Understanding and troubleshooting DMARC reports from Google and Yahoo
Published 11 Jul 2025
Updated 22 Oct 2026
14 min read
Summarize with
Updated on 22 Oct 2026: We clarified report interpretation and policy testing, added message-header checks, and expanded troubleshooting for missing reports.
Google and Yahoo DMARC reports show which servers sent mail claiming to use your domain, whether those messages passed SPF or DKIM, whether either result matched the visible From domain, and what policy action the receiver selected. Use them to separate legitimate senders that need DNS or signing fixes from unknown sources that should remain unauthenticated before a stronger DMARC policy is published.
Each receiver reports only the traffic it sees, so Google and Yahoo reports cover different message samples. If both receivers show the same known sender failing DMARC, start with its authentication setup. If only one receiver shows failures, check forwarding, mailing lists, ARC handling, and receiver-specific authentication behavior before changing DNS.
- Confirm the source IP belongs to a sender you use, then check whether SPF or DKIM passed with a domain that matches the visible From address under your alignment settings.
- Group failures by sender and reporting window. One failed forwarded message does not mean the whole platform is broken.
- Only tighten policy after legitimate senders pass DMARC and the remaining failures have been investigated.
How Google and Yahoo reports work
To request aggregate DMARC reports from Google and Yahoo, include a rua address in your DMARC record. Reports generally cover a daily reporting window and contain grouped results rather than individual message bodies. A row with count 500 means the receiver grouped 500 messages with the same reported source, identifiers, and evaluation outcome. Reports arrive as XML attachments, often GZIP-compressed as .xml.gz.
Receiving a report is routine when your address is listed in rua; it is not evidence of a compromised account. Google or Yahoo is reporting on mail it received that claimed to use your domain. To redirect reports to a dedicated mailbox or Suped, change the rua destination while keeping the intended DMARC policy.
Google's own documentation says DMARC reports help identify servers and third-party senders using your domain, the percentage of mail that passes DMARC, failing sources, and the action taken on unauthenticated mail. Google's report guidance provides a useful baseline for the XML fields. Emailed XML reports are separate from authentication views in Google Admin Console.
Illustrative Google Admin Console authentication view showing SPF, DKIM, and DMARC results.
|
|
|
|---|---|---|
source_ip | The connecting IP seen by Google or Yahoo, including a forwarder when mail is forwarded. | Map it to a known mail source. |
count | How many messages matched the row. | Prioritize high-volume rows first. |
header_from | The visible From domain evaluated by DMARC. | Compare it with authenticated SPF and DKIM domains. |
policy_evaluated/spf | Whether a passing SPF identifier aligned for DMARC. | Inspect the envelope domain in auth_results. |
policy_evaluated/dkim | Whether a passing DKIM signature aligned for DMARC. | Inspect the signing domain in auth_results. |
disposition | The DMARC policy disposition selected by the receiver. | Do not treat it as proof of inbox placement. |
Core fields to inspect before changing DNS or policy.
The report is not the message
Aggregate DMARC reports do not contain the email content, subject line, or full recipient list. They show grouped authentication outcomes at receiver level. Do not confuse them with message-specific failure reports requested through ruf; receivers are not required to send those reports.
External authorization for reports sent to dmarc@reports.example.netDNS
Host: example.com._report._dmarc.reports.example.net Value: v=DMARC1;
For a policy published for example.com with rua=mailto:dmarc@reports.example.net, the administrator of reports.example.net publishes this TXT authorization record in the destination's DNS zone. A wildcard authorization can also authorize the destination. Without valid external authorization, receivers must ignore that destination. This is separate from publishing the domain's DMARC policy.
Check report metadata and overrides first
Before diagnosing a sender row, confirm who generated the report, which period it covers, and which DMARC policy the receiver saw. A DNS change made during the reporting window can produce mixed results, and the published-policy snapshot can lag the record currently visible in DNS.
|
|
|
|---|---|---|
org_name | The receiver that generated the report. | Separate Google and Yahoo observations. |
date_range | The UTC reporting window as Unix timestamps. | Compare changes only after the relevant window closes. |
report_id | The receiver's unique identifier for the report. | Deduplicate resent reports using the reporter, policy domain, report ID, and reporting window before totaling volume. |
policy_published | The policy and alignment modes seen for the report. | Compare the snapshot with the intended DNS record. |
reason | Why the receiver overrode the requested policy. | Check local policy, mailing-list, testing, or trusted-forwarder context. |
error | A receiver-reported policy or reporting problem. | Read the specific error; check record syntax and duplicate DMARC records before changing sender settings. |
Metadata and exception fields that can change the interpretation.
An override changes the policy action, not authentication
A policy override reason such as mailing_list, trusted_forwarder, policy_test_mode, local_policy, or other explains why the receiver did not apply the published action. It does not turn failed SPF or DKIM into a DMARC pass.
Troubleshoot Google and Yahoo DMARC failures
Troubleshoot Google and Yahoo reports in this order to reduce false fixes. A DMARC row can fail because the sender is unauthorized, a legitimate sender is not signing correctly, or forwarding changed the path after the original authentication happened.
DMARC report troubleshooting steps for identifying senders and checking SPF and DKIM alignment.
- Identify the source IP and compare it with your known mail platforms, CRM systems, help desk tools, billing systems, website servers, and forwarding services. Confirm ownership with sending logs or the responsible team; a shared IP or reverse DNS name alone is not proof.
- If nobody owns the source, do not add it to SPF just to make the report green. Investigate forwarding and forgotten senders before classifying it as unwanted traffic.
- Inspect SPF. With aspf=r, the authenticated envelope domain must share the organizational domain of the visible From address. With aspf=s, the domains must match exactly.
- Inspect DKIM. A passing signature must use a signing domain that matches the visible From domain under adkim=r (the same organizational domain) or adkim=s (an exact match). Relaxed alignment is the default for both methods.
- Read the policy result. If the report says disposition none, the receiver did not apply a DMARC quarantine or reject action. Separate filtering can still affect delivery.
If the record itself looks invalid, run the domain through our DMARC checker before editing DNS. Syntax mistakes in the DMARC TXT record can cause receivers to ignore the policy completely.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Google report patterns
- Group Google rows by source and count to identify the business senders responsible for your Gmail traffic.
- Forwarded mail can show SPF failure even when matching DKIM survives and DMARC still passes.
- Google requires bulk senders to set up SPF and DKIM and publish DMARC with at least p=none. A DMARC pass still needs only one passing method with the required domain match.
Yahoo report patterns
- Review Yahoo and AOL rows for failures in the mail streams that actually reach those recipients.
- Repeated rows for the same platform are a reason to check that platform's authentication settings.
- Yahoo requires bulk senders to use SPF and DKIM, publish at least p=none, and pass DMARC through matching SPF or DKIM. Relaxed alignment is acceptable.
How to read DMARC report XML
Raw DMARC XML looks intimidating, but only a small set of fields is needed for a useful decision. The row shows where mail came from and what the receiver did. The identifiers show the visible From domain. The auth results show which domains passed SPF and DKIM.
Simplified legacy-format DMARC aggregate report exampleXML
<feedback> <report_metadata> <org_name>google.com</org_name> <email>noreply-dmarc-support@google.com</email> <report_id>abc-123</report_id> <date_range> <begin>1786665600</begin> <end>1786751999</end> </date_range> </report_metadata> <policy_published> <domain>example.com</domain> <p>none</p> <adkim>r</adkim> <aspf>r</aspf> </policy_published> <record> <row> <source_ip>203.0.113.10</source_ip> <count>42</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>mail.example.com</domain> <selector>news</selector> <result>pass</result> </dkim> <spf> <domain>bounce.sender.example</domain> <scope>mfrom</scope> <result>fail</result> </spf> </auth_results> </record> </feedback>
In this example, SPF failed but DKIM passed with mail.example.com. Under relaxed alignment, that signing domain shares the organizational domain example.com with the visible From address, so this row passes DMARC through DKIM. DMARC needs one aligned authentication method to pass, not both. Calculate the DMARC pass rate by summing count for rows where policy_evaluated SPF or DKIM passes, dividing by total message count, and multiplying by 100 for a percentage. Count each passing row once, even when both methods pass.
The policy_evaluated results include the DMARC domain-match test; auth_results contains raw authentication results. RFC 9990 reports use the dmarc-2.0 XML namespace and add fields such as testing and discovery_method, plus disposition pass for DMARC-passing mail under an enforcement policy. Read older reports in their original format rather than assuming those fields are present.
Do not fix the wrong layer
- For SPF failure, check sending IP authorization at the envelope domain. Forwarding failures need path investigation rather than adding the forwarder to your SPF record.
- For DKIM failure, check the selector and public key, then investigate message changes after signing.
- For DMARC failure, check authentication and domain alignment. A sender can pass SPF or DKIM and still fail DMARC when neither passing domain matches the visible From domain.
- For a policy override, investigate the receiver's stated reason before treating disposition as an authentication result.
For deeper source interpretation, use the separate checklist for interpreting DMARC reports. That is where sender identification, failure type grouping, and low-volume anomalies deserve more detail.
Common DMARC failures and fixes
Most Google and Yahoo DMARC failures fall into predictable buckets. Start with the highest-count row, map the sender, then make one sender-specific fix at a time. Bulk edits to SPF, DKIM, and DMARC at once make it harder to prove which change worked.
|
|
|
|---|---|---|
SPF pass, DMARC fail | The passing envelope domain does not match under aspf, and there is no matching DKIM pass. | Configure a custom Return-Path that meets aspf, or enable matching DKIM signing. |
DKIM pass, DMARC fail | The passing signing domain does not match under adkim, and there is no matching SPF pass. | Configure a custom DKIM signing domain that meets adkim. |
SPF and DKIM fail | Sender is not configured or not authorized. | If legitimate, authorize its envelope path and enable aligned DKIM. If unknown, do not authorize it. |
Only forwarded mail fails DMARC | Forwarding breaks SPF, and no passing DKIM signature with the required domain match survives. | Preserve matching DKIM where possible. ARC can inform receiver handling, but it does not turn a DMARC failure into a pass. |
Unknown IP repeats | An unidentified sender, forwarding service, or spoofing attempt. | Check sender ownership and forwarding before classifying the traffic. Do not add unknown IPs to SPF. |
SPF permerror | Invalid or multiple SPF records, or too many DNS-querying terms. | Publish one SPF record at the envelope domain and keep evaluation within the 10-term DNS lookup limit, including nested includes and redirects. |
DKIM fails after key rotation | The sender uses a selector whose public key is missing or no longer matches. | Publish the correct selector key, verify signing, and retain old keys until queued mail signed with them has cleared. |
Use the report symptom to choose the fix, not guesswork.
Check auth_results or message headers for temperror versus permerror. A temperror calls for checking temporary DNS failures and repeating the test; a permerror calls for investigating persistent record or configuration problems.
A clean starting record for monitoring uses p=none with a working aggregate report address. If you need to create one safely, use our record generator and then publish one DMARC TXT record at _dmarc.example.com, replacing example.com with your domain. The records below are alternatives; publish only one.
Alternative DMARC records for monitoring and enforcementDNS
v=DMARC1; p=none; rua=mailto:dmarc@reports.example.com; v=DMARC1; p=quarantine; rua=mailto:dmarc@reports.example.com; v=DMARC1; p=reject; rua=mailto:dmarc@reports.example.com;
RFC 9989 defines t=y as a testing request: quarantine becomes none, and reject becomes quarantine at receivers implementing it. Older receivers ignore unknown tags and can apply the full published policy, so do not rely on t=y to prevent enforcement. The pct tag is historic under RFC 9989; legacy reports can still contain pct or sampled_out.
Verify report failures against message headers
Send a controlled test through the affected sending platform to Gmail and Yahoo, then open the full message headers. In Gmail, use Show original. Read the receiving provider's trusted Authentication-Results header and match the test's sending path to the failing report rows. A direct test does not reproduce a failure that happens only after forwarding.
Illustrative headers: SPF and DKIM pass, but DMARC failstext
From: Accounts <accounts@example.com> Return-Path: <bounce@bounce.sender.example> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.sender.example; dkim=pass header.d=sender.example header.s=news; dmarc=fail header.from=example.com
Both methods pass here, but neither authenticated domain matches example.com, so DMARC fails. Configure custom DKIM signing for example.com or an envelope domain that meets the applicable alignment mode. Changing Reply-To does not affect DMARC.
- Compare smtp.mailfrom with the visible From domain for SPF alignment, and header.d with the visible From domain for DKIM alignment. Check every reported DKIM signature; one passing signature with the required domain match is enough.
- Read d= and s= in DKIM-Signature to identify the signing domain and selector. The public key is published at selector._domainkey.signing-domain; verify any CNAME target supplied by the sender.
- Compare Received headers with sending logs to identify forwarding or mailing-list changes. If the message was rejected before delivery, use the SMTP rejection and sender logs to investigate the failed attempt.
After fixing the sender, repeat the same test and compare the next complete reporting windows after DNS caches expire. For further header-level checks, use troubleshooting DMARC failures.
When to tighten policy
Do not move a domain straight to reject because a week of reports looks mostly clean. Check for stable legitimate-sender coverage and no unresolved high-value systems such as billing, password reset, payroll, support, or executive mail. Include infrequent and monthly sending jobs. Measure legitimate mail separately from suspected spoofing; low unknown volume is not a prerequisite for enforcement.
Policy readiness bands
A practical way to stage DMARC policy after reviewing Google and Yahoo reports.
Monitor
p=none
You are still identifying sources and fixing legitimate senders.
Quarantine
p=quarantine
Legitimate senders pass DMARC, and you are reviewing the effect of actual quarantine policy.
Strong enforcement
p=reject
Legitimate traffic is stable, the domain is suitable for reject, and testing mode is off.
General-purpose domains whose users post to Internet mailing lists need extra caution. RFC 9989 says such domains should not publish p=reject because mailing-list changes can break authentication and cause interoperability problems. For those domains considering reject, it recommends at least a month at p=none followed by an equally long period at p=quarantine to assess the impact.
Before tightening policy, run a broader domain health check. Check SPF, DKIM, DMARC, DNS, and mail server basics together. DMARC enforcement addresses domain spoofing, but it does not fix broken DNS, missing DKIM keys, or a mail server reputation issue by itself.
Enforcement exposes hidden senders
The first enforcement step can expose forgotten, low-volume senders. Check finance, HR, product, support, sales, and marketing systems before changing policy.
Use Suped to track report fixes
Manual report reading works for a small domain with one or two senders. Reviewing XML takes more work as the number of senders and domains grows. Suped, our DMARC and email authentication platform, groups Google, Yahoo, and other receiver reports by source so you can investigate failures through our DMARC monitoring workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped to identify a sender, follow the issue's steps to fix, and check later reports for the result. Alerts based on aggregate reports follow the receiver's reporting schedule. Review small, stable domains weekly and check reporting windows after each sender or policy change.
Manual report inbox
- You decompress XML, normalize rows, and map IPs by hand.
- Each source needs separate investigation before anyone knows the next step.
- Check low-volume senders before moving to quarantine or reject.
Suped workflow
- Google and Yahoo reports are grouped into verified and unverified senders for review.
- Issues include tailored steps, DNS context, and verification actions.
- Review known-sender coverage and later reporting windows before changing hosted DMARC policy.
Frequently asked questions
They see different recipient traffic, forwarding paths, and sender behavior. If the same known sender fails at both, start with its authentication setup. If it fails at only one, compare report windows and inspect forwarding and that receiver's authentication headers before changing DNS.
No. DMARC can pass when DKIM passes and the signing domain matches the visible From domain. SPF failure is common with forwarding, so DKIM is often the more reliable path.
It means the receiver did not apply a DMARC quarantine or reject action. The message can still fail DMARC, and separate spam or security filters can still affect final delivery.
No. Monitor first, fix legitimate senders, and review actual quarantine results before reject. Do not rely on t=y to prevent enforcement at receivers that ignore it. Domains used by people who post to Internet mailing lists need extra caution with reject.
Check for one valid DMARC record with a rua=mailto: destination, working mailbox routing, available storage, and external authorization when required. Check spam folders and attachment filtering for XML or GZIP files. Allow a daily reporting cycle after relevant mail reaches Google or Yahoo and DNS caches expire. Reports are not guaranteed, and no report is not proof of no spoofing.
The report contains the policy snapshot seen during its reporting window. DNS caching or a policy change during that window can make it differ from the record you see now, so compare the date range before troubleshooting.
