The protocol that trusts the sender by default

Email was designed in an era when nobody lied about who they were, and it shows. By default, the "From" address on a message is just text the sender types — there is nothing in the base protocol that checks whether the person sending mail "from" your domain has any right to. That single design choice is why phishing and invoice fraud work so well: an attacker can send a perfectly formatted email that claims to come from your CEO, your billing system, or your support desk, and the recipient's mail server has no built-in reason to doubt it.

Email authentication is the set of three DNS-published standards that close this gap — SPF, DKIM, and DMARC. Together they let a receiving server answer the question the base protocol can't: did this message really come from a system the domain owner authorized? Getting all three right is one of the highest-leverage, lowest-cost hardening steps a domain owner can take, and it directly shrinks the external attack surface your own brand presents to the world.

SPF: which servers are allowed to send

SPF (Sender Policy Framework) is a DNS record listing the IP addresses and services permitted to send mail for your domain. When a receiving server gets a message, it checks the sending IP against that published list. If the sender isn't on it, the message fails SPF.

  • It authenticates the envelope, not the visible From. SPF validates the hidden return-path address, which is why it can't stand alone — an attacker can pass SPF on a domain they control while still spoofing the From header a human reads.
  • It breaks on forwarding. When mail is forwarded, the sending IP changes, and a strict SPF check can fail legitimate mail. This is a real operational constraint, not a reason to skip it.
  • It has a hard limit. SPF allows only ten DNS lookups; sprawling records that chain through every SaaS vendor silently exceed it and fail. Keep the record lean and reviewed.

DKIM: a signature that proves the message wasn't forged

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message, using a private key held by your sending infrastructure and a public key published in your DNS. The receiver verifies the signature against the published key. A valid signature proves two things: the message genuinely originated from a system holding your key, and the signed parts weren't altered in transit.

DKIM survives forwarding where SPF doesn't, because the signature travels with the message rather than depending on the connecting IP. But like SPF, on its own it doesn't tie the verified identity back to the From address a person actually sees — and its strength depends entirely on guarding the signing key, the same key-management discipline that decides whether any cryptographic control means anything.

DMARC: the policy that ties it together and tells you what's happening

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the keystone. It does two things SPF and DKIM can't do alone:

  • It aligns authentication with the visible From. DMARC requires that a passing SPF or DKIM result actually match the domain in the From header the recipient sees. This is what finally defends the address a human reads, closing the gap the other two leave open.
  • It publishes a policy and a feedback loop. Your DMARC record tells receivers what to do with mail that fails — p=none (monitor only), p=quarantine (send to spam), or p=reject (refuse outright) — and requests aggregate reports showing every source sending mail as your domain.

That reporting is the part most teams underuse. DMARC reports are a discovery tool: they reveal forgotten marketing platforms, a billing service nobody documented, and the attacker actively spoofing you — the same outside-in visibility that makes asset inventory honest, applied to your email senders.

The step everyone skips: getting to enforcement

Here is the trap. The overwhelming majority of domains publish a DMARC record at p=none — monitoring only — and stop there. A p=none policy provides reports but blocks nothing; an attacker can still spoof you freely. Visibility without enforcement is a dashboard, not a defense.

The reason teams stall is legitimate fear: flip straight to p=reject with a misconfigured sender and you'll bounce your own newsletters and password resets. The disciplined path is a staged rollout:

  1. Start at p=none and read the aggregate reports until you can account for every legitimate sender.
  2. Authenticate each real sender — bring every marketing, billing, and support platform under SPF and DKIM with proper alignment.
  3. Move to p=quarantine, watch for collateral damage, then advance to p=reject. Reject is the only policy an attacker actually feels.

This is configuration that drifts: a new SaaS tool gets added next quarter and silently fails alignment, exactly the posture drift that erodes controls over time. Treat your DMARC reports as a monitored signal, so a new unauthenticated sender surfaces as a finding in your findings workflow — and so the answer you give on a security questionnaire about email spoofing protection reflects what's actually enforced, not what's merely published.

SPF says which servers may send, DKIM proves a message wasn't forged, and DMARC ties both to the name your customers actually read — then tells you who's abusing it. Published at p=reject and watched continuously, the three together take "anyone can email as you" off the table.