Understanding and troubleshooting DMARC reports from Google and Yahoo
Matthew Whittaker
Co-founder & CTO, Suped
Published 11 Jul 2025
Updated 11 Jul 2025
6 min read
If you have recently set up DMARC for your domain, you have probably noticed something new in your inbox: a daily stream of emails with cryptic XML attachments. These are your DMARC aggregate reports, sent from providers like Google and Yahoo. Since their new requirements took effect, understanding these reports is absolutely essential for anyone sending email.
At first glance, these files are completely unreadable to the human eye. It is just a wall of code. This often leads to the question seen on forums all the time: what am I supposed to do with these DMARC reports? The answer is that they contain information about your email sending activity, both legitimate and fraudulent. They tell you who is sending email on your behalf and whether that email is passing authentication.
The purpose of these reports is to empower you. By analyzing the data, you can identify unauthorized senders, fix authentication issues with your legitimate services, and confidently move towards a stricter DMARC policy like p=quarantine or p=reject. Interpreting what Google and Yahoo are telling you is necessary to resolve common problems.
Decoding the contents of a DMARC report
DMARC aggregate reports, or RUA reports, are sent in a machine-readable format called XML. While a DMARC analyzer is the best way to parse this information, it is helpful to understand the basic structure. Each report contains metadata about the reporting organization (like Google) and the date range it covers. More importantly, it lists every IP address that sent email claiming to be from your domain.
For each sending IP, the report shows a count of messages and the authentication results. The key section is <policy_evaluated>, which tells you if the messages passed or failed SPF and DKIM checks from DMARC's perspective. It also shows the <disposition>, which is the policy that was applied (none, quarantine, or reject). This information helps you understand what messages are passing and which are not.
Finally, the <auth_results> section gives you the raw SPF and DKIM results, including the domain that was checked for each. This is crucial for troubleshooting matching issues, which we will cover next. Understanding these basic components is the first step to taming your DMARC reports and making them work for you.
Common DMARC issues and how to spot them
The most common reason for a DMARC fail error is a misconfiguration known as a domain mismatch. For DMARC to pass, the domain used in the SPF check (the Return-Path domain) or the DKIM signature (the d= tag) must match the domain in the visible 'From' address. This is a security feature to prevent spoofing where the underlying authentication is technically valid but for a different domain.
You will often see this with third-party sending services. For example, you might send email through a service like Mailchimp. If you have not set up custom DKIM, the DKIM signature will be for a Mailchimp domain, not your own. Even if the DKIM check passes, DMARC will see the mismatch and record a failure for DKIM matching. The same principle applies to SPF.
Failing record (mismatched)
An email sent from a third-party service without proper configuration. The SPF check uses the service's domain, and the DKIM signature is also for the service's domain.
Reported results
SPF Result: Pass (but for mail-sender.com)
DKIM Result: Pass (but for mail-sender.com)
DMARC Matching: Fail
Passing record (matched)
The same service after configuring custom SPF and DKIM. The authentication checks now use your sending domain, matching with the 'From' address.
Reported results
SPF Result: Pass (for yourdomain.com)
DKIM Result: Pass (for yourdomain.com)
DMARC Matching: Pass
Another common source of confusing reports is email forwarding. When an email is forwarded, the intermediate server breaks the SPF chain because it is not listed in your SPF record. Luckily, DKIM signatures survive forwarding. This is why having both SPF and DKIM is so important. It provides resilience and ensures your legitimate emails still pass DMARC even in complex delivery scenarios.
A step-by-step guide to troubleshooting
So you see failures in your reports. Do not panic. The process for fixing them is methodical. First, ensure your DMARC policy is set to p=none. This monitoring mode allows you to gather data without any risk of your emails being blocked or sent to spam. This is a critical first step that providers strongly recommend.
Next, go through your reports and identify every source IP address sending on your behalf. For each one, ask yourself if this is a legitimate service you use. You might find your corporate mail server, your marketing platform, and your transactional email provider. You might also find IP addresses you do not recognize, which could be a sign of a phishing attack.
Identify your sources: Comb through your DMARC reports to create a list of all services and servers sending email for your domain.
Authenticate legitimate senders: For each legitimate service, follow their documentation to set up matched SPF and DKIM. This usually involves adding specific DNS records.
Monitor and verify: Continue to check your DMARC set up by reviewing reports. Once you see consistent passing results for all your legitimate traffic, you are ready to enforce a stricter policy.
Enforce your policy: Gradually update your DMARC record, first to p=quarantine and finally to p=reject, to protect your domain.
Once all your known, legitimate sources are consistently passing DMARC with proper matching, you can begin the journey to enforcement. This involves updating your DMARC policy from p=none to p=quarantine. This tells receivers to send unauthenticated mail to the spam folder. After a period of monitoring at quarantine, and seeing no issues with legitimate mail, you can take the final step to p=reject, instructing them to block unauthorized mail entirely.
Navigating DMARC reports from Google and Yahoo is a manageable and incredibly valuable process. By moving from monitoring to enforcement, you actively defend your brand, protect your customers from phishing attacks, and improve your overall email deliverability. It turns a confusing chore into a powerful security tool.
Remember that DMARC is not a 'set it and forget it' protocol. Your sending sources can change, new services may be added, and configurations can break. Regular monitoring of your DMARC reports is key to maintaining a secure and effective email program long-term.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
