DMARC Failure Reporting

If you receive an abuse report based on your DMARC DNS options, you'll be directed to this article.

DMARC messages show a pass or a failure for each component, depending on your DMARC reporting options. You should open the attachment (e.g. ATT00001) and review it. The attachment and components include:

  • Mail From
  • Authentication - The results of authentication from the MTA
  • Delivery Result - Whether the message was rejected or quarantined, based on the policy outlined in the DMARC record.
  • From DKIM Domain
  • DKIM Identity
  • DKIM selector
  • DKIM Body
  • SPF from domain
  • IP Information - the IP address from which the message purports to originate.
  • Time - The time the message was originally received by the ISP (by the second).
  • Message headers

To pass DMARC, a message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment.

Email messages will be processed based on the instructions in your DMARC record (p=). You may receive a failure report although the message may not be acted upon and still delivered.

Understanding the Authentication results

SPF-authenticated Identifiers

DMARC provides the option of applying SPF in a strict mode or a relaxed mode. 

In relaxed mode, the [SPF]-authenticated RFC5321.MailFrom (commonly called the "envelope sender") domain and RFC5322.From domain must match or share the same Organizational Domain. The SPF-authenticated RFC5321.MailFrom domain may be a parent domain or child domain of the RFC5322.From domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. 

For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode. 

For purposes of identifier alignment, in relaxed mode, Organizational Domains of RFC5321.MailFrom domains that are a parent domain of the RFC5322.From domain are acceptable, as many large organizations perform more efficient bounce processing by mapping the RFC5321.MailFrom domain to specific mail streams.

DKIM-authenticated Identifiers

DMARC provides the option of applying DKIM in a strict mode or a relaxed mode.

In relaxed mode, the Organizational Domain of the [DKIM]-authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal. In strict mode, only an exact match is considered to produce identifier alignment.

To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From domain is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail. However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result as "com" should appear on all public suffix lists, and therefore cannot be an Organizational Domain.

Identifier alignment is required to prevent abuse by phishers that send DKIM-signed email using an arbitrary "d=" domain (such as a Cousin Domain) to pass authentication checks.

DMARC Mechanism Check Result

This is the Alignment Results of DMARC Mechanism Check Result.  This looks for a failure in the RFC5322.From domain and the return path and/or DKIM domain. Based on results is if this fails.


How did we do?