Last week, in Part II of our series, we went into detail about forensic and aggregate reports. Now we’ll walk through the importance of and how to analyze those reports, as well as provide resources to help you.
Analysis of DMARC reports can be time consuming, but there are various free and cost effective 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). However, if you receive a large number of reports, then it may be best to connect with a DMARC vendor as they can provide a portal with an aggregate view of all the reports and can provide guidance with record implementation and adjustment. This level of service and capability does of course come at a cost.
Some DMARC vendors are:
It is recommended to review these reports, verify which domains are authorized, and adjust the SPF recorded as needed. Do this for about 3-5 months. Once complete, change the policy to Reject (or Quarantine).
Do not stay at policy level None, which is least effective in protecting consumers and other organizations. If you want to help reduce spam/phishing using your organization’s email domain, then move up to policy level Reject.
External Destination Verification
This is a feature that is built into DMARC that allows you to send reports to an email address that is outside of your organization. For instance, if your DMARC policy looked like this: v=DMARC1; p=none; rua=mailto:[email protected], your DMARC record is telling the world to send your DMARC reports to [email protected]. Before any reports can be sent to gotdmarc.org we must create a simple TXT record basically saying it is ok. On the DNS server of the server you are wanting to send reports to the below record will need to be created:
Name: <reporting company>._report._dmarc.<receiving company>
Examples of what to look for during report analysis
Example 1 – As we look at this one, the red boxes show us that DMARC has failed both DKIM and SPF, the green boxes show us DKIM and SPF passing the checks, the blue boxes are the issue here as the domains do not match the from domain.
Example 2 – Here we can see DKIM fails due to not being setup correctly, the DKIM selectors errors, and SPF fails due to non-matching domains these then caused DMARC to fail.
Example 3 – In this example we see that DKIM and DMARC have both passed and are aligned, but SPF has failed because of forwarding. These messages are being forwarded using Gmail/Yahoo/or Hotmail.
Example 4 – DKIM does not appear to be configured, and SPF is failing due to the IP addresses not existing in the SPF record on the DNS server.
If we take a look at this one, we see that the DKIM domain matches the return domain in the blue boxes. But DKIM still failed shown in the red box, this is because the DKIM public key was not published in the correct location on the DNS server.
Here we have another DKIM issue, this is a configuration error within the DKIM policy on the DNS server.
In this one we see that SPF has failed because ssssmail.com is not authorized in the SPF record to send mail on behalf of globalcyberalliance.org, DKIM is also not configured for this domain.
DKIM and SPF issues
Here we have 2 errors, DKIM fails because of the from domain and DKIM domain not matching, and SPF soft fails because the IP address is not in the SPF record.