Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · DNS change auditor series ~5 min read

How mail records get watched

Mail records deserve their own post because they share a property that makes them uniquely dangerous: breaking them produces no error anywhere you can see. Everything still sends. Nothing logs a failure. The only symptom is customers not replying, and that takes weeks to notice and is nearly impossible to attribute.

Key takeaways

  • Four records, four different silent failures.
  • MX: mail stops arriving, and senders may not get a bounce for days.
  • SPF: your mail still sends and increasingly lands in junk.
  • DKIM: signatures stop verifying, usually after a provider key rotation.
  • DMARC is the one that tells you the others are broken, if you read the reports.

Four silent failures

RecordIf it breaksHow you find out today
MXIncoming mail bounces or vanishesA customer says they emailed you, days later
SPFYour outgoing mail is treated as suspiciousInvoices are ’never received’, over weeks
DKIMSignatures fail; the same as SPF but harder to spotSame as SPF, and usually blamed on SPF
DMARCNothing immediately; you lose your reportingYou do not

The third column is the argument for the whole system. Every one of those failures is currently discovered by a customer, indirectly, after enough time has passed that the cause is no longer obvious. A change detected within the hour with a sentence explaining it removes all four.

What each change means

How changes to the four mail records are handledA vertical chain of five steps entered by a box labelled A mail record changed, being MX, SPF, DKIM or DMARC. Step one asks whether it is MX, affecting incoming mail; if so it exits to Alarm to both people, because mail may be lost now. Step two asks whether it is SPF, affecting outgoing reputation; if so it exits to Alarm with the diff, naming which sender lost cover. Step three asks whether it is a DKIM selector, which is a provider key; if so it exits to Check it verifies, rather than merely noting that it changed. Step four asks whether it is DMARC, covering policy and reporting; if so it exits to Alarm on policy weakening, noting that reject to none is a big change. Step five records it and includes it in the digest. A note says DKIM is the one where changing is normal, and what matters is whether it still verifies.AWS ACCOUNTA mail record changedMX, SPF, DKIM or DMARCMX?incoming mailAlarm, both peoplemail may be lost nowyesSPF?outgoing reputationAlarm, with the diffwhich sender lost coveryesDKIM selector?provider keyCheck it verifiesnot just that it changedyesDMARC?policy and reportingAlarm on policy weakeningreject to none is a big changeyesRecordedand in the digestDKIM is the one where changing is normal. What matters is whether it still verifies.
Fig 1. How each mail record change is handled. DKIM is the exception: rotation is routine, so the check is functional rather than a diff.
  • App integration
  • Security & identity
  • Management

SPF: which sender lost cover

An SPF record is a list of who is allowed to send as you, and the useful description of a change is not the string diff but the answer to “which of our senders is no longer covered?” A removed include is usually a whole mail provider, and naming it is what makes the message actionable.

There is a second SPF failure worth watching that is not a change at all: the lookup limit. SPF permits a bounded number of DNS lookups when evaluating a record, and a business that has accumulated includes over the years can cross it. When that happens the record stops working entirely, without anybody having edited it, because a provider added an include inside their own include.

DKIM: changing is normal

Mail providers rotate DKIM keys, sometimes automatically, and a selector record changing is routine rather than alarming. Treating every rotation as an incident is how this particular check gets muted.

So the DKIM check is functional: take the selector, fetch the key, and confirm it is well-formed and of a sane length. A rotation that produces a valid key is a digest line. A selector that stops resolving, or returns something malformed, is an alarm — and that is the actual failure mode, usually caused by a provider migration where the new selector was never added.

The check that is not a diff

How the SPF lookup limit is monitoredA horizontal row of five boxes. SPF lookups: counted weekly. At eight of ten: warn. At ten: the record fails entirely. Nobody edited it: a provider grew their own include. No diff would catch it: which is the point. A note says a record that has not changed can stop working, and counting is the only way to see it.THE SPF LOOKUP LIMITSPF lookupscount them, weeklyAt 8 of 10warnAt 10the record fails entirelyNobody edited ita provider grew theirsNo diff would catch itwhich is the pointA record that has not changed can stop working. Counting is the only way to see it.
Fig 2. The one mail check that a change auditor would otherwise miss completely: a record that is byte-identical to last week and has stopped being valid.
  • App integration
  • Security & identity
  • Management
  • Analytics

Counting SPF lookups means resolving the record and recursively following every include, a, mx and redirect in it, which is a dozen lines of code and the single most valuable non-diff check in the whole system. It catches a failure that has no author and no event.

Next: how confirmation works, and what the digest looks like.

All posts