DMARC reports IETF RFC compliance

After analyzing millions of DMARC reports, I've reached the disheartening conclusion that only a small percentage adhere to the DMARC IETF RFC guidelines. Many reports lack mandatory elements or contain incorrect values, which is not what domain owners should expect from major organizations like Google, Yahoo!, and Mail.ru.

DMARC aggregate reports are crucial for monitoring email deliverability and the alignment of DKIM and SPF policies. They provide essential feedback, allowing domain owners to track authentication success and identify threats, aiding in the fine-tuning of SPF and DKIM setups to reduce the risk of unauthorized use of their domains for spam or phishing.

The DMARC IETF RFC includes an XML schema that outlines reporting guidelines (Appendix C). Unfortunately, some guidelines are ambiguously written, possibly contributing to widespread non-compliance.

At URIports, we process millions of DMARC reports daily and have observed many of these reports failing validation. Often, the lack of crucial information leads to guesswork and inaccuracies, which undermines the effectiveness of these reports. More accurate and complete reports would significantly enhance domain owners' awareness of their email systems' deliverability.

Below is a real-time list of organizations from which we've received the most non-compliant reports over the past three days.

If an organization has a 0% compliance rate, every report from that organization contains a validation error. This could be due to missing elements or incorrect or empty values.

Inconsistencies

The DMARC aggregate report has an element with the name policy_published. This name would indicate that the elements within contain the domain's published policy. The RFC explains this element as PolicyPublishedType:

The comments mention applied, which is in contrast to the name of the element (policy_published), as some organizations that send aggregate reports do not send failure reports and thus do not "apply" the "fo" (failure reporting options) element. This particular element's comment also implies that it is optional: "failure reporting options in effect." On the other hand, this element has a default minOccurs value of 1, so it should not be omitted.

The comments are to blame, and that's why so many organizations have a different implementation. I think the element policy_published should be just that: the published policy. The default value should be used when a policy tag is omitted because it is optional (adkim, aspf, sp, pct, and fo).

IdentifierType: envelope_from

A typical missing value in the identifiers element is envelope_from. It should contain the RFC5321.MailFrom domain, but is left out by some organizations, even though it has a minOccurs value of 1 and could contain valuable information.

Others

Some inconsistencies are easily fixed, like the missing or empty DKIM selector and SPF scope, and the empty extra_contact_info that should be omitted instead of having an empty value.

Drafts VS RFC

XML elements IdentifierType 'envelope_from, SPFAuthResultType scope, DKIMAuthResultType selector, and feedback version were added to the DMARC (pre-IETF) draft in January 2013. It looks like most organizations (even the founding contributors like Google, Yahoo!, and LinkedIn) based their code on the pre-2013 drafts and haven't touched that code since. This explains why XML elements are missing from their reports. The PolicyPublishedType fo element was added to draft-kucherawy-dmarc-base-02 in December 2013. You would expect that as soon as the RFC was published in March 2015, the organizations would update to the final XML schema; unfortunately, most didn't.

Conclusion

As more and more domains adopt DKIM, SPF, and DMARC, I'm hoping more aggregate report-sending parties will make the reports as complete as possible so we at URIports can help domain owners make the internet a better and safer place.

Any comments? Do you (dis)agree with my interpretations of the RFC guidelines? Please, find me on Twitter @freddieleeman.