SPF vs DKIM vs DMARC: Email Authentication Explained

SPF, DKIM, and DMARC get mentioned in the same breath so often that it’s easy to blur them into one thing. They aren’t. Each does a distinct job: SPF authorizes which servers may send mail, DKIM proves a message hasn’t been tampered with, and DMARC ties both to the address your customers actually see — and sets a policy for what happens when authentication fails. This guide explains each standard with real DNS examples, how they combine, and how to roll them out safely.

Why Email Authentication Matters

SMTP, the protocol that moves email around the internet, was designed without any built-in sender verification. Anyone can connect to a mail server and claim to be invoice@yourcompany.com. Attackers exploit this to phish your customers, impersonate your executives in business email compromise scams, and damage your domain’s reputation — which quietly erodes deliverability as mailbox providers learn to distrust mail bearing your name. SPF, DKIM, and DMARC are the three open standards that let domain owners prove which mail is genuinely theirs.

What is SPF

SPF (Sender Policy Framework, RFC 7208) is a TXT record at the root of your domain listing every server authorized to send email for it. When mail arrives, the receiving server looks up the SPF record for the envelope sender domain — the invisible MAIL FROM (also called the return-path) — and checks whether the connecting server’s IP is on the list.

An example record:

v=spf1 ip4:192.0.2.10 include:_spf.google.com -all

The pieces:

• v=spf1 marks the record as SPF.
• ip4:/ip6: allow specific IPs; include: pulls in another domain’s record (your email provider’s); a and mx authorize your own servers.
• The qualifiers control the result: -all (fail — reject anything else), ~all (softfail — treat unmatched senders as suspicious), + (pass), and ? (neutral).

SPF has two well-known limits. First, it authenticates the envelope sender, not the From header — so a spammer can pass SPF for their own throwaway domain while the From field displays your brand. Second, SPF breaks when mail is forwarded, because the forwarding server’s IP isn’t in your record. There is also a hard cap of 10 DNS lookups per evaluation, and only one SPF record per domain is allowed.

What is DKIM

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to outgoing mail. Your sending service signs the message with a private key, and the signature is placed in a DKIM-Signature header. The receiving server fetches the matching public key from DNS and verifies that the message content hasn’t been altered since signing.

The public key lives in a TXT record at a selector subdomain — for example google._domainkey.example.com:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Selectors let you rotate keys and run multiple senders side by side: your mail provider signs with selector s1, your marketing platform with s2, each with its own key pair. Because the signature travels with the message, DKIM survives forwarding — which makes it the more reliable authentication method for DMARC. One nuance: DKIM authenticates the signing domain (the d= value), which must be your domain for the signature to count for you. If your email provider signs with its own domain by default, you need to switch on domain-level authentication in their settings.

What is DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the policy layer. Published as a TXT record at _dmarc.example.com, it tells receiving servers two things: which domain authentication should align with, and what to do when it doesn’t.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; sp=none; adkim=r; aspf=r

Key tags:

• p= — the policy: none (monitor only), quarantine (spam folder), or reject (drop the mail).
• sp= — a separate policy for your subdomains.
• rua= — where aggregate reports should be sent.
• adkim/aspf — alignment mode: r (relaxed — same organizational domain) or s (strict — exact match).
• pct= — apply the policy to only a percentage of failing mail during rollout.

DMARC passes when either SPF or DKIM passes and the authenticated domain aligns with the From header domain. That alignment requirement is the crucial piece SPF and DKIM lack on their own.

How They Work Together

A useful mental model: SPF is the guest list at the door — it says which servers are allowed in. DKIM is the tamper-proof ID badge — it proves a specific signer vouches for the message. DMARC is the door policy — the name on the badge must match the name on the envelope, or the message is refused.

In practice: your mail passes SPF because it left an authorized server. A forwarding hop may break SPF, but DKIM still verifies — so DMARC passes on DKIM alignment alone. An attacker’s server fails SPF and has no valid DKIM signature, so DMARC fails — and your policy tells the receiver to quarantine or reject it. Deploying all three means a forged message has to fail two independent checks to slip through, while your legitimate mail only needs one of them to succeed.

Step-by-Step DNS Setup

1. Publish your SPF record at the domain root. Merge every sender into a single record — start with ~all and switch to -all once you’re confident.

   v=spf1 include:spf.protection.outlook.com include:_spf.mailchimp.com ~all

2. Enable DKIM in each sending platform and copy the generated TXT records into DNS at the selector subdomains they specify.
3. Verify propagation with a TXT lookup before relying on either record; DNS changes can take time to spread depending on TTL.
4. Publish a monitor-only DMARC record.

   v=DMARC1; p=none; rua=mailto:dmarc@example.com

5. Wait two to four weeks and review the aggregate reports. Fix any legitimate senders that are failing, then move to p=quarantine.
6. After more clean reporting, switch to p=reject and set sp=reject (or at least sp=quarantine) so subdomains are covered too.
7. Re-check whenever you add a new sending service — every new tool changes your authentication footprint.

Testing Your Configuration

After every change, test from outside your own infrastructure:

• Send an email to a Gmail address and open Show original — you’ll see a line-by-line verdict for SPF, DKIM, and DMARC.
• Use public lookup tools (like MXToolbox) to inspect your SPF, DKIM, and DMARC records exactly as receivers see them.
• Review parsed DMARC reports for legitimate sources that fail — they’re the ones that will break when you tighten policy.
• Our free DNS security checker verifies that SPF, DKIM, and DMARC records are present and well-formed for your domain.
• Remember TTL: after a DNS edit, wait for the old record to expire before judging the result.

Conclusion

Email authentication is not optional plumbing — it is the difference between a domain that spoofers can impersonate and one they can’t. SPF and DKIM build the foundation; DMARC turns it into an enforceable policy with visibility into everything that sends as you. Roll out in stages, watch the reports, and you’ll reach a reject policy that protects your customers, your staff, and your deliverability — without breaking a single legitimate message.