Email Authentication: SPF, DKIM, and DMARC Explained

Why Email Authentication Matters

Email was designed in an era of trust. The original SMTP protocol had no built-in mechanism to verify that the sender of a message is who they claim to be. Anyone could set up an SMTP server, claim to be [email protected], and send messages that looked completely legitimate. This design flaw is the foundation of phishing, spoofing, and business email compromise attacks that cost organizations billions annually.

Email authentication fixes this by adding DNS-based verification layers. Three complementary protocols — SPF, DKIM, and DMARC — work together to let receiving mail servers verify that incoming messages genuinely originated from authorized servers. Together, they form a defense that, when properly configured, eliminates nearly all domain spoofing.

Beyond security, email authentication directly affects deliverability. Gmail, Outlook, and Yahoo now require SPF, DKIM, and DMARC for bulk senders. Without them, your legitimate emails land in spam folders — or are rejected entirely.

SPF (Sender Policy Framework)

SPF is the simplest authentication method. It's a DNS TXT record that lists the IP addresses and servers authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourdomain.com, it checks your SPF record. If the sending server's IP is listed, the message passes SPF.

A basic SPF record looks like this:

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

Breaking down the syntax:

• v=spf1 — Required version identifier. Must be the first mechanism.
• include:_spf.google.com — Include Google's SPF record (if you use Google Workspace). The receiver follows this reference and authorizes Google's IPs.
• include:mailgun.org — Include Mailgun's sending servers. Each include can reference another domain's SPF record.
• ip4:192.0.2.0/24 — Authorize a specific IP range. Use for your own mail servers.
• ~all — "Soft fail" for everything else. Messages from unauthorized IPs are marked but still delivered. Use during testing.
• -all — "Hard fail." Messages from unauthorized IPs should be rejected. This is the production goal.
• ?all — "Neutral." No policy. Effectively no protection. Don't use this.

SPF limits: DNS lookups are limited to 10 per SPF evaluation. If your record chains through too many include statements, receivers stop evaluating and return "permerror." Keep your includes under 10, and flatten if necessary.

The SPF forwarding problem: When email is forwarded (e.g., a university alumni address forwarding to Gmail), the forwarding server's IP isn't in your SPF record. SPF breaks on forwarded mail. This is why DKIM exists — it survives forwarding because the signature is in the email headers, not tied to the connecting IP.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing emails. The sending mail server signs specific headers and the email body using a private key. The public key is published in DNS. The receiving server retrieves the public key, verifies the signature, and confirms the email wasn't tampered with in transit.

A DKIM DNS record looks like this:

selector._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

The selector is a label you choose — it lets you rotate keys without downtime. Multiple selectors can coexist, allowing gradual key transitions. The p= value is the base64-encoded public key.

Key points about DKIM:

• What gets signed: The From, Subject, Date, and other headers, plus a hash of the body. If any signed header or the body is modified in transit, the signature fails.
• Not all mail needs signing: Some mail flows (transactional, marketing) sign everything. Internal-only mail may skip DKIM. But for maximum protection, sign all outgoing mail.
• Key rotation: Rotate DKIM keys annually or after any suspected compromise. Publish the new key under a new selector, switch your mail server to sign with it, then remove the old selector after a transition period.
• Relaxed vs Strict: The d= tag in the DKIM signature specifies the signing domain. d=yourdomain.com with a matching From: @yourdomain.com header is "aligned." This alignment is required for DMARC to pass.

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

DMARC ties SPF and DKIM together and adds a policy enforcement layer. It answers the question: "What should the receiver do if SPF or DKIM fails?" Without DMARC, receivers make their own decisions — some quarantine, some deliver with a warning, some silently drop. DMARC lets you specify the policy.

A DMARC record looks like this:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=50; adkim=s; aspf=s"

Breaking down the tags:

• p=quarantine — Policy. none (monitor only), quarantine (send to spam), or reject (block entirely). Always start with none.
• rua=mailto:[email protected] — Aggregate reports emailed to this address. Receivers send daily XML reports showing which messages passed/failed authentication and why. Essential for monitoring.
• ruf=mailto:[email protected] — Forensic reports with message samples. Optional, and some receivers don't send them for privacy reasons.
• pct=50 — Apply the policy to 50% of failing messages. Use for gradual rollout: start at 1%, increase to 5%, 25%, 50%, 100%.
• adkim=s — Strict DKIM alignment. The DKIM signing domain must exactly match the From header domain. Use adkim=r for relaxed (subdomain match).
• aspf=s — Strict SPF alignment. The envelope-from (MAIL FROM) domain must exactly match the From header domain.
• sp=quarantine — Subdomain policy. Apply this policy to subdomains separately from the apex domain.

The DMARC Rollout Process

Never deploy DMARC in p=reject mode immediately. You'll block legitimate mail. Follow this phased approach:

Phase 1 — Monitor (p=none): Deploy DMARC with p=none and a rua report address. Collect daily aggregate reports for 2-4 weeks. These reports show you every sender using your domain, including third-party services you forgot about (marketing platforms, billing systems, CRM tools).

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Phase 2 — Identify and fix: Analyze the reports. Identify all legitimate senders. Add missing ones to SPF. Ensure all senders sign with DKIM. Fix alignment issues (e.g., a third-party sender using their domain in the envelope-from without proper DKIM alignment).

Phase 3 — Quarantine (p=quarantine, pct=1): Switch to quarantine mode at 1%. Monitor for complaints about missing emails. If clean, increase: 5%, 25%, 50%, 100%.

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25

Phase 4 — Reject (p=reject, pct=100): After 4-8 weeks of clean quarantine at 100%, switch to reject. Spoofed email is now blocked at the receiver level.

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Common Configuration Mistakes

• SPF with too many includes: Each include is a DNS lookup. If you chain through 15 services, receivers hit the 10-lookup limit and fail closed. Use SPF flattening services (DMARC Digest, EasyDMARC) if you have many providers.
• DMARC reject on day one: Guaranteed to break legitimate mail flow. Always start with p=none.
• Missing DKIM alignment: If your ESP signs with d=sendgrid.net but your From is @yourdomain.com, DMARC fails alignment. Configure your ESP to sign with your domain.
• Not handling subdomains: Set sp= explicitly. Otherwise, subdomains inherit the apex policy, which may quarantine legitimate subdomain senders.
• Ignoring reports: DMARC reports are gold mines of information. Set up automated parsing (dmarcian, UriPort, EasyDMARC) to visualize sender patterns and catch unauthorized use early.

Verifying Your Setup

Once configured, verify with these DNS lookups:

• Check SPF: dig TXT yourdomain.com — Look for v=spf1 record
• Check DKIM: dig TXT selector._domainkey.yourdomain.com — Verify the public key is published
• Check DMARC: dig TXT _dmarc.yourdomain.com — Verify the policy is active

Send a test email to mail-tester.com or [email protected] for a comprehensive authentication report. These services show you exactly what a receiving server sees.

Use our DNS Lookup tool to verify your SPF, DKIM, and DMARC records are published correctly.