SPF & DKIM Best Practices

Why SPF and DKIM Are Non-Negotiable for Deliverability

You send a campaign to thousands. It’s well-written, on-brand, and perfectly timed. Then you check the reports—half your emails never land in inboxes. Instead, they vanish into spam folders or get outright rejected. Sounds familiar? It’s not the content. It’s not even the list. It’s the invisible foundation: your DNS records.

SPF and DKIM aren’t optional add-ons. They’re the authentication backbone that lets email providers trust you. Without them, even your most carefully crafted messages are treated like potential threats. Major providers—Gmail, Outlook, Apple Mail—require them. No handshake, no delivery.

Think of SPF and DKIM as a digital ID and signature for your domain. SPF says, “These servers can send mail for me.” DKIM cryptographically confirms the message hasn’t been altered in transit. Together, they’re how the email ecosystem verifies identity. Skip either, and you’re sending from a fake phone number with no ID.

Key takeaways

SPF and DKIM are required by Gmail, Outlook, and Apple Mail to accept inbound mail.
Unauthenticated domains are routinely rejected or marked as spam, regardless of message content.
Proper configuration directly impacts inbox placement and sender reputation over time.

What Do SPF and DKIM Actually Do?

You use SPF and DKIM to prove your emails actually come from your domain—no tricks, no spoofing. SPF checks that the sending IP is authorized in your DNS records. DKIM adds a digital signature to each email, so receiving servers can verify it wasn’t altered in transit. Together, they're the first line of trust when an inbox decides whether to accept or reject your message.

SPF: Your Domain’s Permission List

SPF acts like a gatekeeper. It tells mail servers which IP addresses are allowed to send emails on your domain’s behalf. If an email arrives from an unauthorized server, SPF can flag it as suspicious. Without SPF, spammers could easily impersonate your brand.

You define this list in your DNS as a TXT record. The record specifies which mail servers—yours or third-party services like SendGrid or Mailchimp—are allowed to send. Misconfigured SPF records can trigger bounces or damage sender reputation, so accuracy is critical.

DKIM: The Unbroken Seal on Your Email

DKIM works by signing each outgoing email with a cryptographic key tied to your domain. The receiving server uses your public key (also in DNS) to verify the signature. If the signature checks out, the email hasn’t been tampered with during delivery.

This isn't just about authenticity—it's about integrity. If a message is altered (say, a link is replaced), the signature fails. DKIM helps prevent phishing and makes your emails more likely to land in inboxes, not trash folders.

Both SPF and DKIM are part of a broader authentication framework. They’re not standalone fixes, but foundational layers in a system that includes DMARC and proper sender reputation. When used together, they significantly reduce the chance of your emails being marked as spam.

For teams managing large lists, verifying records alone isn’t enough. You need to test end-to-end deliverability. Our inbox placement tool checks how your emails land across real inboxes across major providers. It reveals not just authentication health, but actual reception—critical for campaigns, newsletters, and transactional sends.

You can test your full sender configuration, including SPF and DKIM, in real time with our verification API or bulk list validation tool. These help catch misconfigurations before they cost you deliverability. Whether you're onboarding new tools or auditing existing setups, having real proof of compliance is far better than guessing.

For deeper validation, we recommend testing your setup with actual emails sent to real domains. Use MailTester’s inbox placement tool to see how your emails perform in Gmail, Outlook, and others. This step goes beyond DNS checks and confirms your domain is trusted in practice.

SPF and DKIM are standard across the industry. The IETF RFC 7208 (for SPF) and RFC 6376 (for DKIM) define them in detail. These aren’t optional extras—they’re the rules of the road for email authentication. Ignoring them is like sending mail without a return address.

The Three Core Rules for SPF Configuration

SPF fails fast—if your DNS TXT records aren’t set up correctly, your messages won’t get past gatekeepers like Gmail and Outlook. You must keep SPF records singular, avoid excessive lookups, and always end with -all. This prevents misdelivery, improves sender reputation, and keeps your mail from being flagged as spam. Let’s break it down.

Single TXT Record, One Rule

Only one SPF TXT record per domain is allowed. Multiple records trigger validation failure.
If you have more than one, merge them into a single record using the v=spf1 format.
Use tools like MXToolbox to check your DNS configuration before sending.

Respect the 10-Lookup Limit

SPF validation can perform up to 10 DNS lookups. Exceeding this breaks validation.
Use include: sparingly—each include counts as a lookup.
For example, v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all uses two includes and leaves room for others.
Overhead from third-party services (e.g., marketing platforms) can eat this budget fast. Test your record’s lookup count with SPF Checker.
If you’re adding more than a few includes, reconsider your setup—simplify or use a sender policy framework wrapper.

Always End with -all

Include -all to enforce strict policy. This tells receiving servers: “If not explicitly allowed, reject.”
Using +all or ~all weakens your security and may result in false positives or poor deliverability.
Best practice: v=spf1 include:_spf.example.com -all.
Test your SPF config with a real verification tool like MailTester’s email validation API to catch misconfigurations early.
Don’t rely on legacy tools—modern systems expect strict enforcement to reduce spoofing risks.

SPF isn’t just about blocking fake mail—it’s about proving you’re the real sender. Misconfiguration costs trust.

Step-by-Step: Setting Up SPF Correctly

Configuring SPF correctly starts with logging into your DNS provider and adding a TXT record for your domain with the exact v=spf1 syntax, including only trusted sending sources like SendGrid or Mandrill, using -all to reject unauthorized mail. Avoid mixing mechanisms without clear tracking, and always test the result before sending.

Log in to your DNS provider’s control panel. This is where you manage your domain’s DNS records. Providers like Cloudflare, AWS Route 53, or GoDaddy host these settings. Choose the one linked to your sending domain (e.g., example.com).
Create a new TXT record for your domain. In the DNS interface, look for an option labeled “Add record” or “Create new record.” Select TXT as the type. Enter your domain name (e.g., example.com) in the name or host field.
Set the name field to '@' or leave it blank. Using @ or leaving it blank ensures the record applies to the root domain, not a subdomain. This is critical—misconfiguring the name field can break SPF entirely.
Enter the full SPF string. Use a format like v=spf1 include:_spf.sendgrid.net include:spf.mandrill.com -all. Replace these with your actual sending platforms. Keep the syntax exact; even a typo breaks validation.
Avoid mixing mechanisms without care. Using both ip4 and include mechanisms can cause issues if not tested. Each mechanism adds complexity—verify the total mechanism count doesn’t exceed 10, per RFC 7208.
Save the record and test it. After saving, wait up to 48 hours for DNS propagation. Use tools like MxToolbox or your provider’s DNS checker to validate the SPF record. You can also test your setup before sending to validate deliverability.

Why This Matters

SPF isn't just a formality. It’s one of the core email authentication standards. Misconfigured SPF can lead to your emails being rejected, marked as spam, or blocked—especially by large providers like Gmail and Outlook. A single typo or invalid mechanism can cause all mail from your domain to fail.

Preventing Overcomplication

Don’t add every service that sends emails under the sun. Only include trusted sources you actively use. Overloading SPF with multiple includes increases the risk of hitting the 10-mechanism limit. Instead, use a dedicated email service provider with proper SPF delegation.

“SPF is foundational, but it’s not a silver bullet. It must be set correctly and used in concert with DKIM and DMARC.” — RFC 7208

Once SPF is set, pair it with DKIM and DMARC for stronger deliverability. You can test your overall configuration with inbox placement tools. For full verification, use MailTester’s inbox tester to see how your messages land in real inboxes.

DKIM: How to Generate and Publish a Signing Key

You generate a DKIM key pair through your email service provider or a trusted tool, keep the private key secure on your sending system, and publish the public key in DNS as a TXT record using a selector like default._domainkey.example.com. Use at least 1024-bit keys—2048-bit is recommended for stronger security and long-term reliability. This process verifies that emails sent from your domain were authorized and haven’t been tampered with in transit.

Step-by-step: Generating and Publishing Your DKIM Key

Generate the key pair via your email service — Log into your email platform (SendGrid, Mailchimp, or a dedicated DKIM tool). Look for the DKIM setup section and generate a new key pair. The platform handles the cryptographic generation; you don’t need to do this manually.
Keep the private key secure — The private key never leaves your sending system. It’s used to sign outgoing emails. If compromised, attackers could forge emails that appear to come from your domain. Never store or share this key externally.
Use a minimum of 1024 bits; prefer 2048-bit keys — While 1024-bit keys were once standard, they’re now considered weak. As of 2023, major platforms like Google and Microsoft recommend 2048-bit keys. This aligns with security best practices outlined in RFC 6376, which defines the DKIM standard.
Extract the public key and selector — Your provider will give you a public key string (often starting with v=DKIM1; k=rsa;) and a selector (e.g., default or mail1). The DNS record name will be selector._domainkey.yourdomain.com — this is how receiving servers look it up.
Publish the public key in DNS as a TXT record — In your domain’s DNS management panel, create a new TXT record with the full key string as the value. The record name must match the selector and domain exactly. Double-check for typos: even a single space or missing quote can break DKIM validation.

Verify Your DKIM Setup

After publishing, use a tool like MxToolbox or DKIM Analyzer to verify the record resolves correctly. A successful lookup means the public key is accessible and can be used by receivers to validate your signed messages. Never skip this step — a misconfigured or missing record renders DKIM ineffective.

Once set up, DKIM significantly improves email deliverability by proving authentication. Combined with SPF and DMARC, it protects your domain reputation. You can test how your emails perform in real inboxes using MailTester’s inbox placement tool: inbox placement tester. For high-volume senders, use the real-time verification API to validate addresses before sending, including DKIM readiness.

SPF vs DKIM vs DMARC: Roles, Differences, and What They Protect

You need all three—SPF, DKIM, and DMARC—working together to properly authenticate your emails. SPF checks if the sending IP is authorized for your domain. DKIM verifies that the message content hasn’t been altered in transit. DMARC uses SPF and DKIM results to tell receiving servers what to do when authentication fails, enforcing your domain’s email policy. None replaces the others; together, they prevent spoofing and improve inbox placement.

How Each Protocol Works

SPF (Sender Policy Framework) acts like a whitelist. It tells receiving servers which IP addresses are allowed to send emails on behalf of your domain. If an email comes from an unapproved IP, SPF fails—often resulting in a hard bounce or spam marking.

DKIM (DomainKeys Identified Mail) adds cryptographic signatures to each email. It ensures that the message body and headers haven’t been tampered with since leaving your server. Even a single changed character breaks the DKIM signature, which receivers check before delivery.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the enforcement layer. It relies on SPF and DKIM results. You set a DMARC policy—such as “reject” or “quarantine”—and receivers apply it when authentication fails. DMARC also provides feedback reports so you can monitor misuse of your domain.

Why All Three Are Required

SPF alone is insufficient. It only covers the envelope sender (Return-Path), leaving DKIM’s content validation unverified. DKIM alone can’t block impersonation from unauthorized IPs. DMARC can’t enforce anything without valid SPF or DKIM results.

Think of it like a security system: SPF is the front door lock, DKIM is the tamper seal on the package, and DMARC is the security team that says “don’t accept the package if either check fails.” All three together stop attackers from spoofing your domain or injecting malicious content.

Spamhaus and the IETF document the technical foundations of these standards. The DMARC specification (RFC 7483) outlines how policies are evaluated, and it’s widely adopted by major email providers.

For ongoing email health, verify your records with real-world testing. Use our inbox placement tester to see how your emails land across major providers, or run a full bulk verification to check lists before sending. These tools help spot misconfigurations early—before they hurt your deliverability.

Common Mistakes to Avoid When Configuring SPF and DKIM

You’re likely to break email deliverability if you publish multiple SPF records, exceed the 10-DNS-lookup limit with overuse of include, or misconfigure DKIM selectors. Using +all in SPF allows spammers to send as you, and skipping post-deployment validation means you won’t catch errors until after reputation damage. Let’s run through the most common pitfalls—and how to avoid them.

SPF Configuration Errors That Break Deliverability

Only one SPF TXT record is allowed per domain. Multiple records cause validation failure and can lead to deliverability blackouts.
Using too many include mechanisms (e.g., include:spf.protection.outlook.com, include:sendgrid.net, include:amazon.com) risks hitting the 10-DNS lookup limit. Exceeding it causes SPF to fail silently.
Using +all in SPF means accepting any sender, even unauthorized ones. Always use -all to reject unauthorized mail.

DKIM and Validation Oversight

DKIM keys must be published with the correct selector (e.g., default._domainkey.example.com). A typo here breaks signing and causes rejection.
DKIM signatures expire. If your key has a long TTL or isn’t rotated, emails fail authentication after expiry.
After changing SPF or DKIM, always test. Changes can take 24–48 hours to propagate. Use tools like MXToolbox to verify DNS records are live and correct.

Even with correct records, you won’t know if they’re working until you send. Use inbox placement testing to confirm your messages reach inboxes—not spam folders. MailTester’s inbox placement tool simulates real-world delivery across major providers to reveal configuration gaps before you send to your list.

“A correctly configured SPF record doesn’t guarantee deliverability—it just removes one major blocker.”

Don’t assume everything works. Test your full email stack after every change. Even minor misconfigurations can trigger filters or blacklists.

Use MailTester’s real-time verification API to validate email addresses and confirm your DNS settings align with actual deliverability performance. Run bulk checks on your list with MailTester’s bulk verification tool to catch bad domain patterns early.

How to Verify SPF and DKIM Are Working in Real Time

You can verify SPF and DKIM are working in real time by testing individual email addresses with a real-time verification API like MailTester’s, sending test emails to Gmail or Outlook and checking the Received-SPF and DKIM-Signature headers in the full message source, and validating DNS records and header results using tools like MxToolbox or Gmail’s Message Header Analyzer. Monitor for delays or bounces—these often signal alignment or reputation issues before they affect deliverability.

Test Addresses in Real Time with the API

Let’s start with a concrete check: use the MailTester real-time verification API to test an email address and confirm it passes SPF and DKIM alignment. The API returns detailed results including authentication status, domain validity, and whether the mailbox is catch-all or disposable. This is faster than sending real test emails and gives you immediate feedback on whether your sender policy is correctly enforced.

Analyze Headers in a Live Message

Send a test email to a Gmail or Outlook inbox. Once delivered, open the message, click “Show original,” and inspect the Received-SPF and DKIM-Signature headers. You should see a “pass” status for both, and ensure the domain in the DKIM-Signature matches your sending domain. A mismatch here signals configuration errors. Tools like MxToolbox’s SPF/DKIM checker can validate both DNS records and header outputs in one go.

For deeper insight, check RFC 5322 and RFC 7672, which define the structure of email headers and how alignment checks work. Misconfigured DKIM can result in a “fail” even if the signature is technically correct—often due to missing or incorrect canonicalization.

Real-time monitoring helps you catch issues early. If your domain shows delayed delivery or high bounce rates, it could stem from SPF/DKIM misalignment or a degraded sender reputation. The MailTester inbox placement tool lets you simulate delivery to major inboxes and analyze how your email stack performs under real-world conditions. Use it periodically to ensure that your configuration stays effective.

Don’t rely only on tools. SPF and DKIM are part of a larger system. If your DKIM alignment fails but SPF passes, or vice versa, you’re still at risk of rejection by receiving mail servers. Consistency across all three authentication methods (SPF, DKIM, DMARC) is a sign of a mature email program.

Learn more about how MailTester integrates with platforms like SendGrid, Klaviyo, and Mailchimp to automate these checks for your entire list. Use the MailTester verification API to verify your setup continuously, or try inbox placement testing to see exactly how real inboxes process your messages.

When to Use MailTester to Audit Your SPF and DKIM Setup

Use MailTester to audit your SPF and DKIM records whenever you’re preparing for a large email campaign, switching email providers, noticing sudden deliverability drops, or making DNS changes. It’s the fastest way to catch misconfigurations before they hurt inbox placement. You’re not just checking if records exist—you’re validating whether they’re properly aligned, signed, and trusted by receiving servers.

When to run a full authentication audit

Before launching a bulk email campaign—especially if you’re using a new sender domain or email service provider.
After switching to a new ESP (like Mailchimp, HubSpot, or Klaviyo)—these platforms often update DNS requirements, and a misaligned SPF or DKIM can trigger spam filters.
If you notice sudden spikes in hard bounces or inbox placement drops—misconfigured authentication is a common cause, especially after infrastructure changes.
Immediately after migrating domains or editing DNS records for the first time—errors in syntax, record length, or alignment can break deliverability.
When integrating with tools like Klaviyo or SendGrid: verify that your outbound emails aren’t triggering sender reputation red flags from receiving servers.

How MailTester helps you stay ahead

It’s not enough to have SPF or DKIM set up—you need to ensure they’re correctly formatted, properly aligned, and not conflicting with other records. MailTester checks for syntax errors, alignment mismatches, and missing signatures, all in real time. Unlike basic DNS checkers, it validates how these records appear to email receivers, including the latest standards from RFC 7208 and RFC 6376.

For example, if your SPF record exceeds 10 DNS lookups or includes an incorrect mechanism like ~all instead of -all, MailTester flags it. If DKIM isn’t using a valid selector or your public key isn’t correctly published, you’ll see it instantly.

Run a free check on your first 100 domains using the bulk verification tool. If you’re integrating with marketing platforms, test your setup with the inbox placement tester to see exactly how your emails land in real inboxes across providers.

It’s not about guessing. It’s about verifying—before your next send. With credits that never expire, you can audit as often as you need. The goal isn’t perfection, but operational confidence.

Why Proper DNS Configuration Prevents Deliverability Issues

You can’t send consistently to inboxes if your SPF and DKIM records are misconfigured. Even a single syntax error breaks authentication, and that triggers filters at major providers like Gmail and Outlook. Every failed authentication increases the odds your domain gets flagged — even if your content is clean. MailTester’s 98.9% accurate verification catches these problems before they cost you deliverability.

Authentication Failures Show Up Early

When you run a bulk list through MailTester’s email verification tool, addresses with invalid or misconfigured SPF or DKIM records often get flagged as 'risky' or 'invalid'. That’s because the underlying DNS checks reveal syntax errors, missing tags, or expired keys. It’s not guessing — it’s testing actual authentication signals from the mail server’s perspective.

Let’s say your SPF record lists a domain that no longer handles mail, or your DKIM key is malformed. These aren’t just small mistakes; they’re red flags to receiving servers. You may not see it until your first large send fails with a hard bounce, or worse, gets silently filtered. With MailTester, you catch this earlier — before your domain reputation takes a hit.

Protecting Sender Reputation Starts With DNS

Every message you send successfully — with proper SPF, DKIM, and DMARC — contributes to your reputation. But if even 1% of your sends fail authentication, it signals inconsistency to inbox providers. That consistency is why services like Google and Microsoft track long-term sending patterns.

MailTester helps you send only to addresses that pass verification. That means fewer bounces, less time in quarantine, and a stronger long-term signal to providers that you’re a legitimate sender. The result? Better inbox placement over time — especially important for marketing or transactional campaigns.

Use our bulk verification to clean lists before sending. Our real-time API checks individual addresses on the fly. And for full validation, run inbox placement tests via inbox tester. With every successful send, your domain gets stronger. More sends, more consistency — that’s how reputation grows.

For a full guide on how DNS records actually work in practice, see the SPF specification or the DKIM standard. These aren’t just documentation — they’re the real rules of email authentication.

Conclusion: Authentication Is the Foundation of Inbox Placement

Proper SPF and DKIM configuration isn’t optional — it’s the baseline for consistent inbox delivery. Without it, even the most carefully crafted email campaign will struggle to reach inboxes, regardless of list quality or content relevance.

Unauthenticated messages are frequently blocked or filtered by recipient providers, even when sender reputation is strong. This is not a temporary glitch; it’s a fundamental requirement of modern email infrastructure.

Use MailTester’s inbox-placement testing and real-time API to validate your domain alignment and catch setup errors before they impact deliverability. The feedback is immediate, actionable, and based on actual sending conditions.

Keep reading

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

Frequently asked questions

Can you have multiple SPF records?

No. Only one SPF TXT record is allowed per domain. Multiple records cause validation failure. Use include statements within a single record instead.

What happens if DKIM fails but SPF passes?

The message may still be delivered, but the lack of DKIM signature reduces trust. Receivers prioritize messages with both SPF and DKIM validation.

How long does it take for SPF and DKIM to take effect?

DNS propagation typically takes 5 to 30 minutes, but full validation in receivers’ systems may take up to 24 hours.

What is the best SPF policy to use?

Use '-all' to reject messages from unauthorized IPs. Using '+all' (relax mode) allows forged messages to pass and harms reputation.

Can MailTester test SPF and DKIM directly?

Yes. MailTester’s real-time API and inbox-placement testing validate recipient domain configuration, including SPF and DKIM alignment.

Do I need DKIM if I have SPF?

Yes. SPF only checks the sending IP. DKIM validates content integrity and provides stronger sender identity proof.

What is DMARC and why does it matter?

DMARC uses SPF and DKIM results to define how receivers should handle failures. It’s essential for protecting your domain from impersonation.

Can a bad SPF record get my domain blacklisted?

Not directly, but misconfigured SPF increases spam risk and can lead to reputation damage over time, which may trigger blocklisting.

Should I use a dedicated domain for email sending?

Yes. Dedicated domains isolate your email reputation from web traffic and reduce the impact of misconfiguration.

How often should I review my DNS records?

At least quarterly, or after any change to your email service provider, infrastructure, or sending volume.

What does 'authentication alignment' mean?

It means the domain used in the 'From' header matches the one in SPF and DKIM results. Mismatches reduce trust and hurt deliverability.

Can tools like MailTester help with DMARC?

Yes. MailTester's inbox-placement and verification tools test DMARC compliance indirectly by validating sender authentication, including DKIM and SPF alignment.