Since Google and Yahoo began enforcing authentication requirements for senders in 2024, email authentication stopped being a best practice and became table stakes: mail that fails checks increasingly is not delivered at all. The system rests on three DNS records that are cheap to publish and easy to get subtly wrong. Here is what each one actually does, and the order in which to deploy them safely.
SPF: Who May Send
SPF (Sender Policy Framework) is a TXT record listing the servers allowed to send mail for your domain. A typical record — v=spf1 include:_spf.google.com include:sendgrid.net ~all — authorizes Google Workspace and SendGrid, then asks receivers to treat anything else with suspicion (~all softfail) or reject it outright (-all hardfail). Two rules prevent the classic failures. One: exactly one SPF record — two records is a permanent error that disables SPF entirely, and it happens constantly when different vendors each ask you to “just add” their record; merge the includes into a single record instead. Two: stay under ten DNS lookups — every include costs at least one, chained SaaS vendors quietly stack up, and lookup eleven breaks everything. SPF alone has a blind spot: it checks the invisible envelope sender, not the From line the human sees, so it cannot stop From-line spoofing by itself.
DKIM: Proof the Message Wasn’t Altered
DKIM (DomainKeys Identified Mail) has your mail server sign each outgoing message; the public key lives in DNS at selector._domainkey.yourdomain.com, and receivers verify the signature. A valid signature proves the message came from infrastructure holding your key and was not modified in transit. Selectors (the arbitrary name before ._domainkey) exist so multiple systems can sign independently — Google uses google, Microsoft 365 uses selector1/selector2, ESPs use their own. Every service that sends mail for you needs its own DKIM setup; a common gap is authenticating the mail suite but forgetting the billing system, the CRM, and the marketing platform, whose unsigned mail then degrades your domain’s reputation.
DMARC: Policy and Feedback
DMARC ties the first two together with the check both of them miss — alignment. It requires that the domain the human sees in the From line matches the domain SPF or DKIM validated, which is exactly what spoofers exploit. The record at _dmarc.yourdomain.com declares policy: p=none (deliver anyway, but send me reports), p=quarantine (spam-folder failures), p=reject (refuse them). Just as important, rua= requests aggregate reports — XML summaries from receivers showing every source sending mail as your domain, which is how you discover the forgotten newsletter tool before enforcement breaks it.
The Rollout Order That Doesn’t Burn You
Deploy in monitoring-first sequence. Week one: publish SPF covering every legitimate sender, enable DKIM on all of them, and publish DMARC at p=none with a reporting address. Weeks two to four: read the reports, find legitimate senders that fail alignment, fix them. Then ratchet: p=quarantine with pct=25, raise the percentage as reports stay clean, and finish at p=reject — where your domain becomes effectively unspoofable and, helpfully, more trusted by receiving filters. Jumping straight to reject without the monitoring phase is how companies block their own invoices; the reports exist precisely to prevent that.
Total cost: three DNS records and a few hours of report-reading spread over a month. For most domains this is the highest-leverage deliverability and anti-phishing work available at any price.