You might encounter a situation where a DMARC failure report appears for your domain, yet the sending source isn’t one you recognize.
In most cases, this occurs when the report was generated for an auto-forwarded message. During auto-forwarding, the sending source shown in the failure report is the forwarding server rather than the original one used to send the email. The same pattern can also be noticed in the “Forwarded” section of DMARC aggregate reports.
This behavior can be misleading, so let’s break down the logic behind it to better distinguish these cases from genuine authentication issues.
Understanding how auto-forwarding influences authentication results and DMARC failure reporting
What happens to the messages when they are auto-forwarded
When emails originate from a domain and are sent to recipients who have configured automatic forwarding to other addresses, SPF often fails, because, during SPF evaluation, the receiving server performs the check against the domain of the server that delivers the message to the final recipient. In the case of auto-forwarding, that server is the forwarder, not the original sender. As a result, SPF doesn’t survive auto-forwarding, as it usually fails authentication, alignment, or both.
On the other hand, DKIM behaves differently. It can survive auto-forwarding as long as the forwarding server does not modify the message content in any way (for example, by automatically appending a signature or disclaimer), and the message will pass DMARC.
You can explicitly check our article about DMARC and auto-forwarding for more details.
How are DMARC failure reports triggered
DMARC failure (forensic) reports are generated and sent in real or near real time, triggered by the specific conditions defined by the domain owner in the DMARC record. These conditions are controlled by the “fo=” tag, which can have several values. The “fo=0” reports only when both SPF and DKIM fail, “fo=1” triggers failure reports when either SPF or DKIM fails, “fo=d” triggers failure reports when DKIM fails, and “fo=s” triggers failure reports when SPF fails.
Correlation of auto-forwarding and DMARC failure reports
Based on the information we discussed above, for auto-forwarded messages DMARC failure reports can be triggered under several conditions:
1. When “fo=0” is set and the message fails both SPF (as it commonly does during forwarding) and DKIM due to message alteration
2. When “fo=1” is set and the message passes DKIM but fails SPF, still triggering a report despite passing DMARC
3. Almost always when “fo=s” is set, since SPF fails on forwarded emails
4. When “fo=d” is set and DKIM fails because the message was modified by the forwarder
How to detect if the DMARC failure report was triggered for an auto-forwarded message
There are multiple indicators that will point out that the DMARC failure report was triggered and generated for an auto-forwarded message.
Let’s analyze the real case example below for the originalsender.com domain:
The originalsender.com domain has “fo=1” which means that DMARC failure reports should be triggered if an email fails either SPF or DKIM checks.
A DMARC failure report was generated by Yahoo for the email that was originally sent from the vip@originalsender.com address.
Important note: When Yahoo generates DMARC failure reports, they replace the actual recipient’s email address with the email address specified in the RUF tag (i.e., the EasyDMARC address where the reports are sent). This approach is due to Yahoo’s privacy policies, which prevent disclosing recipient details in the reports. As a result, the "To" address you see in the failure reports corresponds to the RUF tag email of your domain’s DMARC record rather than the original recipient address.
Option 1. Compare the DMARC failure report data with the data in the DMARC aggregate reports
In many cases, when a DMARC failure report is generated for an auto-forwarded message, the same message also appears to be reported in DMARC aggregate reports under the “Forwarded” category.
In our example, the source IP address in the DMARC failure report is 23.83.216.32.
Copy this IP address and filter the data in your DMARC aggregate reports to locate emails associated with it.
After filtering, we can see that this IP address was the source of several emails included in the DMARC aggregate reports and classified as “Forwarded” including the message that appeared in the failure reports.
In the DMARC aggregate reports, we clearly see that SPF failed on those messages.
However, the messages were able to pass DMARC checks and get delivered. 
What happened
The message originated from the originalsender.com and after that it was auto-forwarded by one of the recipients to other external receivers.
The reason of SPF failure, as we explained above, is that SPF return-path checks are performed against the domain that delivered the message to the final recipient (forwarder.com).
But since originalsender.com has DKIM properly configured for its sending sources and as we already know that DKIM is able to survive auto-forwarding if the forwarders don’t change the message content, the messages passed DKIM checks and were able to pass DMARC as it required either SPF or/and DKIM to pass.
Option 2: Analyze the raw message headers provided in the DMARC Failure reports
There might be cases when a DMARC failure report is received but when comparing the data with DMARC aggregate reports, messages with same source IP address are not found there. In such cases, you can analyze the message raw source provided in the DMARC failure reports to indicate if the DMARC failure report was generated for an auto-forwarded message.
To locate the message raw headers in DMARC failure reports, click on the domain of the email in the report.
To locate the SPF, DKIM, and DMARC results, look for the “Authentication-Results” field in the email’s raw header.
For a quicker search, use “Ctrl + F” (Windows) or “Command + F” (macOS) and type “authentication-results.”
Note: When searching for “authentication-results”, there might be two results in the header. Disregard the first one as it represents the authentication results of the Failure report message itself, sent by Yahoo.
The authentication results of the message in question appear under the second “Authentication-results” field.
The results in the raw message header show the same:
SPF return-path checks are performed against the domain that delivered the message to the final recipient (forwarder.com) and SPF failed.
The originalsender.com domain’s DKIM was properly set up and survived auto-forwarding as the message content was not altered by the forwarder.com.
Since DMARC requires the message to pass either SPF or/and DKIM checks to be DMARC compliant, the message passed DMARC with DKIM.
Note: There might be cases when the forwarded messages would fail DMARC even if DKIM of the original sending domain is properly set up. This can happen when the forwarders alter the message content. Still, if DKIM is correctly configured for all sending sources of the original sender, there is no need for concerns.
Conclusion
DMARC failure reports are usually generated for messages that were auto-forwarded and failed SPF, while those might be able to pass DMARC checks with DKIM.
It’s crucial to make sure that DKIM is configured on all sending sources of your domains.
To avoid potential confusions caused by DMARC failure reports generated for auto-forwarded emails, it’s recommended to perform clear analysis of the failure reports following the steps described in this guide.
In case any questions arise, feel free to contact EasyDMARC technical support.