SPF, DKIM, and DMARC Explained: Stop Emails Going to Spam

Your carefully written email lands in spam. The recipient never sees it. According to Google’s Email Sender Guidelines (2024), bulk senders without SPF, DKIM, and DMARC now face rejection on roughly 75% of unauthenticated messages to Gmail. Microsoft and Yahoo enforce similar requirements.

These three protocols, SPF, DKIM, and DMARC, form the foundation of email authentication. They tell receiving servers that your email is actually from you. This guide explains how each protocol works, shows real DNS records, and walks through setup for Google Workspace, Microsoft 365, and custom domains. No theory without practice.

email and DNS tools

Check Your SPF Records

Validate your domain’s SPF record, check for syntax errors, and count DNS lookups instantly.

Why Do Emails Go to Spam?

Email spam filters have gotten aggressive. Validity’s Email Deliverability Benchmark Report (2025) found that 16.9% of legitimate marketing emails fail to reach the inbox globally. The biggest single cause is missing or broken authentication records.

When a mail server receives your message, it asks three questions. Is the sending server authorized by your domain’s SPF record? Does the DKIM signature on the message check out? Does the DMARC policy align SPF or DKIM with the From header?

Fail any of these checks and you’re fighting an uphill battle. The message might land in spam, get flagged with a warning, or get rejected outright. And here’s what trips people up: you can fail these checks silently. No bounce notification. No error message. Your email just disappears into a spam folder.

Citation capsule: According to Validity’s 2025 Email Deliverability Benchmark Report, 16.9% of legitimate marketing emails never reach the inbox. Missing SPF, DKIM, or DMARC authentication records are the leading cause, as Gmail, Yahoo, and Microsoft now require all three for bulk senders.

Other factors that trigger spam filters

Authentication isn’t the only factor. But it’s the prerequisite. Even with perfect SPF, DKIM, and DMARC, you can still hit spam if you have poor sending reputation, spammy content, or complaints from recipients. Think of authentication as the entry ticket. Without it, nothing else matters.

understand DNS TXT records

What Is SPF and How Does It Work?

SPF (Sender Policy Framework) lets domain owners specify which mail servers are allowed to send email on their behalf. RFC 7208 defines the current SPF standard, and according to Agari’s Email Fraud Report (2025), SPF adoption among Fortune 500 companies has reached 91%. It’s the most widely deployed email authentication protocol.

SPF works through a single DNS TXT record published on your domain. When someone receives an email claiming to be from you@yourdomain.com, their mail server looks up the SPF record for yourdomain.com. That record lists every IP address and server authorized to send mail for your domain. If the sending server’s IP isn’t on the list, SPF fails.

SPF record syntax explained

Here’s a real SPF record for a domain using Google Workspace and Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.50 -all

Breaking this down piece by piece:

• v=spf1 - Version identifier. Always required, always first.
• include:_spf.google.com - Authorize Google’s mail servers.
• include:servers.mcsv.net - Authorize Mailchimp’s servers.
• ip4:203.0.113.50 - Authorize one specific IPv4 address.
• -all - Hard fail everything else. Reject unauthorized senders.

The -all at the end is critical. It tells receiving servers what to do with messages from unlisted servers. You have three options:

Most setups use ~all (soft fail) during initial deployment, then switch to -all once everything is verified. Don’t use +all. Ever.

The 10 DNS lookup limit

This is the single most common SPF failure, and it’s invisible unless you check. RFC 7208 specifies that SPF evaluation must stop after 10 DNS lookups. Every include, a, mx, and redirect mechanism triggers a lookup. The ip4 and ip6 mechanisms don’t count because they don’t require DNS resolution.

Here’s how lookups add up fast:

include:_spf.google.com       → 3 lookups (includes nested SPF records)
include:spf.protection.outlook.com → 2 lookups
include:servers.mcsv.net      → 1 lookup
include:sendgrid.net           → 1 lookup
include:spf.brevo.com         → 2 lookups
                                ─────────
Total:                          9 lookups (just under the wire)

Add one more service and you’ve exceeded the limit. When that happens, SPF returns permerror, and many receiving servers treat that as a complete SPF failure. Your email goes to spam and you have no idea why. We’ve seen domains with 14 or 15 lookups that worked fine for months, then suddenly started failing. Why? Because third-party SPF records change. Google might add a nested include, pushing you over the limit without any change on your end. Check your lookup count monthly.

check SPF record syntax

What Is DKIM and How Does It Work?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email, proving the message wasn’t tampered with in transit. RFC 6376 defines the standard. According to Google’s Transparency Report (2025), over 92% of inbound email to Gmail now carries a valid DKIM signature, up from 76% in 2019.

Where SPF checks which server sent the email, DKIM checks that the email itself hasn’t been modified. Your mail server signs outgoing messages with a private key. The receiving server retrieves your public key from DNS and verifies the signature. If someone changed the subject, body, or headers in transit, the signature breaks.

Citation capsule: DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign email headers and body content, allowing recipients to verify message integrity. According to Google’s Transparency Report (2025), 92% of inbound Gmail messages carry valid DKIM signatures, making it the most widely verified email authentication mechanism.

How DKIM signing works

When your mail server sends a message, it:

1. Selects specific headers (From, Subject, Date, MIME-Version, etc.)
2. Hashes the message body
3. Creates a signature over the headers and body hash using your private key
4. Adds a DKIM-Signature header to the message

Here’s what that header looks like in a real email:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=google;
  h=from:to:subject:date:mime-version:content-type;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AXmr8kDwLLNd0v...

The important fields:

• d= - The signing domain (your domain)
• s= - The selector (identifies which key pair was used)
• h= - Which headers were signed
• bh= - Body hash
• b= - The actual signature

Selectors and DNS records

The selector (s= value) tells the receiving server where to find the public key. If your selector is google, the receiving server looks up google._domainkey.yourdomain.com as a TXT record.

google._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a..."

The p= value is your public key. It’s a long Base64-encoded RSA or Ed25519 key. You don’t generate this manually. Your email provider (Google Workspace, Microsoft 365, etc.) gives you the record to publish.

Key rotation

DKIM keys should be rotated periodically. M3AAWG Best Practices (2024) recommends rotating DKIM keys at least every 6-12 months. The process is straightforward:

1. Generate a new key pair with a new selector (e.g., selector2)
2. Publish the new public key in DNS
3. Configure your mail server to sign with the new key
4. Keep the old public key in DNS for 7 days (messages in transit may still reference it)
5. Remove the old key

Rotation matters because private keys can be compromised. If an attacker gets your DKIM private key, they can forge perfectly signed emails from your domain until you rotate.

What Is DMARC and How Does It Work?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receivers what to do when checks fail. According to Valimail’s Email Authentication Report (2025), only 33.4% of domains with DMARC records have enforcement enabled (quarantine or reject), meaning two-thirds of DMARC adopters are running in monitor-only mode.

DMARC solves a gap that neither SPF nor DKIM addresses alone: alignment. SPF validates the envelope sender (the Return-Path), and DKIM validates the signing domain. But neither one checks whether those match the From address that humans actually see. DMARC requires that at least one of them aligns with the visible From domain.

Citation capsule: DMARC ensures the From address visible to recipients matches the domain authenticated by SPF or DKIM, a requirement called alignment. Valimail’s 2025 Email Authentication Report shows that only 33.4% of domains with DMARC records enforce a policy of quarantine or reject, leaving most domains without real protection against spoofing.

DMARC record syntax

DMARC records live at _dmarc.yourdomain.com as a TXT record:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=r; aspf=r"

Tag by tag:

• v=DMARC1 - Version. Always required, always first.
• p=reject - Policy for messages that fail alignment.
• rua= - Where to send aggregate reports (daily XML summaries).
• ruf= - Where to send forensic reports (individual failure details).
• pct=100 - Apply the policy to 100% of failing messages.
• adkim=r - DKIM alignment mode: relaxed (subdomains allowed).
• aspf=r - SPF alignment mode: relaxed.

DMARC policies compared

The policy tag (p=) is the most important decision. Here’s what each option does:

The pct tag is your safety valve during rollout. Set p=quarantine; pct=10 to quarantine only 10% of failing messages. This lets you catch misconfigurations before they affect all your mail. Increase gradually: 10%, 25%, 50%, 100%. Then move from quarantine to reject following the same ramp.

DMARC reporting

DMARC aggregate reports are XML files sent daily by receiving servers. They tell you exactly which IPs are sending email as your domain and whether those messages pass or fail authentication. You’ll want a reporting tool to parse them, raw XML is painful.

Free options include Postmark’s DMARC monitoring and Google’s Postmaster Tools. For higher volumes, paid tools like Valimail and dmarcian provide dashboards and alerting.

look up DMARC and other DNS records

How Do SPF, DKIM, and DMARC Work Together?

Each protocol handles a different piece of the authentication puzzle. None of them alone is sufficient. According to Google’s Email Sender Guidelines (2024), all three are mandatory for senders delivering over 5,000 messages per day to Gmail addresses.

Here’s how they chain together when someone receives your email:

The authentication flow works like this:

1. Your mail server sends a message. SPF authorizes the server IP. DKIM signs the content.
2. The receiving server checks SPF against your domain’s TXT record.
3. It checks the DKIM signature against the public key in DNS.
4. It checks your DMARC record. At least one of SPF or DKIM must both pass AND align with the From domain.
5. If DMARC alignment fails, the receiving server applies your DMARC policy (none, quarantine, or reject).

What does “alignment” mean in practice? If your email’s From address is user@yourdomain.com, then SPF must pass for yourdomain.com (not some other domain in the Return-Path) or DKIM must be signed by yourdomain.com. If SPF passes for bounces.mailchimp.com but DKIM is signed by yourdomain.com, DMARC still passes because DKIM aligns.

We’ve found that DKIM alignment is more reliable than SPF alignment for third-party senders. Most email services (Mailchimp, SendGrid, Brevo) let you set up custom DKIM signing on your domain, which gives you DMARC alignment automatically. SPF alignment requires the Return-Path domain to match, which third-party senders don’t always support.

How Do You Set Up SPF, DKIM, and DMARC?

Setup varies by provider, but the DNS changes follow the same pattern everywhere. According to EasyDMARC’s Global DMARC Adoption Report (2025), only 5.7 million of the roughly 350 million registered domains have published a DMARC record. That’s under 2% global adoption, meaning most domains are still unprotected.

The order matters: set up SPF first, then DKIM, then DMARC. DMARC depends on the other two, so you need them working before DMARC can evaluate alignment.

Google Workspace setup

SPF record:

yourdomain.com. IN TXT "v=spf1 include:_spf.google.com ~all"

Add this as a TXT record on your root domain. If you use other sending services, add their include directives before ~all.

DKIM setup:

1. Open Google Admin Console, go to Apps then Google Workspace then Gmail.
2. Click Authenticate email and select your domain.
3. Click Generate new record. Choose 2048-bit key length.
4. Google gives you a TXT record with a selector (default: google).
5. Add the TXT record to DNS at google._domainkey.yourdomain.com.
6. Return to Admin Console and click Start authentication.

DMARC record:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Start with p=none to collect reports. After 2-4 weeks of clean reports, move to p=quarantine, then p=reject.

Microsoft 365 setup

SPF record:

yourdomain.com. IN TXT "v=spf1 include:spf.protection.outlook.com ~all"

DKIM setup:

1. Go to the Microsoft 365 Defender portal, then Email & collaboration then Policies then DKIM.
2. Select your domain. Microsoft auto-generates two CNAME records.
3. Add both CNAMEs to DNS:

selector1._domainkey.yourdomain.com. CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com.
selector2._domainkey.yourdomain.com. CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com.

4. Return to the Defender portal and enable DKIM signing.

Microsoft uses CNAME records that point to their managed keys, rather than publishing raw public keys. This lets Microsoft handle key rotation automatically.

DMARC record: Same as above. Start with p=none.

Custom domain (self-hosted or third-party SMTP)

If you run your own mail server or use a transactional email service like SendGrid or Amazon SES, the process is similar but you handle key generation yourself.

SPF record example with multiple services:

yourdomain.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:sendgrid.net include:amazonses.com ~all"

DKIM for SendGrid:

SendGrid provides three CNAME records when you authenticate your domain. Add them to DNS and SendGrid handles signing and key management.

DKIM for self-hosted (OpenDKIM):

# Generate a 2048-bit key pair
opendkim-genkey -s mail -d yourdomain.com -b 2048

# This creates:
# mail.txt       → DNS TXT record (public key)
# mail.private   → Private key for your mail server

Publish mail.txt as a TXT record at mail._domainkey.yourdomain.com. Configure your MTA (Postfix, Exim) to sign with mail.private.

verify MX records for your domain

How Do You Test Your Email Authentication?

Testing before and after setup prevents surprises. Google Postmaster Tools (2025) shows authentication rates for your domain, and according to Google’s documentation, domains with properly configured SPF, DKIM, and DMARC see spam classification rates drop by 75% or more compared to unauthenticated domains.

Command-line DNS checks

Verify each record exists and has correct syntax:

# Check SPF
$ dig yourdomain.com TXT +short | grep spf
"v=spf1 include:_spf.google.com ~all"

# Check DKIM (replace 'google' with your selector)
$ dig google._domainkey.yourdomain.com TXT +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9..."

# Check DMARC
$ dig _dmarc.yourdomain.com TXT +short
"v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

If any of these return empty results, your records aren’t published or haven’t propagated yet.

Send a test email

The most practical test: send an email to a Gmail account and check the headers. In Gmail, open the message, click the three dots menu, and select Show original. Look for:

SPF:    PASS with IP 209.85.220.41
DKIM:   PASS with domain yourdomain.com
DMARC:  PASS

All three should show PASS. If any show FAIL or NEUTRAL, you’ve got a configuration issue.

Online testing tools

• mail-tester.com - Send an email to their test address, get a scored report with SPF, DKIM, and DMARC results.
• MXToolbox - Real-time DNS record lookups and SPF/DKIM/DMARC validation.
• Google Postmaster Tools - Ongoing monitoring of authentication rates and spam complaints for your domain.

What Are the Most Common Email Authentication Mistakes?

Misconfigurations cause more deliverability problems than missing records. According to dmarcian’s analysis (2025), approximately 35% of published SPF records contain at least one error, ranging from exceeding the lookup limit to syntax mistakes.

Here are the mistakes we see most often, in order of frequency.

Multiple SPF records on the same domain

You can only have one SPF record per domain. If you add a new one without merging it with the existing record, DNS returns both. Most receiving servers treat this as a permanent error and fail SPF entirely. Always check for existing records before adding:

$ dig yourdomain.com TXT +short | grep spf

If a record exists, modify it. Don’t create a second one.

Exceeding the 10-lookup limit

We covered this in the SPF section, but it bears repeating. Every include and a mechanism counts. Third-party records contain nested includes that you can’t see without expanding them. Use an SPF flattening service or our SPF checker tool to count total lookups.

Forgetting third-party senders before enforcing DMARC

This is the most damaging mistake. You set p=reject, and suddenly your CRM’s emails, your billing system’s invoices, and your helpdesk’s replies all get blocked. Always run p=none for at least two weeks and review aggregate reports before moving to enforcement.

Not setting up DKIM for third-party services

SPF alone isn’t enough for DMARC alignment when third-party services send on your behalf. Many services use their own Return-Path domain, which breaks SPF alignment. Custom DKIM signing is the fix. Configure it for every third-party sender.

Using p=none forever

Monitor mode is not a security policy. If you never move to quarantine or reject, attackers can spoof your domain freely and DMARC does nothing to stop them. Set a calendar reminder to review reports and escalate your policy within 90 days.

There’s a counterintuitive problem with SPF “flattening” services that resolve includes down to raw IP addresses. These services reduce your lookup count, but they create brittle records. When your email provider changes their server IPs (which happens regularly), your flattened SPF record becomes stale. If you flatten, make sure the service monitors for IP changes and updates automatically.

check SPF syntax and lookup count

Frequently Asked Questions

Do I need SPF, DKIM, and DMARC if I only send a few emails?

Yes. Volume doesn’t matter for authentication. Google’s sender guidelines apply to all senders, with stricter rules for those above 5,000 daily messages (Google Email Sender Guidelines, 2024). Even personal domains benefit. Without authentication, any attacker can send emails pretending to be you. Setup takes 15 minutes and protects you permanently.

What happens if SPF passes but DKIM fails?

Your email can still pass DMARC. DMARC requires that at least one protocol, either SPF or DKIM, both passes its check and aligns with the From domain. However, having both pass is significantly better for deliverability. According to Google’s Transparency Report (2025), messages with both valid SPF and DKIM are classified as spam at less than half the rate of messages with only one.

How do I fix “SPF PermError: too many DNS lookups”?

Count your total lookups by expanding every include chain. Each include, a, mx, and redirect mechanism counts toward the 10-lookup limit. Remove unused services, merge overlapping includes, or use SPF flattening (with automatic IP monitoring). Our SPF checker tool shows your exact lookup count and highlights which includes are the most expensive.

Can I use the same DMARC record for subdomains?

By default, DMARC applies to subdomains through the sp= tag (subdomain policy). If you don’t set sp=, subdomains inherit the p= policy. You can also publish separate DMARC records on specific subdomains to override the parent. For example, _dmarc.mail.yourdomain.com can have its own policy independent of _dmarc.yourdomain.com.

How long should I stay on DMARC p=none before enforcing?

Run p=none for a minimum of 2-4 weeks while monitoring aggregate reports. This gives you enough data to identify all legitimate sending sources. Once reports show consistent passes for all authorized senders, move to p=quarantine; pct=25 and increase gradually. According to Valimail’s data (2025), organizations that follow a phased rollout over 30-60 days achieve 95%+ enforcement success rates.

look up DNS records for your domain check your MX configuration validate SPF records