SPF, DKIM, and DMARC Explained:
Why Your Emails Are Landing in Spam

Your email is sent. It doesn't bounce. But it never arrives in the inbox either — it's sitting in the spam folder of someone who actually wanted to hear from you. Or worse, it's being used by scammers who have figured out they can send email that claims to be from your domain, because you never set up the authentication records that would stop them.

SPF, DKIM, and DMARC are three DNS records that sit between your emails and either the inbox or the spam folder. Together they verify that emails claiming to come from your domain actually do come from your domain — and they tell receiving servers what to do with ones that don't.

In February 2024, Google and Yahoo started requiring all three for bulk senders. But even if you're not a bulk sender, missing any of these records is a deliverability handicap that makes every email you send slightly more suspicious to spam filters. This guide will explain how each one works, how to set them up correctly, and what happens when you get them wrong.

1. Why email authentication exists

Email was designed in an era when the internet was a small, trusted network and nobody was thinking about adversaries. The original SMTP protocol has essentially zero authentication built into it. When a mail server says “I am sending this email on behalf of example.com,” there is nothing in SMTP itself that verifies this claim. Any server on the internet can send an email claiming to be from any domain it wants.

This is how phishing works. This is how business email compromise (BEC) attacks work — someone sends an email that appears to come from your CEO's domain, asking someone in finance to wire money, and the email looks completely legitimate because there's nothing in the protocol to prevent the sender from claiming any identity they want.

SPF, DKIM, and DMARC are the industry's solution to this — retrofitted onto the email infrastructure over the past two decades. They don't change SMTP itself, but they add a verification layer using DNS that lets receiving servers check claims about who sent an email.

2. SPF — authorizing your sending IPs

SPF, which stands for Sender Policy Framework, is the simplest of the three to understand. You publish a DNS TXT record at your root domain listing all the IP addresses and services that are authorized to send email on your behalf. When a receiving server gets an email from your domain, it looks up your SPF record and checks whether the IP address of the sending server is on the authorized list.

A basic SPF record in DNS looks like this:

Host:  @
Type:  TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~all

Breaking this down:

• v=spf1 — declares this is an SPF record, version 1.
• include:_spf.google.com — authorizes all Google Workspace mail servers. The include: mechanism tells the receiver to also check the SPF record at that domain and include its IPs.
• include:sendgrid.net — authorizes SendGrid as a sending service (used for transactional email).
• ip4:203.0.113.0/24 — authorizes a specific IP range (e.g., your own server).
• ~all — the qualifier. A tilde means “softfail” — emails from unauthorized IPs should be treated with suspicion but not outright rejected. Use -all (hardfail) when you're confident your list is complete. Never use +all — it authorizes every server on the internet.

The 10-lookup limit

SPF has a hard limit of 10 DNS lookups during evaluation. Every include:, a:, mx:, and redirect= each count as a lookup, and nested includes count too. If your SPF record requires more than 10 DNS lookups to evaluate, receivers are allowed to fail the check immediately — which means legitimate emails get flagged. This is a common problem for organizations that use many email services (Mailchimp, HubSpot, Intercom, Zendesk, plus their email provider). The fix is to use SPF flattening tools that resolve all the includes to explicit IP ranges, eliminating the lookup chain.

SPF's critical weakness: email forwarding

SPF fails silently whenever an email is forwarded. Here's why: when someone at gmail.com forwards your email to their hotmail.com account, Gmail's servers resend the email to Hotmail. Hotmail checks SPF and sees: the email claims to be from your domain, but it arrived from Gmail's IP addresses, which aren't in your SPF record. SPF fails. This is not a misconfiguration — it's a fundamental limitation of how SPF works. This is one of the key reasons DKIM was created.

3. DKIM — cryptographic signing

DKIM (DomainKeys Identified Mail) solves the forwarding problem by signing the email itself rather than checking where it came from. When your mail server sends an email, it generates a cryptographic hash of the email content (including certain headers and the body) and signs that hash with a private key that only your server knows. The signature is added to the email as a DKIM-Signature header.

The corresponding public key is published in DNS under a special subdomain format:

Host:  selector._domainkey.yourdomain.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

The selector part is just a label — it lets you have multiple DKIM keys simultaneously (useful when rotating keys or using multiple mail providers). Google Workspace uses google._domainkey. Mailchimp uses k1._domainkey. SendGrid often uses s1._domainkey and s2._domainkey.

Why DKIM survives forwarding

When Gmail forwards your email to Hotmail, the DKIM signature your server created is still in the email. Hotmail looks up your public key from DNS and verifies the signature — it checks out, because the email content and headers that were signed haven't changed. The fact that Gmail's servers were the ones that forwarded it doesn't matter. The signature proves the email originally came from a server that held your private key.

How to set up DKIM

The process for enabling DKIM depends on your email provider:

• Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Google generates the key pair. You copy the TXT record value to your DNS.
• Microsoft 365: Security & Compliance center → Threat management → Policy → DKIM. Enable DKIM for your domain and add the two CNAME records to DNS.
• SendGrid: Settings → Sender Authentication → Domain Authentication. SendGrid generates CNAME records for you to add to DNS — they manage the actual key and signing.
• Self-hosted mail (Postfix, etc.): Install opendkim, generate a key pair with opendkim-genkey, and publish the public key to DNS manually.

4. DMARC — the policy and reporting layer

DMARC doesn't verify emails itself. Instead, it defines what should happen when SPF or DKIM verification fails, and it gives you a way to receive reports about what's happening with email sent using your domain.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

Host:  _dmarc.yourdomain.com
Type:  TXT
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r

Understanding the tags:

• p= — the policy. none means monitor only, quarantine means send to spam, reject means block.
• rua= — aggregate report email address. You'll receive daily XML reports summarizing authentication results.
• ruf= — forensic report email. Receive reports for individual failing messages. Not all receivers send these.
• pct= — percentage of failing emails the policy applies to. Start with pct=10 or pct=100 — intermediate values are generally not recommended.
• adkim= — DKIM alignment mode. r (relaxed) allows subdomains; s (strict) requires exact domain match.
• aspf= — SPF alignment mode. Same options as adkim.

What DMARC alignment means

This is where things get subtle. DMARC doesn't just check that SPF passes or DKIM passes — it checks that they pass in alignment with the domain in the From header.

For SPF alignment: the domain in your Return-Path header (which SPF checks) must match your From header domain. For DKIM alignment: the domain in the DKIM signature'sd= tag must match the From header domain.

This matters because DMARC was designed specifically to prevent the attack where a scammer passes SPF by sending from their own domain's legitimate server, while putting your domain in the From header. Without alignment, that attack works: SPF passes (for their domain) but the email claims to be from your domain. With DMARC alignment, that attack fails because the SPF domain and the From domain must match.

5. Setting up all three, in the right order

Order matters. You should never set an enforcing DMARC policy before SPF and DKIM are working correctly, or you'll start blocking legitimate emails.

6. Common problems and how to diagnose them

SPF failures

“SPF FAIL” — email server not in SPF record:A service you use to send email isn't included in your SPF record. Check your DMARC reports to find which IP addresses are sending email from your domain and ensure they're authorized.

PermError — too many DNS lookups: Your SPF record exceeds the 10-lookup limit. Use a tool like MXToolbox SPF lookup to count your lookups. The fix is SPF flattening — resolving all includes to IP addresses.

Multiple SPF records: You can only have one SPF TXT record per domain. If you have two, evaluation fails with PermError. Merge them into a single record.

DKIM failures

DKIM signature verification failed: The email content was modified in transit. Common causes: mailing list software adding footers, content rewriting by spam filters, or line ending conversion. Usually not something you can fix — but DMARC in relaxed alignment mode will fall back to SPF.

DKIM selector not found in DNS:The selector in your DKIM-Signature header doesn't match any published TXT record. Either you haven't published the DKIM record yet, or there's a selector mismatch between your mail server configuration and DNS.

DMARC alignment failures

SPF passes but DMARC fails:Your Return-Path domain doesn't match your From domain. This happens when you use a third-party sending service and they use their own Return-Path domain. Fix: configure the service to use a custom Return-Path on your domain (most services support this — it's called custom envelope domain or bounce domain).

7. Testing your configuration

After setting up your records, verify them using these approaches:

SEOCheckPilot DNS Checker: The DNS & Email Security checker validates your SPF record syntax, checks your DMARC policy, and probes 18 common DKIM selectors to find your configured keys — all in one place without manually querying DNS.

MXToolbox Email Header Analyzer: Send a test email to a Gmail or Outlook account, view the raw message headers (Show original in Gmail), and look for the Authentication-Results header. It will show you whether SPF, DKIM, and DMARC passed or failed and with what result.

Mail-tester.com: Send an email to a unique address provided by mail-tester.com, and it scores your email on deliverability factors including authentication, spam content, blacklist status, and more.

# What you want to see in Gmail's Authentication-Results header:
Authentication-Results: mx.google.com;
   dkim=pass [email protected] header.s=google header.b=abc123;
   spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender) [email protected];
   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Frequently asked questions

The short version

SPF says which servers can send email for your domain. DKIM proves an email was signed by your server and wasn't tampered with. DMARC says what to do when they fail and gives you visibility into who is sending email using your domain name.

Set up SPF and DKIM first. Then add DMARC at p=none and read the reports. Fix any legitimate sending sources that aren't passing. Then move to p=quarantine and eventually p=reject. The whole process takes a few weeks but once it's done, your domain is significantly more protected against spoofing and your emails are meaningfully more likely to reach the inbox.