SPF, DKIM and DMARC Explained: Stop Other People Sending Email as You

The problem: From: is just a text field

SMTP, designed in 1982, lets any server put anything in the From: header. Without authentication, "mail from ceo@yourcompany.com" is a claim anyone can make — which is why invoice fraud and phishing lean so hard on spoofed sender addresses. SPF, DKIM and DMARC are DNS records that let receiving servers verify the claim.

SPF: who may send for your domain

A TXT record listing authorized sending sources:

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

Receivers check the connecting server's IP against the list. The final mechanism matters: -all (hard fail) says reject everything else; ~all (soft fail) says treat it suspiciously; ?all and the catastrophic +all effectively authorize anyone.

Common SPF mistakes:

• More than 10 DNS lookups. The spec caps mechanism lookups at 10; beyond it, SPF returns a permanent error and effectively stops working. Every include: costs lookups, and third-party services nest them — this breaks silently as you add vendors.
• Stale includes from services you stopped using, quietly keeping an old vendor (and everyone on their shared IPs) authorized to send as you.
• SPF alone. SPF checks the invisible envelope sender, not the From: header users see — and it breaks on forwarding. Alone, it stops very little; that is DMARC's job.

DKIM: a signature on every message

Your sending service signs each message with a private key; the public key sits in DNS at selector._domainkey.yourdomain.com. Receivers verify the signature, proving the message body and headers were not altered and that it came from someone holding the key. DKIM survives forwarding (unlike SPF), which makes it the sturdier of the two authentication legs. Mistakes are rarer: mostly unrotated old keys, 1024-bit keys where 2048 is expected, and vendors signing with their own domain instead of yours — which brings us to alignment.

DMARC: the enforcement layer

SPF and DKIM each pass or fail, but neither is tied to the From: address the human reads. DMARC adds that link — alignment: the domain that passed SPF or DKIM must match the From: domain. A TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r

• p=none — monitor only; receivers just send you reports.
• p=quarantine — failing mail goes to spam.
• p=reject — failing mail is refused. This is the setting that actually stops spoofing.

The rua address receives aggregate XML reports showing who is sending as your domain and whether they authenticate — how you discover the payroll system nobody mentioned before you turn on enforcement.

The safe path to p=reject

1. Publish p=none with reporting and read the reports for a few weeks (a report-parsing service helps; raw XML is grim).
2. Fix every legitimate sender the reports reveal — add missing includes, enable DKIM signing with your domain at each vendor.
3. Step up to p=quarantine, optionally with pct= to ramp gradually.
4. Land on p=reject and leave reporting on: it is your ongoing view of spoofing attempts and vendor drift.

Since 2024, Gmail and Yahoo require DMARC (at least p=none) for bulk senders, and Microsoft followed for high-volume mail in 2025 — deliverability, not just security, now depends on this stack.

Don't forget the domains that send no mail

Parked and secondary domains are favorite spoofing targets precisely because nobody watches them. For any domain that should never send mail, publish v=spf1 -all, an empty DKIM policy, and p=reject — three records that make the domain useless to spoofers.

Keep watching the records

Email authentication is configuration, and configuration drifts: a vendor migration edits SPF, a broad include sneaks in, a DMARC policy gets loosened "temporarily." Because these are public DNS records, drift is externally observable — checking that SPF stays within its lookup budget, DMARC stays at enforcement, and nothing quietly broadened is part of what continuous external monitoring (Bastion included) watches on every scan.

Frequently asked questions