The short answer
SPF publishes the list of servers allowed to send mail for your domain. DKIM puts a cryptographic signature on each message. DMARC ties both to the From address users see and tells receivers what to do when checks fail: deliver, quarantine or reject. All three live in DNS as TXT records, and you deploy them in exactly that order.
Why receivers stopped trusting the From header
SMTP was designed in an era when forging a sender address was considered a feature. Anyone can put anything in the From header, the protocol does not care, and for decades phishing built its business on that. The trio of SPF, DKIM and DMARC is the retrofit: three DNS records that let a receiving server ask “should I believe this message really comes from that domain?”
The stakes stopped being theoretical for senders in February 2024, when Google and Yahoo started requiring authentication for anyone sending bulk mail to their users, DMARC record included. Fail to publish the records and your newsletters land in spam or get rejected at the door, regardless of how clean your content is. Deliverability is now an infrastructure property.
Receiving server checks DNS
SPF: the guest list
SPF is a TXT record on your domain that enumerates the servers allowed to send
mail claiming to be you. A typical record reads
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all:
Google Workspace may send, Mailchimp may send, treat everyone else with
suspicion. The receiving server checks the connecting IP against that list
during the SMTP conversation.
Two traps cost real debugging hours. First, the lookup limit: RFC 7208 allows at most 10 DNS lookups per evaluation, includes count recursively, and a record that exceeds the budget returns a permanent error. Audit yours with a DNS lookup on the TXT record and count what each include pulls in. Second, the scope: SPF validates the envelope sender (the bounce address), not the From header your users see. A message can pass SPF while displaying a completely forged From line, which is precisely the hole DMARC exists to close.
Forwarding breaks SPF by design: the forwarder’s IP is not on your list. That is not a bug to fix in SPF; it is the reason DKIM exists.
DKIM: the tamper-evident signature
DKIM signs selected headers and the body of each outgoing message with a
private key; the matching public key sits in DNS at
selector._domainkey.yourdomain.com. Any receiver can fetch the
key and verify that the message was signed by your infrastructure and has not
been modified since. Because the signature travels inside the message, it
survives forwarding, which SPF does not.
Operationally, DKIM is the easiest of the three: your mail provider generates the keys, you publish one CNAME or TXT record per selector, you flip the switch. Use 2048-bit keys (1024 is legacy), and rotate selectors when staff with access to the signing infrastructure leave. The one self-inflicted wound to avoid: mailing-list software and ticketing systems that rewrite subjects or footers will invalidate signatures on relayed mail, so sign at the final hop, not three systems upstream.
DMARC: the policy that makes the other two matter
DMARC is the keystone. Published at _dmarc.yourdomain.com, it
declares: for mail whose visible From is my domain, check that SPF or DKIM
passes and aligns (the domain that passed matches the From domain), and if
neither does, here is what to do: p=none (just report),
p=quarantine (spam folder) or p=reject (bounce).
Alignment is the crucial mechanic: it welds the technical checks to the
address human beings actually read, which is what makes exact-domain spoofing
fail. The spec is RFC 7489.
DMARC also gives you eyes. The rua tag requests daily aggregate
reports from every major receiver: which IPs sent as your domain, what passed,
what failed. The first week of reports is reliably humbling; most
organizations discover a billing system, an old marketing tool or an intern’s
script sending legitimate mail that authenticates as nothing.
Deploying without burning your own mail
The order of operations protects you. Publish SPF, enable DKIM on every
sender, then publish DMARC at p=none with a reporting address and
wait two to four weeks. Read the reports, fix every legitimate source that
fails (usually by adding an include or enabling a provider’s DKIM), and only
then ratchet the policy: p=quarantine, optionally with
pct=25 to phase it in, and finally p=reject.
The classic failure is the enthusiastic jump straight to p=reject
on day one, followed by the discovery that payroll notifications came from an
unauthenticated SaaS nobody documented. The reports exist so that surprise
happens in a dashboard instead of in HR’s inbox.
Verify the whole setup from outside: query the three records with the DNS lookup tool, send a test to a Gmail account and use “Show original”, which displays SPF, DKIM and DMARC verdicts line by line.
The bonus level: your logo in the inbox
Reaching p=reject unlocks one extra: BIMI (Brand Indicators for
Message Identification), yet another DNS record, this one pointing to an SVG
of your logo. Gmail, Yahoo and Apple Mail display it next to your messages,
but only for domains whose DMARC policy is at enforcement, and the big
providers additionally want a Verified Mark Certificate, which means a
registered trademark and a few hundred dollars a year. For most organizations
the certificate is optional vanity; the prerequisite is not. BIMI is the
industry’s way of paying senders to finish their DMARC rollout, and it works:
the logo is the visible proof that the invisible plumbing is done.
Three TXT records, one afternoon of setup, a few weeks of reading reports, and the door on exact-domain spoofing closes for good. Few security controls offer that much return for that little ongoing effort.
Frequently asked questions
Do I need all three records or is SPF enough?
You need all three. SPF alone breaks on forwarding and does not protect the From address users actually see. DKIM alone says nothing about mail that arrives unsigned. DMARC is the piece that ties both to the visible From domain and tells receivers what to do on failure, and since 2024 Gmail and Yahoo require it for bulk senders.
What is the difference between ~all and -all in SPF?
The tilde (~all, softfail) asks receivers to treat unlisted senders with suspicion but not to refuse them outright; the dash (-all, hardfail) asks for rejection. In a DMARC world the difference matters less than people think, because DMARC policy decides the final outcome. Most deployments run ~all and let DMARC do the enforcement.
Why does my SPF record fail with too many DNS lookups?
SPF caps mechanism lookups at 10 per check (RFC 7208). Every include, a, mx and redirect costs one, and includes of includes count too. Stack enough SaaS senders and you blow the budget, at which point receivers may treat the record as a permanent error. Fixes: remove dead includes, use ip4/ip6 blocks where possible, or use an SPF flattening service.
What does p=none actually do?
Nothing to your mail flow, everything for your visibility. With p=none, receivers deliver mail exactly as before but send you aggregate reports showing which sources pass and fail. It is the observation phase: you deploy it first, watch the reports until every legitimate sender passes, then tighten the policy.
Can SPF, DKIM and DMARC stop all spoofing?
They stop exact-domain spoofing: nobody can pass DMARC while forging yourdomain.com in the From header. They do nothing against lookalike domains (yourd0main.com), display-name tricks, or compromised legitimate accounts. They are necessary, not sufficient; the rest is user training and filtering.