SPF Record Setup Guide

Why SPF Setup Matters for Inbox Placement

You send emails. Some land in the inbox. Most don’t. Your lists grow, your campaigns run — and still, deliverability stalls. Why?

One reason hides in plain sight: your SPF record. It’s not flashy, but it’s one of the core checks that determines whether your mail gets accepted or blocked.

A correct SPF setup acts like a digital handshake between your domain and receiving servers. It says, “This sender is authorized.” Get it wrong, and your emails get flagged, bounced, or sent to spam — even if your content is perfect.

If you’re trying to improve inbox placement, you don’t just need better subject lines. You need to fix what’s underneath: your domain’s authentication foundation.

Here’s how to set up SPF step-by-step, with no guesswork. No fluff. Just the mechanics, the common mistakes, and the impact on deliverability.

Key takeaways

SPF is a core email authentication protocol that verifies sender legitimacy to receiving servers.
Misconfigured SPF records commonly cause bounces, spam filtering, and damage to sender reputation.
A correctly implemented SPF record improves inbox placement by reducing rejection risks and increasing trust signals.

The Real-World Impact of SPF Misconfiguration

You’ve set up SPF. Good. But if it’s incomplete, conflicting, or has a single syntax error, your emails won’t just get flagged — they’ll be quietly rejected. Gmail, Outlook, and other major providers are strict about authentication. One misstep in your DNS record can trigger a chain reaction across your entire domain infrastructure.

One Syntax Error, Whole System Breakdown

Let’s be clear: a mistyped character in a TXT record — like an extra space, a missing quote, or a typo in include: — can invalidate the entire SPF policy. That’s not hyperbole. The SPF specification (defined in RFC 7208) treats a syntax error as a hard fail. Once that happens, the mail server doesn’t just ignore your sender policy — it considers your domain untrustworthy for sending.

Imagine sending to 10,000 recipients. With a broken SPF record, your emails won’t just get into spam: they’ll be blocked entirely. No bounce back. No error code. Just silence. This silent rejection is one of the hardest deliverability issues to diagnose — your open rates stay flat, your click-throughs are dead, and you’re left wondering why your campaign underperformed.

How Misconfigurations Hit Deliverability

Even if your SPF record is valid, having multiple records for the same domain is a classic mistake. DNS allows only one TXT record per hostname, and when you have two or more, they don’t merge — they conflict. The receiving server sees multiple policy statements and fails to process any of them. This is why duplicate SPF records are worse than no record at all.

Another common issue: relying on third-party services like SendGrid, Mailchimp, or AWS SES without properly including their SPF mechanisms. If you’re sending via those platforms but haven’t listed their included domain in your TXT record, your emails are treated as unauthenticated. Gmail’s own filters (documented in Google’s help documentation) will flag these messages as high-risk, often routing them straight to spam or discarding them silently.

Here’s the cold truth: if your SPF record isn’t verified with real email data, you’re guessing. You’re not seeing what your recipients actually experience. Use a real-time verification tool to test how your SPF policy holds up across major providers. Try inbox placement testing or run a bulk verification with MailTester’s bulk verification to spot problems before they cost you leads and revenue.

Step-by-Step: Set Up Your SPF Record Correctly

SPF isn't a magic fix, but it’s one of the most critical foundations for email deliverability. Without it, your messages may not reach inboxes — or worse, get flagged as spam. Let’s walk through setting it up correctly, step by step.

Verify Your Sending Infrastructure First

Before you configure SPF, know which platforms actually send email on your behalf. Common senders include Google Workspace, AWS SES, SendGrid, or Mailchimp. Using the wrong include (like include:_spf.google.com when you're using AWS) breaks authentication.

Each email service publishes its own SPF includes. You can verify them using their official documentation or third-party tools. For example, RFC 7208, the SPF specification, outlines standard practices for publishing and validating alignment.

Log in to your domain registrar or DNS provider — whether it’s Cloudflare, GoDaddy, AWS Route 53, or another platform. You need access to your DNS zone records.
Navigate to the DNS management section and look for the TXT record list. This is where you’ll define your SPF policy.
Create a new TXT record. Set the name (also known as the host) to your root domain like example.com, or leave it blank if your provider uses that convention for the root.
Set the value to v=spf1 include:_spf.google.com ~all. Replace _spf.google.com with your sender’s include. For example: include:sendgrid.net or include:aws.amazon.com.
Ensure you don’t duplicate SPF records. Only one SPF TXT record per domain is allowed. Having multiple leads to validation failure. Check for duplicates using a DNS lookup tool.
Save the record. Changes can take a few minutes to propagate, but up to 48 hours is normal in some cases.
Verify the record is published using a public DNS lookup tool like MXToolbox or dig txt example.com from the command line. Confirm the output matches what you set.

Double-Check for Common Mistakes

SPF syntax is strict. One typo can break your entire email delivery. Avoid using all without a modifier like ~all (soft fail) or -all (hard fail). Using -all too early can break legitimate sends if you miss a provider.

Don't forget that SPF only covers sending origin. It doesn’t guarantee inbox placement. But it’s a required part of email authentication, along with DKIM and DMARC. Tools like inbox placement testing can show you how your messages land across inboxes after you’ve verified the record.

“SPF is not a deliverability solution by itself, but it’s a baseline requirement.” — RFC 7208

After setup, use MailTester’s API or bulk verification to test lists against real-world deliverability signals, including SPF alignment and bounce risk.

Common SPF Mistakes That Break Deliverability

Even a small error in your SPF setup can tank deliverability. Let’s cut through the noise and fix what actually breaks email inboxes.

Too Many SPF Records? One’s All You Get

You’re not allowed multiple SPF records. Only one TXT record per domain is valid. If you have more than one—even if they’re both labeled SPF—it fails validation.

Many tools, like Mailchimp or SendGrid, add their own, and you end up with two TXT records. That breaks SPF completely. Your DNS configuration must consolidate all policies into a single TXT record.

Use a tool like MxToolbox’s SPF Checker to verify your record is clean and singular.

Too Many Lookups? SPF Dies at 10

Every time your SPF record includes another domain (like include:spf.prosend.com), it counts as one DNS lookup. Your total must stay under 10.

More than 10 lookups trigger a permerror. Strict receivers (like Gmail, Outlook) reject messages outright when this happens. Even one extra include can push you over the edge.

Don’t use include for every third-party service. Consolidate where possible.
Replace multiple includes with a single, well-structured include chain if approved by your providers.
Check your record against the SPF specification (RFC 7208) to ensure compliance.

The "All" Clause: Don’t Just Say "Fail" — Say "Fail Softly"

Using all without a qualifier—like -all—is a disaster in practice.

That single line tells receivers: “All other senders are unauthorized.” Even if your email is valid, strict receivers treat this as a hard fail.

Always use -all to reject unauthorized senders, or ~all to mark them as soft-fail. -all is standard and safer for deliverability.

Forgetting Your Email Provider? That’s a Delivery Killer

If you use SendGrid, Mailchimp, or similar services, you must include their SPF in your record.

Example: include:_spf.sendgrid.net

Without it, your emails get flagged as forged—even if you’re sending from a legitimate system. Your provider’s SPF is part of the trust chain.

Double-check all senders in your stack. Use Bulk Email Verification to test if your senders are recognized as valid before sending to real users.

SPF vs DKIM vs DMARC: What Each One Does

Let’s break down the three core email authentication protocols you need for reliable deliverability. They’re not just technical checkboxes—they’re your foundation for avoiding spam filters and inbox rejection.

SPF: Trust the Sending Server

SPF (Sender Policy Framework) tells receiving servers: “Only these IP addresses are allowed to send emails on my behalf.” It checks that the email came from one of your authorized servers. If the sending IP isn’t on the approved list, the email fails SPF. A common mistake? Forgetting to include all your email platforms—like SendGrid, Mailchimp, or your own mail server—in the SPF record.

DKIM: Prove the Message is Untampered

DKIM goes further. It doesn’t just check the sender—it verifies the email content hasn’t been altered in transit. Every outgoing message gets a digital signature tied to your domain. Receiving servers check that signature against your public key. If it doesn’t match, the email is flagged. This is especially important when emails pass through third-party services that may rewrite parts of the message.

DMARC: Tell Receivers What to Do

DMARC ties SPF and DKIM together. It’s your directive: “If an email fails SPF or DKIM, reject it, quarantine it, or allow it?” You can also set up reporting—DMARC gives you reports about who’s sending on your behalf, which helps detect spoofing attempts. Without DMARC, even if SPF and DKIM are set up, you get no feedback or enforcement. The official DMARC spec (RFC 7489) is the definitive reference. It explains how alignment works—ensuring the domain in the From header matches the domain that passed SPF or DKIM. Let’s be clear: none of these protocols work alone. SPF stops unauthorized sources. DKIM ensures message integrity. DMARC enforces the rules and gives you visibility. Together, they form an authentication stack that major providers like Gmail and Outlook rely on to filter spam. You can verify SPF and DKIM alignment on your domain using tools like MailTester’s inbox placement test, which simulates real-world delivery across major providers. If you're setting up or updating your records, always validate your configuration—errors cause deliverability drops. Use a tool like MailTester’s real-time verification API to test individual addresses before sending, and bulk verification to clean your list at scale. Think of it as a three-layer system: authentication, integrity, and enforcement. When done right, you’re far less likely to land in spam or be blocked altogether.

How to Test Your SPF Record After Setup

Setting up an SPF record is only half the battle. The real test comes after you apply it—because a misconfigured record can silently harm deliverability. Let’s walk through how to validate it properly.

Run a Real-Time DNS Check

Go to a free DNS lookup tool like MXToolbox and enter your domain.
Select the “SPF” check from the dropdown. It will query your DNS immediately.
Review the result. The full SPF record should appear exactly as you entered it—no missing components, no extra quotes, no truncation.

Even a single misplaced quote or typo breaks SPF validation. The record must be parsed correctly by receiving servers. A malformed entry is treated as a hard failure, which can lead to emails being blocked.

Check for Errors and Permissions

Look for any permerror or fail in the results. These signals mean your record is syntactically invalid.
Verify that your sending provider (e.g., SendGrid, Amazon SES, Mailchimp) is listed in the include or ip4 mechanisms.
For SendGrid, ensure you have include:sendgrid.net in the record. Without it, emails from your SendGrid account won’t pass SPF.

If the provider isn’t listed, even if the syntax is correct, delivery will likely fail. Receiving mail servers perform this check automatically—and don’t give second chances.

SPF doesn’t operate in isolation. It works best when paired with DKIM and DMARC. A well-configured SPF record is foundational, but not sufficient on its own. The SPF RFC documents the standard, but implementation often falls short in practice.

Once you’re confident the record is correct, test it from the source. Use MailTester’s inbox placement test to see how real email providers treat messages sent from your domain—before you send to real customers.

Keep in mind that SPF is strict about alignment. If you add or remove a service, update the record immediately. DNS changes can take up to 48 hours to propagate fully, so test early.

Don’t trust your gut. Verify. A single missing include or a typo in an IP range can silently cause delivery issues. When your email is critical, clarity and validation are non-negotiable.

You’ve set up SPF, DKIM, and DMARC, but you’re still seeing bounces. It’s not always the configuration—sometimes, the issue starts with the email address itself. Let’s talk about how MailTester helps you avoid those frustrating delivery failures before they happen.

Spotting problem domains before you send

Not every bounce comes from misconfigured headers. Some email addresses are fundamentally invalid—especially if they belong to role-based accounts like admin@, sales@, or support@. Or they’re on disposable domains that reject incoming mail outright. MailTester’s real-time API and bulk verification tools check for these red flags as you build your list. It doesn’t just tell you if an address exists—it tells you whether that address is likely to fail SPF validation due to domain policies or catch-all behavior. With 98.9% accuracy, MailTester’s verification identifies catch-all domains (where any address gets accepted, even invalid ones) and disposable email providers (like mailinator or 10minutemail), which commonly block SPF checks. You’re not just cleaning your list—you’re preventing sends to addresses that won’t accept your message regardless of your authentication setup.

Testing SPF in real-world conditions

Even with perfect records, SPF can still trigger delivery issues if the receiving provider has strict policies or runs deep analysis on sender reputation. MailTester’s inbox-placement testing lets you simulate delivery across Gmail, Outlook, Apple Mail, and others. This isn’t a lab test—it’s a real-world simulation that reveals how your messages land in inboxes or junk folders. When you run an inbox-placement test, MailTester checks whether SPF validation passes under the actual rules of each provider. If an address is flagged as “risky” or “catch-all,” the test will reflect that. This means you catch SPF-related delivery failures in advance—not after a campaign has already failed to reach inboxes. Let’s be clear: SPF is one piece of the puzzle. But if your sending infrastructure can’t pass it, the rest doesn’t matter. Using MailTester’s bulk verification or real-time API, you can screen out high-risk addresses before they get to your server, regardless of how solid your SPF record is. This isn’t about replacing SPF setup—it’s about making sure the foundation you've built actually works with real-world email behavior. And yes, you can test it. Try inbox placement today at MailTester's inbox-placement testing, or get started with 100 free verifications for your list at bulk verification.

SPF and List Hygiene: Preventing Bounce Loops

Let’s be clear: SPF doesn’t fix bad data. It only checks if a server is authorized to send on behalf of a domain. If your list contains invalid or role-based addresses—like admin@, sales@, or info@—you’re not just risking bounces. You’re making SPF checks ineffective.

Role Accounts and Invisible Failures

Role addresses often appear valid but aren’t actually monitored. They’re commonly used as spam traps or are configured to auto-delete. When you send to them, SPF might succeed… but the email never lands in an inbox. Instead, you get a bounce. That bounce might be soft, then hard, and eventually, your domain gets flagged as unreliable. This is how bounce loops start.

MailTester’s verification engine identifies these high-risk addresses before they ever hit your sending platform. It doesn’t just check syntax or domain presence—it analyzes real-time delivery patterns, catch-all responses, and sender reputation signals. You’ll see flags for role accounts, disposable domains, or non-existent mailboxes before you send a single message.

Think of it like checking your engine before a long drive. A clean list means SPF isn’t wasting time on dead ends. It runs only on addresses that can actually receive mail. That’s how you avoid getting caught in a cycle where every bounce reinforces bad sender reputation.

How Verification Improves SPF Accuracy

SPF checks are part of a larger deliverability ecosystem. If your list is full of invalid emails, even a perfectly configured SPF record won’t help. ISPs see volume and quality signals. If a large chunk of your sends fail due to non-existent or role-based addresses, your sender score drops—no matter how correct your SPF, DKIM, or DMARC are.

By cleaning your list with MailTester’s bulk verification, you ensure every send is targeted, tracked, and measurable. You’re not just validating syntax—you’re reducing the number of failed deliveries, which directly impacts your sender reputation. More importantly, you’re making SPF checks apply only where they matter: to valid endpoints.

Use the bulk verification tool to clean large lists in minutes. It’s built to handle 100,000+ emails efficiently and integrates with platforms like Mailchimp, HubSpot, and Klaviyo, so you can verify before sending. You can also automate this with the real-time API—perfect for lead capture or onboarding workflows.

It’s not about being perfect. It’s about being efficient. The fewer bad sends you make, the lower your bounce rate, the better your SPF and DKIM signals stack up. This is how you stay out of spam traps and keep mailboxes open.

For a broader view of how your emails land in inboxes—beyond SPF—run a delivery test with inbox placement to see real-time results across Gmail, Outlook, and other primary providers.

When SPF Isn’t Enough: Layering with DKIM and DMARC

You’ve set up SPF. That’s solid groundwork. But SPF alone won’t stop a clever attacker from altering your message or forging the sender address if other systems fail. It only validates the sending server, not the content.

DKIM: Signing for Message Integrity

Let’s say your email gets rerouted through a compromised server. SPF might still pass — because the server is in your approved list. But DKIM changes that. It adds a cryptographic signature to your email’s header and body. Every receiving server checks this signature to confirm the message wasn’t tampered with in transit. If it diverges even slightly, the email fails DKIM validation.

DKIM doesn’t prevent spoofing by itself, but it ensures what arrives is exactly what you sent. Think of it as a digital fingerprint tied to your domain. It’s an industry-standard requirement for serious senders.

DMARC: The Enforcement Layer

DKIM confirms integrity. SPF confirms origin. But who decides what happens when one fails? That’s where DMARC comes in. It’s a policy framework telling receivers what to do with emails that fail SPF or DKIM checks.

You can set DMARC to simply monitor, quarantine suspicious messages, or reject them outright. You also get feedback reports — daily summaries showing which emails passed or failed, and where they were sent from. This lets you spot unauthorized senders, detect impersonation attempts, and validate your setup over time.

DMARC doesn’t work without SPF or DKIM. It’s the enforcement layer, not the detection layer. But without DMARC, you’re flying blind. You won’t know when your domain gets abused, or if your email authentication is actually stopping fraud.

Most high-volume senders, especially those using platforms like Mailchimp, HubSpot, or SendGrid, require DMARC alignment. If you’re not publishing a DMARC record, you’re at risk of being filtered or blocked — even if SPF is correct.

Let’s look at the real picture: a 2023 report from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG) notes that email authentication failures — especially missing or misconfigured DMARC — are a top reason for inbox placement drops. You can verify your domain’s current alignment and detect potential flaws using tools like MailTester’s inbox placement test, which includes email authentication checks.

Proper email delivery isn’t a single check — it’s a chain. SPF starts the chain. DKIM secures it. DMARC enforces it. Ignore any one, and the whole system risks failure.

Keep Your SPF Record Updated as You Scale

Scaling your email operations means adding new tools—CRM, marketing automation, support platforms. Each one may need to send emails on your behalf, which means your SPF record must evolve.

Don’t Let New Services Break Your Deliverability

Every time you add a new email-sending service (like a CRM or newsletter platform), check if it requires an include in your SPF record.
Use include: instead of hardcoding IP addresses. It’s more maintainable, and it avoids expiration or misconfiguration when a provider changes IPs.
Never exceed 10 DNS lookup limits in your SPF record. If you hit that limit, consolidate providers or use a DMARC alignment strategy with a dedicated sending domain.
Use a tool like MailTester’s bulk verification to test your senders’ domain alignment and catch SPF issues before they impact deliverability.
Monitor SPF consistency monthly. Use a free tool like MXToolbox or RFC 7208 to verify your record’s structure matches your current email flow.
Update your SPF record the moment a new service joins your stack. Delaying adds risk—misconfigured SPF can trigger soft bounces or outright rejection.

Align SPF with Real-World Sending Behavior

SPF isn’t static. It’s a living document. If you migrate from one platform to another, remove outdated includes. If a service stops sending, don’t leave its inclusion in place.

Review your sender reputation monthly. Check if your email is marked as spam or failing verification in real-world inbox tests.
Use MailTester’s inbox placement tool to simulate real delivery across Gmail, Yahoo, Outlook. This shows whether SPF (and DKIM/DMARC) are working in practice—not just in theory.
Double-check that all your include: entries point to active, correct providers. A typo or outdated include breaks alignment.
Let’s be honest: most email delivery issues aren’t from bad content. They’re from forgotten or outdated SPF records.

Consistency between your SPF record and actual sending behavior is the foundation of long-term deliverability.

When you scale, don’t assume your SPF will stay valid. Keep it audited, updated, and aligned with every service you use—even the ones you thought you’d only use temporarily.

Final Step: Confirm Your Domain’s Delivery Health

Even with a properly configured SPF record, email deliverability depends on real-world testing. Use MailTester’s inbox-placement test to send a sample message to major inboxes and observe actual delivery outcomes.

The test checks SPF alignment, DKIM, DMARC, and inbox placement in Gmail, Yahoo, Outlook, and other major providers. You’ll get detailed feedback on authentication status and any issues blocking delivery.

Always re-test after a DNS change. Propagation delays can mask misconfigurations. A single test ensures your SPF setup is active across all relevant servers and not stuck in cache.

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if I don’t set up SPF?

Emails from your domain may be rejected or marked as spam by receivers that enforce authentication. This harms deliverability and sender reputation.

Can I have two SPF records?

No. Only one SPF TXT record is allowed per domain. Multiple records cause a fatal error and break authentication.

How do I find my email provider’s SPF include?

Check your provider’s documentation — examples include _spf.google.com for Gmail, sendgrid.net for SendGrid, or aws.amazon.com for Amazon SES.

Does SPF protect against phishing?

Not directly. SPF prevents unauthorized use of your domain for sending, reducing spoofing risk, but phishing prevention requires DKIM and DMARC too.

What’s the difference between ~all and -all in SPF?

~all means 'soft fail' — emails will still be accepted but flagged. -all means 'hard fail' — receivers should reject messages from unauthorized IPs.

How can I check if my SPF record is working?

Use a public DNS tool like MXToolbox to query your domain’s TXT records and confirm syntax, alignment, and correct includes.

Can MailTester help with SPF setup?

MailTester doesn’t set up records, but its inbox-placement and verification tools help verify your domain’s delivery health after setup.

Does SPF affect sender reputation?

Yes. Consistent SPF failures or misconfigurations harm sender reputation over time by increasing bounce and spam likelihood.

Should I include my sending platform’s SPF record?

Yes — only use the provider’s include (e.g., include:sendgrid.net) instead of hardcoding IP addresses.

Can I test SPF without sending email?

Yes — MXToolbox and similar tools check DNS records directly, allowing you to verify SPF correctness without sending mail.

What if my SPF record exceeds 10 DNS lookups?

It triggers a permerror. Resolve it by using a single provider include or transitioning to use a DMARC-aligned mechanism like a dedicated subdomain.

How often should I audit my SPF record?

Review at least quarterly, especially after adding new email services or changing sending providers.