DMARC is not set and forget
A practical look at why email authentication drifts after launch and what to monitor before customers notice.
Most bad email setups were not bad on day one.
Someone added SPF. Someone turned on DKIM. Someone copied a DMARC record from a vendor guide, saw the green check, and moved on. Six months later the billing tool changes sending IPs, the CRM rotates DKIM selectors, or a new help desk starts sending from the main domain. The DNS record is still there. The setup is no longer doing what everyone thinks it is doing.
That is the boring failure mode. No dramatic breach. No obvious outage. Just a slow slide from “configured” to “technically present but unreliable.”
The record can stay still while the mail changes
DMARC depends on SPF or DKIM passing and matching the domain in the visible From address. That last part matters. A message can pass SPF for the vendor’s bounce domain and still fail DMARC alignment for your domain. It can pass DKIM with a signature from a different domain and still fail the policy your users expect to protect them.
This is where teams get caught. They check a domain once and see:
- one SPF record
- a DKIM record for the main mail provider
- a DMARC record with
p=none - working MX records
That scan was useful. It was not a guarantee.
Your mail stream is a moving target. Product notifications, invoices, outbound sales, support replies, password resets, newsletter campaigns, and calendar tools may all send from the same domain or nearby subdomains. Each sender has its own DNS requirements. Each sender can change its instructions.
What usually breaks
SPF breaks when a vendor include disappears, a new sender is missing, or the record gets too large. The SPF DNS lookup limit is easy to hit if every new tool adds another nested include.
DKIM breaks when a selector changes, a key is removed too early, or a subdomain starts signing with the wrong domain. The frustrating part is that DKIM can look fine for one sender while another sender is unsigned.
DMARC breaks when neither SPF nor DKIM aligns with the From domain. This can happen even when both protocols appear to pass somewhere in the headers. DMARC is stricter than a simple “SPF pass” or “DKIM pass” label.
Reports break too. A rua address can stop receiving aggregate reports because the mailbox changed, the route was removed, or the report processor stopped ingesting attachments. When that happens, you do not get a loud failure. You get silence.
A safer monitoring habit
The minimum habit is simple: scan the domain on a schedule and compare the result with the last known good state.
Watch for changes in:
- SPF record count, validity, lookup count, and unsafe mechanisms
- DKIM selectors that were valid yesterday and missing today
- DMARC policy, percentage, and report destination
- MX presence and route changes
- BIMI issues, if you use BIMI for brand display
- daily score changes that point to DNS drift
BIMI deserves a note. It is useful for brand presentation, but it should not distract from authentication. In Inbox Vital, BIMI is diagnostic only. It does not raise or lower the domain health score because authentication and routing need to stay the main signal.
Treat quiet as a signal
If a monitor stops seeing DMARC reports for a domain that normally receives them, that is worth investigating. It might mean send volume dropped. It might mean the report address broke. It might mean a provider changed how it sends reports. None of those are things you want to discover after a spoofing problem or a delivery complaint.
The same goes for daily scans. A single bad day can be a bad deploy, a vendor migration, or a typo in DNS. The important part is catching it while the change is still fresh enough for someone to remember what happened.
DMARC is a policy, but the environment around it keeps moving. The record is only the start.