RFC 7960 — DMARC and indirect mail flows

Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows

Status
Informational
Published
2016

RFC 7960 catalogues the ways legitimate mail fails DMARC. If you are staring at failures you cannot explain from senders you recognise, this document probably already describes your situation.

It is Informational — it defines nothing and fixes nothing. Its value is that it is an honest, exhaustive account of the protocol’s known collateral damage, written by the people who built it.

What an indirect mail flow is

Any path where the message does not travel directly from the author’s infrastructure to the recipient’s. In practice:

  • Mailing lists, which retransmit from their own servers and frequently modify the message
  • Forwarders, both automatic (.forward, corporate rules) and manual
  • Gateways that rewrite content — appliances adding disclaimers, malware scanners rebuilding attachments

Each breaks authentication differently. Retransmission breaks SPF, because the relaying IP is not in your record. Modification breaks DKIM, because the signature covers content that changed. A list doing both breaks both.

Why this is not simply a bug to fix

The uncomfortable conclusion is that some of these are not fixable at the protocol level. A mailing list that appends a footer is behaving correctly and has been for thirty years. DMARC asks a question it cannot answer without breaking either the list or the security guarantee.

The document is careful to present mitigations rather than solutions: lists can rewrite the From: header to their own domain (which works and annoys everyone), senders can prefer DKIM over SPF (which survives forwarding more often), and receivers can weigh ARC (which is Experimental and optional).

What to do with it

Read it before deciding that DMARC failures should reach zero. They should not, and a domain publishing p=reject with mailing-list traffic is making a deliberate trade rather than fixing an error.

Practically: identify indirect flows in your aggregate reports, confirm they are real, and leave them. The failures you should chase are the ones from your own infrastructure.

Read it: rfc-editor.org/rfc/rfc7960