DMARC Reporting:
Key Benefits and Takeaways

By Shehzad Mirza


One of the many benefits of implementing DMARC is the reporting component.  These reports provide various types of information which will help an organization’s IT/email administrators and can provide an email asset inventory.  The reports contain:

  • Date/time range of the report
  • The domain impacted
  • The IP address of the sending system (as well as the PTR record)
  • Whether SPF/DKIM check have passed or failed
  • If SPF/DKIM is aligned correctly
  • The DMARC policy applied
  • The domain associated with SPF/DKIM

The domains and IP addresses of the sending systems should (hopefully) all be authorized systems, which should match the IT/email administration inventory list.  If anything is not on their list, then it’s either an email service not known by the team (thus improving IT asset inventory), or those domains/IP addresses are spammers and/or phishers.  Knowing the spammers/phishers is beneficial as well, because that data that can be used for cyber intel and spam blocklists.

DMARC has two types of reports, the aggregate report and the forensic report.  Both reports are sent by participating recipient email servers to the sending organization.  However, in order to receive these reports, the rua (aggregate) and ruf (forensic) tags must be included.  At a minimum, all organizations should get the aggregate reports.

These reports can be sent to anyone within the organization. It is strongly recommended to send the reports to a group account rather than individual accounts, especially in mid- to large-sized organizations.  The reason being, your inbox could get flooded with reports.

In some cases, you may want to send reports to an external organization (a DMARC reporting service or a third-party IT service provider).  In order to do so, the DMARC policy will still use the rua and ruf tags.  However, the external organization must create DNS TXT records in order to accept those reports.  Those records will look as follows:

Host: <sending org>._report._dmarc.<external org>

Text:  v=DMARC1

For example, if globalcyberalliance.net is the organization that wants to send the report to globalcyberalliance.org, the the records would look like:

Host: globalcyberalliance.net._report._dmarc.globalcyberalliance.org

Text:  v=DMARC1

Analysis of the report can be time consuming, but there are various free and cost methods of reviewing those reports.

A few free options are:

Of course if the report analysis gets to be too much, a SOC/NOC could be used to perform the analysis (along with one of the free options listed above) or one of the DMARC service providers below can be used (at a cost):

Agarihttps://www.agari.com/
Valimailhttps://www.valimail.com/
OnDMARChttps://redsift.com/products/ondmarc
DMARC Analyzerhttps://www.dmarcanalyzer.com/
250okhttps://www.validity.com/everest/250ok/
dmarcianhttps://dmarcian.com/
Proofpointhttps://www.proofpoint.com/us
DMARC360https://www.dmarc360.com/
ProDMARChttps://prodmarc.com/

 

Overall, it is important to review the DMARC reports by using one of the mechanisms above, especially when you are the DMARC policy level of ‘none’, which is least effective in protecting consumers and other organizations.

The author, Shehzad Mirza, is the Director of Operations at the Global Cyber Alliance. You can connect with Shehzad on LinkedIn.