Learn · Email authentication
DNS drift: why email authentication decays
Email authentication is configured in DNS, and DNS is a shared surface: your IT team, your web agency, your marketing tools, your registrar — and, if you're unlucky, an attacker — can all change it. The records you carefully set on the way to p=reject don't stay set. That slow decay is DNS drift, and it fails in two opposite directions: spoofing quietly comes back, or your own legitimate mail starts bouncing.
How records actually drift
Almost never through malice — mostly through ordinary work done without the email picture in mind:
- Someone edits SPF for a new tool. A marketing hire adds an
include:for a new platform and accidentally deletes another, or pushes the record over SPF's 10-lookup limit — at which point receivers treat SPF as broken for every sender, not just the new one. - A migration drops DKIM keys. Website moves, DNS provider switches, and zone copies are notorious for losing
_domainkeyrecords. Mail keeps flowing — it just starts failing DKIM, which under an enforced policy means quarantine. - A vendor quietly changes what they need. ESPs update sending infrastructure and deprecate old include hosts or CNAME targets. The record that was right last year points at nothing this year.
- The DMARC record itself gets "simplified". Someone troubleshooting deliverability finds
p=reject, suspects it, and softens it top=none— undoing months of rollout in one edit that nobody announces. - Actual compromise. A stolen registrar or DNS-provider login is the jackpot version: repoint MX and the attacker receives your mail; edit SPF/DKIM and they send as you, authenticated. Unexpected record changes are often the first observable symptom.
Why enforcement raises the stakes
Under p=none, drift is invisible and mostly harmless — nothing was being blocked anyway. Under p=quarantine or p=reject, the same drift has teeth:
- Drift against you: a broken SPF record or deleted DKIM key means your own mail now fails authentication, and your enforced policy tells the world's mailbox providers to junk or reject it. The policy you published to stop attackers starts rejecting invoices.
- Drift for the attacker: a weakened DMARC record (
p=none,pct=10, a removedrua) re-opens the spoofing door — and because everything looks done, nobody is watching the reports the way they were during rollout.
The uncomfortable part: aggregate reports alone catch drift slowly. Reports show yesterday's outcomes, so you notice a deleted DKIM key only after a day of failures — and a weakened policy record generates no failure at all, just quieter enforcement. Catching drift means re-reading the records themselves, every day, and comparing against what was there before.
What a drift watch should cover
| Record | Drift that matters | Blast radius |
|---|---|---|
DMARC (_dmarc) | Policy weakened, rua removed, record deleted or duplicated | Spoofing protection and reporting silently off |
| SPF (apex TXT) | Mechanisms added/removed, over 10 lookups, record deleted or duplicated | Every sender's SPF result; permerror breaks it all |
DKIM (*._domainkey) | Key deleted, CNAME to the ESP removed or repointed | That sender's signatures fail from that moment |
| MX | Hosts added, removed or repointed | Where your inbound mail physically goes |
Two details separate a useful watch from a noisy one. First, failed lookups aren't deletions — DNS has bad moments, and a monitor that cries "SPF removed!" on a timeout trains you to ignore it. Second, DKIM needs to watch the right selectors — the ones your senders actually sign with, which show up in your aggregate reports, not a guessed list — and for ESP-managed keys it should watch the CNAME target rather than the key behind it, because ESPs rotate keys routinely and that rotation is not drift.
Catching it within a day
You can absolutely run this by hand: dig the four record sets, keep yesterday's copy, diff, repeat daily per domain. Nobody does, which is the point — drift wins against good intentions and loses to automation. Canny Pigeons runs this watch on Pro, Business and Partner plans: we re-resolve DMARC, SPF, MX and your report-observed DKIM selectors daily, and when something actually changed you get an email with the before and after — one line of which is usually enough to tell "ah, that was Dave adding the new CRM" from "nobody here did that." Eligible domains on hosted DMARC also get a hosted-policy check: if your _dmarc CNAME stops resolving to the policy we serve for you, that's flagged too.
For a point-in-time look, the DMARC checker reads all four record sets live and grades them — drift monitoring is that same read, repeated daily, with yesterday’s copy to diff against.
Then the alert email ends the same way every security notification should: if you made this change, ignore us. If you didn't — go look, today, not at the end of the quarter.