DEV Community

jeffrey
jeffrey

Posted on

DMARC aggregate reports as infrastructure change detection

#emailsecurity #dmarc #operations

DMARC aggregate reports as infrastructure change detection

Why the reports are worth keeping

Most teams treat DMARC aggregate reports as a migration artefact: read them while moving from a permissive policy to enforcement, then let them pile up unread. The same XML answers a question that operations teams ask constantly and rarely answer with evidence: what is currently sending mail as our domain, and did that set change this week?

How the reports are built

DMARC, defined in RFC 7489, does not authenticate anything by itself. It publishes a policy and tells receivers where to send reports. Authentication comes from SPF (RFC 7208) and DKIM, and DMARC adds identifier alignment: the domain that passed must match the domain in the From header. Receivers send aggregate reports to the address in the rua tag, normally once per day per reporting domain.
A report contains a reporting organisation, a date range, a policy record, and one row per source IP with the evaluated count and the disposition applied. RFC 8616 explains the additional considerations that apply to internationalised addresses.

What to extract

Four signals repay regular parsing:

  • New source IPs with non-trivial volume. A marketing platform, a new ticketing system, or an attacker. The report does not tell you which; it tells you where to look.
  • Alignment failures from your own ranges. These follow a change: a mail gateway upgrade, a new relay, a tenant migration that reset DKIM signing. They are configuration drift made visible.
  • Permanent and temporary failures. SPF permerror and temperror behave differently and point at different fixes.
  • Volume from domains you do not own, which is the spoofing signal that a permissive policy exists to surface. Automate the comparison between yesterday and today. The value is in the diff, not the daily total.

Operating the loop

  1. Send reports to a mailbox that a system reads, not to a person.
  2. Store parsed rows with a retention window long enough to cover a quarter.
  3. Alert on new sending IPs and on the first appearance of an unaligned source above a volume threshold.
  4. Move the policy in stages, and keep watching after enforcement. A misconfigured sender that starts failing alignment under a reject policy is a mail outage discovered by a recipient, not by you.

References

Top comments (0)