SPF, DKIM, and DMARC Explained: Email Authentication in Plain English

Email was invented in the 1970s without any built-in way to verify who sent a message. Anyone could (and still can) send an email claiming to be from any address. This is why phishing and email spoofing remain so effective.

Email authentication protocols — SPF, DKIM, and DMARC — were developed to solve this problem. Together, they let receiving mail servers verify that an email genuinely came from the domain it claims to be from. Since 2024, Google and Yahoo have made these protocols mandatory for bulk senders, but they benefit everyone sending email.

SPF (Sender Policy Framework)

A DNS TXT record that lists which mail servers are authorized to send email for your domain. Receiving servers check whether the sending IP is on the authorized list. Defined in RFC 7208.

DKIM (DomainKeys Identified Mail)

A cryptographic signature added to outgoing email headers. The sending server signs with a private key; receiving servers verify using the public key published in DNS. Proves the email wasn't tampered with in transit. Defined in RFC 6376.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

A policy layer that sits on top of SPF and DKIM. It requires the visible From: domain to align with SPF or DKIM results, specifies what to do with failures (none/quarantine/reject), and enables aggregate reporting. Defined in RFC 7489.

Think of SPF as a guest list for your domain's email. It's a DNS record that says: "These mail servers are authorized to send email on behalf of my domain. Reject (or flag) anything from servers not on this list."

An SPF record looks like this: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all

This record says: "Google's servers, SendGrid's servers, and the IP 203.0.113.5 are authorized. Reject everything else (-all)."

Key rules: - Only one SPF record per domain (multiple records cause failures) - Maximum 10 DNS lookups (each 'include' counts as one) - End with -all (hard fail) or ~all (soft fail) - Include every service that sends email on your behalf

DKIM is like a tamper-evident seal on your emails. When your mail server sends an email, it creates a digital signature using a private key. This signature is added to the email's headers.

The receiving server looks up your public key in DNS and uses it to verify the signature. If the email was modified in transit (even by one character), the signature won't match and DKIM fails.

DKIM records live at: selector._domainkey.yourdomain.com

Each email service uses its own selector. Google Workspace uses 'google', Microsoft 365 uses 'selector1' and 'selector2', and services like SendGrid have their own.

What DKIM proves: - The email came from an authorized sender - The email body and key headers weren't modified in transit - The domain owner authorized this specific sending service

DMARC is the enforcement layer. It tells receiving servers: "Here's what to do when an email claiming to be from my domain fails SPF and DKIM checks."

DMARC also introduces the concept of alignment — the domain in the From: header must match the domain used in SPF and DKIM checks. This prevents attackers from passing SPF/DKIM with their own domain while spoofing yours in the visible From: address.

DMARC policies: - p=none: Monitor only. Failed emails still get delivered. You receive reports. - p=quarantine: Failed emails go to spam/junk. - p=reject: Failed emails are blocked entirely.

A starter DMARC record: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

The rua tag tells servers where to send aggregate reports. The fo=1 tag requests failure reports for deeper analysis.

These three protocols form a chain of trust:

1. SPF verifies the sending server is authorized 2. DKIM verifies the message hasn't been tampered with 3. DMARC checks that SPF and/or DKIM pass with domain alignment, then enforces your policy

For an email to pass DMARC, it needs to pass either: - SPF check AND SPF alignment (the envelope sender domain matches the From: domain), OR - DKIM check AND DKIM alignment (the DKIM signing domain matches the From: domain)

This is why setting up both SPF and DKIM is important — if one fails, the other can still provide DMARC alignment. Relying on only one creates a single point of failure.

1. Multiple SPF records: You can only have one SPF TXT record per domain. Having two causes both to fail.

2. Too many DNS lookups in SPF: The 10-lookup limit is strict. Each include:, a:, mx:, and redirect= counts. Use ip4: and ip6: mechanisms (which don't count) where possible.

3. Forgetting third-party senders: If you use Mailchimp, HubSpot, SendGrid, or any other service to send email, they must be included in your SPF record and have DKIM set up.

4. Jumping straight to p=reject: Always start DMARC at p=none and monitor reports for at least 2-4 weeks. Going straight to reject can block your own legitimate emails if authentication isn't fully configured.

5. Not monitoring after setup: DNS records can break due to changes, expired keys, or provider migrations. Set up continuous monitoring to catch issues before they impact deliverability.

After configuring SPF, DKIM, and DMARC, validate everything:

1. Check your SPF record for syntax errors and lookup counts using an SPF checker tool 2. Verify DKIM signing by sending a test email and checking the DKIM-Signature header 3. Validate your DMARC record syntax and policy with a DMARC checker tool 4. Send test emails to Gmail, Outlook, and Yahoo — check the email headers for authentication results 5. Set up ongoing monitoring to catch any future issues

A comprehensive email deliverability tool can check all three records at once and alert you to any misconfigurations.