A DKIM setup is correct on the day it is built and decays afterwards without anyone editing anything. Five things rot, and each has a different tell.
The five
| What decays | How it happens | The tell |
|---|---|---|
| Selectors for vendors you no longer use | The contract ended; the DNS record did not | A selector nobody can account for. The vendor may still be able to sign as you. |
| Dangling delegations | The vendor tore down their side of a CNAME | The CNAME resolves; the target is NXDOMAIN. A takeover risk, not just a dead record. |
| Keys in testing mode | t=y was set during setup and never removed | Signatures verify and count for nothing. Invisible in every dashboard. |
| Undersized keys | A 1024-bit vendor default from years ago | The MIGf prefix in p=. Increasingly rejected by policy. |
| Unrevoked old selectors | A rotation that stopped after the switch | Two live keys where there should be one, indefinitely. |
A sweep you can actually run
You cannot enumerate selectors, so the inventory has to come from two directions at once: what you know you configured, and what receivers report seeing.
# 1. From your own records # list every _domainkey name in the zone. This is the only # complete list, and only for keys published in your zone — # delegated ones appear here as CNAMEs, which is enough. # 2. From DMARC aggregate reports # collect every header.d that appeared over 30 days. # Anything signing as you that is not in list 1 came from # a delegation or a platform you have forgotten about. # 3. For each name in list 1, resolve it and check: # - does it resolve at all, through any CNAME? # - is p= non-empty? # - is t=y absent? # - does p= start with MIIBIj rather than MIGf? # 4. For anything you cannot account for: find the owner # before removing it. A selector in use is carrying mail.
Never delete a selector you cannot explain
An unaccounted-for selector is either a forgotten vendor or a live sender nobody documented, and the two look identical in DNS. Removing it in the second case breaks a mail stream, usually one belonging to a team that will not connect the outage to a DNS change. Find out what signs with it — a week of aggregate reports will tell you — before touching it.
When to run it
Quarterly, and additionally whenever a vendor relationship ends. The vendor-offboarding case is the one that matters most and the one least likely to happen on its own: the contract is cancelled by someone who has no reason to think about DNS, and the selector that lets them sign as you outlives the invoice by years.