DMARC aggregate reports explained

DMARC gives you insight into and control over your email channel.  It protects your brand from being used in phishing and other email spoofing attacks. DMARC reports are a powerful tool for detecting issues with your DKIM and SPF setup. URIports is a service that helps you turn the often overwhelming, confusing raw DMARC report data into action.  

To give you an idea of what to expect, I'll guide you through the most common DMARC report types and dive into the details of some of ours to help you better understand your own.

What you see below are examples of DMARC reports as they appear in the URIports application. We've blurred some information to protect the privacy of our users and email contacts.

Basics

Need to refresh your memory about any of the columns or values in the screenshot above? Please have a look at one of my previous blogs here: https://www.uriports.com/blog/the-beginners-guide-to-dmarc-with-uriports/

Our domain currently has a `p=quarantine` DMARC policy, so when both DKIM and SPF fail, the receiving server should quarantine the message instead of delivering it to the receiver's inbox. As you can see in the screenshot, two rows (1) have this condition. But when we look at disposition (2), we see that only one row has resulted in quarantined messages.

I'll take you through each row by expanding the inspection window and explain what these reports tell us. Message count sorts the rows in descending order (column Count). So let's go from top to bottom.

Update 07/05/2021

We've added a DMARC column that allows you to filter and group the three different values easily (pass, fail and ignored). If both DKIM and SPF fail, the result is false unless the receiving server ignores the policy. In that case, the DMARC value will be set to ignored. These are most likely forwarded messages. If DKIM or SPF passed validation, the DMARC value would be pass.

Disposition none, DKIM pass, SPF pass

This is the row with the highest message count. The disposition is none (1), which means the messages were delivered to the receiver's inbox. The 'header from' (2) shows the email domain, and below that, we see both DKIM and SPF pass (3). The individual reports (newest on top) give more details on the DMARC results. While the DKIM and SPF columns (3) can only have a pass or fail value, the "DKIM and SPF Auth Results" columns (4) contain more details. More about this later. This is what you want to see, all messages neatly DKIM signed and from an SPF allowlisted source.

Disposition none, DKIM pass, SPF fail

Now things are starting to get tricky. As you can see in the screenshot above, a total of 132 messages (1) passed DKIM but failed SPF (2). As we look at the individual reports, we see that the messages were received from IP addresses (3) that are not ours.

The first SPF Auth Result (4) is a fail because the SPF policy of domain uriports.com does not allowlist the Source IP (3). The two SPF Auth Results that follow pass, but for a different (blurred) domain. SPF validation is based on the Return-Path of a message, and while the SPF Auth Result check can pass for that specific domain (e.g., the source IP is allowlisted in the SPF of the Return-Path domain), the domain does not align with the "Header from",  causing SPF to fail. Auth Results that do not align are shown in a purple color and prefixed with a ≠ (not equal) symbol.

This is mainly caused by servers forwarding your message. Since the message was initially DKIM signed and not changed during transit, DMARC passed, and the message was delivered (disposition none).

Adding the source IP addresses to your SPF policy will not fix this SPF issue because the Return-Path of the messages will always cause alignment issues. However, if these messages are forwarded by a server you control, you could investigate whether or not the Return-Path can be changed to match the "Header from" domain.

Disposition none, DKIM fail, SPF fail

These seven messages failed DKIM and SPF (1) but were delivered anyway because the receiving server (google.com) had a good reason (2). Looking at the DKIM results (4), we see that the message had two DKIM signatures. The original from us failed because the message was altered, and a signature from Microsoft passed. Because onmicrosoft.com does not match uriports.com there is no alignment (≠), and DKIM fails. SPF fails too because the (blurred) Return-Path domain (5) does not align either (≠). Google, however, has good reason to believe that the messages were forwarded by Microsoft and decided to ignore our DMARC policy and deliver the messages anyway.

Disposition quarantine, DKIM fail, SPF fail

Here are five messages that were rightfully quarantined: (1) DKIM failed (2) because the messages had no DKIM signature (DKIM Auth Result "none") and SPF failed (3) because the source IP (4) from Microsoft is not allowlisted by the SPF policy from domain gmail.com. These messages were not from us and were quarantined by the receiving server. If we had set our DMARC policy to p=reject, the messages would have been rejected instead of quarantined.

Disposition none, DKIM fail, SPF pass

The report above is an excellent example of why you shouldn't trust all the reports you receive. This report was submitted by a personal server (1) that was probably not set up correctly, causing DKIM verification to fail. The messages were sent from our server (2) directly and were DKIM signed but somehow failed validation. The messages were delivered because SPF passed. If you have a high message count and multiple sources that share these results, there is probably something wrong with your DKIM signing process. But in this case, with only three messages from a single source, we can safely ignore the DKIM failure.

Disposition none, DKIM pass, SPF fail

This last report for just a single message from a small (blurred) source (1) can be safely ignored too. The source IP is one of our email servers, but SPF failed because of a temporary error (2), probably a DNS issue. DKIM passed just fine, so DMARC should pass too. Even though DMARC passed thanks to DKIM, the receiving server added an (unnecessary) override reason (3) to ensure the message would be delivered. When in doubt, trust the report sources with a high message count.

Issues that should be resolved

Now that we've walked you through our reports, you might be wondering what to look out for and what issues can be resolved. Since our setup is working nicely and all legitimate email reaches its destination, there is nothing for us to change.

In a perfect world, all your legitimate emails have a valid DKIM signature, originate from a server that uses your domain's Return-Path, and whose source IP is allowlisted in the SPF policy.

Let me walk you through a few common resolvable issues:

DKIM fail, SPF pass, DKIM Auth Result none

If you receive many reports from multiple sources where DKIM Auth Result is "none" or "fail" and SPF pass, you have either not set up DKIM or the signing process is not working correctly. Use the Source IP to locate the faulty server and resolve the issues.

DKIM pass, SPF fail, SPF Auth Result fail

This could indicate that an IP or service is not included in your SPF policy. Check the Return-Path domain first to see if there's an alignment issue. If the domain names align, you can add the IP or include the service's SPF record in your SPF policy to resolve this issue.

SPF fail, SPF Auth Result permerror

When multiple sources report an SPF "permerror", there's a good chance that you have a syntax error in your SPF policy. In our experience, this is caused mainly by multiple SPF TXT records. Merge the records into a single TXT record to resolve this issue.

SPF fail, SPF Auth Result none

When SPF fails with an Auth Result value "none", the (sub)domain in question does not have an SPF policy. If this (sub)domain has alignment and you want these messages to pass SPF, you should create an SPF policy that allowlists the IP sources (e.g., v=spf1 a -all). If you want these messages to fail, you should publish  v=spf1 -all.

DKIM fail, Human Result "Unsupported Algorithm"

If multiple sources report this issue, and the DKIM domain and Sender domain align, the messages are signed with an unsupported algorithm. You should upgrade your DKIM algorithms to RSA-sha256 to resolve this issue.

URIports

As you can see, there is a lot of valuable information in DMARC reports. URIports is a great tool to aggregate and enrich the report data to keep you confident in your email setup. When we detect problems with your DKIM or SPF setup, we even send you (push) notifications. Not a URIports user yet? Start your 30-day trial now!