Email was designed in the early 1980s for a network of trusted institutions. Authentication wasn't part of the original specification — there was simply no mechanism to verify that a message claiming to come from a given address actually did. For decades, that gap was a nuisance. Today it's an active attack surface exploited by spammers, phishers, and business email compromise campaigns at industrial scale.

SPF, DKIM, and DMARC are the three standards that collectively close that gap. They're frequently mentioned together, often confused for one another, and rarely all three deployed correctly. Here's what each one actually does — and why you need all three.

SPF: Sender Policy Framework

SPF answers one question: is this sending IP address authorized to send mail for this domain? It works through a DNS TXT record published at the domain's root. When a receiving mail server accepts an inbound SMTP connection, it looks up the SPF record of the domain in the envelope sender (the MAIL FROM address, not the visible From header) and checks whether the connecting IP is listed.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.42 -all

Breaking that down: v=spf1 identifies it as an SPF record. The include: directives pull in the authorized IP ranges for Google Workspace and SendGrid. ip4:203.0.113.42 adds a specific IP directly. The -all at the end is a hard fail directive — any IP not matched by the record should be rejected.

Common SPF qualifiers you'll see:

  • -all — Hard fail: reject mail from unlisted IPs
  • ~all — Soft fail: accept but mark mail from unlisted IPs (common but weak)
  • ?all — Neutral: no policy at all (essentially useless)
  • +all — Pass everything (never use this)

SPF's critical limitation is that it only checks the envelope sender — the address used in the SMTP handshake — not the From: header that users actually see in their email client. A spoofed message can pass SPF while displaying a completely different, fraudulent sender address to the recipient. This is precisely why SPF alone is insufficient.

DKIM: DomainKeys Identified Mail

DKIM solves a different problem: it cryptographically proves that a message was authorized by and hasn't been altered since it left the sender's infrastructure. Instead of checking IPs, it uses public-key cryptography.

When you configure DKIM for your domain, you generate an asymmetric key pair. The private key lives on your mail server (or your email provider's servers). The corresponding public key is published as a DNS TXT record under a selector subdomain. Every outbound message gets a DKIM-Signature header added, which contains a hash of specified message headers and body, signed with the private key.

The DNS record for a DKIM public key looks like this:

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The selector (mail in this case) is chosen by the sender and referenced in the DKIM-Signature header so receivers know which DNS record to look up. When a receiving server validates the signature, it fetches the public key, verifies the hash, and confirms two things: the message was sent by someone who holds the private key for this domain, and the signed portions of the message haven't been modified in transit.

DKIM survives mail forwarding better than SPF does, because it travels with the message rather than depending on the sending IP. However, DKIM alone doesn't tell receivers what to do with a message that fails validation — it just provides a pass/fail signal. That's where DMARC comes in.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

DMARC is the policy layer that ties SPF and DKIM together and actually lets domain owners specify consequences for authentication failures. It adds two critical things that neither SPF nor DKIM provides on their own:

  1. Alignment checking: DMARC requires that SPF or DKIM (or both) pass in a way that aligns with the From: header domain — the address users actually see. This closes the spoofing gap SPF leaves open.
  2. Policy enforcement: DMARC lets domain owners instruct receivers to quarantine or reject mail that fails authentication, rather than leaving that decision entirely to the receiver's discretion.

A DMARC record is also a DNS TXT record, published at _dmarc.yourdomain.com:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; pct=100; adkim=s; aspf=s"

The key fields:

  • p=quarantine — Policy: quarantine (send to spam folder) messages that fail DMARC. Use p=reject for the strictest enforcement, or p=none to monitor without enforcing.
  • rua= — Aggregate report destination: daily XML reports from receivers showing authentication outcomes across all mail from your domain.
  • ruf= — Forensic report destination: copies of individual failed messages (not all receivers send these).
  • pct=100 — Apply this policy to 100% of messages (you can ramp up gradually with lower values).
  • adkim=s — Strict DKIM alignment: the signing domain must exactly match the From domain.
  • aspf=s — Strict SPF alignment: the MAIL FROM domain must exactly match the From domain.
Why DMARC requires both SPF and DKIM to be useful: DMARC passes if either SPF or DKIM passes with alignment. If you only have SPF, a forwarder that relays your mail through a different IP will cause SPF to fail, potentially causing DMARC to fail too — even for legitimate forwarded mail. DKIM survives forwarding because the signature travels with the message. Having both gives you redundancy.

What Happens When Each One Fails

It's worth being specific about what each failure actually means in practice:

SPF failure: The connecting IP isn't in the domain's SPF record. Without DMARC, receivers may accept the message, reject it, or flag it — entirely at their discretion. With DMARC policy set, SPF failure contributes to a DMARC evaluation, but DKIM passing can still save the message.

DKIM failure: The signature didn't verify — either the message was tampered with in transit, the private key has changed since the record was published, or the message was sent by infrastructure that doesn't have access to the private key. Again, without DMARC, the consequence is receiver-specific. With DMARC, SPF passing with alignment can still save the message.

DMARC failure: Neither SPF nor DKIM passed with alignment against the From domain. Now the domain owner's stated policy applies: none (monitor only), quarantine, or reject. Only with p=reject is mail actively turned away.

Getting All Three Set Up

The right deployment sequence is SPF first, then DKIM, then DMARC starting at p=none.

Start with SPF. List every service that legitimately sends mail as your domain: your mail server, your marketing platform, your CRM, your support tool. Use -all once you're confident the list is complete. Be aware that SPF records have a 10 DNS lookup limit — if you have many include: directives, you may need to flatten them.

Configure DKIM through your mail provider or server. Most hosted providers (Google Workspace, Microsoft 365) have DKIM generation built into the admin console. The hard part is making sure every sending service you use has its own DKIM configuration, because unsigned mail from those services will fail DKIM even if SPF passes.

Deploy DMARC at p=none with aggregate reporting enabled. Run it for two to four weeks and review the reports — tools like dmarcian, Postmark's DMARC digests, or even raw XML parsing will show you exactly which sources are sending as your domain and how they're authenticating. Fix gaps before moving to p=quarantine, then eventually to p=reject.

The goal state is p=reject with both SPF and DKIM passing for all legitimate sending sources. At that point, anyone attempting to send fraudulent mail claiming to be from your domain will be rejected outright by every receiver that honors DMARC policy. It doesn't eliminate phishing entirely — attackers can register lookalike domains — but it closes the easiest and most common spoofing path completely.