How often are DMARC aggregate reports sent?

Most mailbox providers send DMARC aggregate reports once every 24 hours, though some may send them more frequently. Reports arrive as gzip-compressed XML files attached to emails sent to the address specified in your DMARC record's rua tag. If your domain receives mail from many providers, you may get dozens of reports per day.

Why do legitimate emails fail in DMARC reports?

Legitimate emails can fail DMARC for several reasons: email forwarding breaks SPF because the forwarding server's IP is not in your SPF record; mailing lists may modify message content and break DKIM signatures; third-party services sending on your behalf may not have proper DKIM signing or SPF authorization; and alignment failures can occur when the signing domain does not match the From header domain.

Can I read DMARC XML reports without a tool?

Yes, DMARC aggregate reports are standard XML files that you can open in any text editor or web browser. However, raw XML is difficult to interpret at scale. For domains receiving large volumes of reports, a DMARC analyzer tool aggregates data across multiple reports and provides visualizations that make it much easier to identify patterns, track trends, and spot issues.

How do I use DMARC reports to move from p=none to p=reject?

Start by collecting reports at p=none to identify all legitimate sending sources. Fix any authentication failures for authorized senders by configuring SPF and DKIM correctly. Once all legitimate sources consistently pass DMARC, move to p=quarantine with a low pct value (such as 10%) and monitor for any impact. Gradually increase the percentage, and when you are confident that no legitimate mail is affected, move to p=reject.

What does it mean when SPF passes but alignment fails?

SPF pass means the sending server's IP is authorized in the SPF record for the Return-Path domain. Alignment failure means the Return-Path domain does not match the From header domain. For DMARC to pass via SPF, both the SPF check and domain alignment must succeed. This commonly occurs when a third-party service uses its own Return-Path domain instead of yours. The fix is to configure the service to use a custom Return-Path domain that matches your From domain.

How to Read a DMARC Report: XML Guide with Examples (2026)

Q: What is the difference between DMARC aggregate and forensic reports?

Aggregate reports (rua) provide statistical summaries of authentication results across all messages from your domain over a time period, typically 24 hours. Forensic reports (ruf) contain details about individual messages that failed DMARC evaluation. Aggregate reports are widely supported and recommended for ongoing monitoring, while forensic reports are sent by fewer providers due to privacy concerns.

Every mailbox provider that receives email from your domain generates DMARC aggregate reports and sends them to the address specified in your DMARC record's rua tag. These reports are the only way to get a complete picture of who is sending email as your domain and whether those messages are passing authentication. Without reading and acting on DMARC reports, you are operating blind.

This guide walks you through the XML structure of a DMARC aggregate report with a realistic annotated example, explains what each element means, and shows you how to identify common patterns that indicate healthy authentication, forwarding issues, misconfigurations, and spoofing attempts. Whether you are reading your first report or planning a path from p=none to p=reject, this is the reference you need.

What Is a DMARC Aggregate Report?

A DMARC aggregate report is an XML document that summarizes how a receiving mail server handled messages claiming to originate from your domain over a specific time period, usually 24 hours. When you publish a DMARC DNS record with a rua tag, you are telling mailbox providers where to send these reports.

The reports arrive as gzip-compressed XML files attached to emails. Each report contains three main sections:

Report metadata: Information about the organization that generated the report, a unique report ID, and the date range covered.
Policy published: Your DMARC record as the receiving server saw it at the time of evaluation, including your policy, subdomain policy, alignment mode, and percentage.
Records: One or more <record> entries, each representing a unique combination of source IP, authentication results, and disposition. Each record includes the message count, the action taken, and detailed SPF and DKIM results.

Where Do Reports Come From?

Reports are generated by any mailbox provider that supports DMARC reporting, including Gmail, Yahoo, Microsoft Outlook, Apple iCloud, and many others. If your domain sends email to recipients at these providers, you will receive reports from each one. A domain sending to diverse audiences may receive dozens of reports per day from different providers.

Anatomy of a DMARC Report: Full XML Example

Below is a realistic DMARC aggregate report XML structure. This example shows a report from Google covering the domain example.com, with three record entries representing different sending scenarios: a legitimate mail server passing all checks, a forwarded message with mixed results, and an unauthorized source failing everything.

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>

  <!-- Section 1: Report Metadata -->
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>17084523456789012345</report_id>
    <date_range>
      <begin>1708387200</begin>  <!-- 2026-02-20 00:00 UTC -->
      <end>1708473600</end>      <!-- 2026-02-21 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- Section 2: Your Published DMARC Policy -->
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>      <!-- DKIM alignment: r=relaxed -->
    <aspf>r</aspf>        <!-- SPF alignment: r=relaxed -->
    <p>none</p>          <!-- Domain policy -->
    <sp>none</sp>        <!-- Subdomain policy -->
    <pct>100</pct>      <!-- Percentage of messages subject to policy -->
  </policy_published>

  <!-- Record 1: Legitimate mail server - all pass -->
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>1524</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <!-- Record 2: Forwarded message - SPF fail, DKIM pass -->
  <record>
    <row>
      <source_ip>203.0.113.50</source_ip>
      <count>87</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>example.com</domain>
        <result>pass</result>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

  <!-- Record 3: Unauthorized source - both fail -->
  <record>
    <row>
      <source_ip>192.0.2.99</source_ip>
      <count>4312</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

</feedback>

The rest of this guide walks through every element of this report so you understand exactly what you are looking at and what action to take.

Annotated Walkthrough of Each XML Element

Report Metadata

The <report_metadata> section tells you who generated the report and what time period it covers.

<org_name>: The organization that sent the report. In our example, google.com means this report came from Gmail's infrastructure. You will also see reports from yahoo.com, outlook.com, mail.ru, and others.
<email>: The contact email for the reporting organization. You generally do not need to contact them unless you suspect report delivery issues.
<report_id>: A unique identifier for this specific report. Useful for tracking and deduplication if you process reports programmatically.
<date_range>: The <begin> and <end> timestamps in Unix epoch format define the period covered. Most reports cover a 24-hour window. Convert these timestamps to human-readable dates to understand which day the report represents.

Policy Published

The <policy_published> section reflects your DMARC DNS record as the receiving server interpreted it at the time of message evaluation.

<domain>: The domain this DMARC policy applies to.
<adkim>: DKIM alignment mode. r means relaxed (organizational domain match is sufficient), s means strict (exact domain match required).
<aspf>: SPF alignment mode. Same as DKIM: r for relaxed, s for strict.
<p>: Your domain policy. Values are none (monitor only), quarantine (send to spam), or reject (block the message).
<sp>: Your subdomain policy. If not set explicitly, it inherits from <p>.
<pct>: The percentage of failing messages that the policy applies to. 100 means the policy applies to all messages. You can use lower values during rollout to limit impact.

Why Does Policy Published Matter?

If your policy shows as none in reports but you have already updated your DNS to quarantine, the report was generated before the DNS change propagated. Always check the <date_range> to confirm the report's time period relative to your DNS changes.

Record Entries

Each <record> represents a group of messages sharing the same source IP and authentication results. This is where the actionable data lives.

<source_ip>: The IP address that sent the messages. This is the most critical piece of information. You need to determine whether this IP belongs to an authorized sender (your ESP, your mail server, a legitimate third-party service) or an unauthorized source.
<count>: The number of messages from this source IP during the reporting period. High counts from unknown IPs are a strong indicator of spoofing or abuse.
<disposition>: The action the receiving server took. none means delivered normally, quarantine means sent to the spam folder, and reject means the message was blocked entirely.
<dkim> (in policy_evaluated): Whether DKIM passed the DMARC evaluation, including alignment. A pass here means both the DKIM signature was valid and the signing domain aligned with the From header domain.
<spf> (in policy_evaluated): Whether SPF passed the DMARC evaluation, including alignment. A pass here means the sending IP was in the SPF record and the domain aligned with the From header.

Auth Results vs Policy Evaluated

This distinction is one of the most commonly misunderstood parts of DMARC reports. The <auth_results> section shows the raw authentication check results, while <policy_evaluated> shows the DMARC-level verdict after applying alignment.

Authentication Pass Does Not Mean DMARC Pass

A message can show SPF pass in <auth_results> but SPF fail in <policy_evaluated>. This happens when the SPF domain (Return-Path) does not align with the From header domain. For DMARC to pass, you need both an authentication pass and alignment for at least one of SPF or DKIM.

Step-by-Step: Reading Your First DMARC Report

If you have just enabled DMARC reporting and received your first batch of XML files, follow this process to make sense of them.

Decompress the report file.

Reports arrive as .gz or .zip attachments. Extract the XML file using any archive utility. The filename typically follows the pattern: receiver!yourdomain!begindate!enddate.xml.

Check the report metadata.

Identify which provider sent the report (<org_name>) and the time period covered (<date_range>). This tells you which mailbox provider is reporting and for which day.

Verify your published policy.

Check the <policy_published> section to confirm the receiver saw your intended DMARC policy. If it shows an outdated policy, the report was generated before your latest DNS update took effect.

List all source IPs and categorize them.

Go through every <record> and extract the <source_ip>. Look up each IP using a WHOIS tool or reverse DNS lookup. Categorize each IP as: your primary mail server, your ESP, an authorized third-party service, a known forwarding service, or unknown and unauthorized.

Check authentication results for each category.

For authorized sources, verify that both SPF and DKIM show pass with alignment. For unknown sources, check the message count to gauge the severity. A few messages from a forwarding server is different from thousands from an unrecognized IP.

Identify what needs fixing and take action.

Authorized senders failing authentication need SPF or DKIM configuration fixes. Unknown senders with high volumes and complete failures are likely spoofing your domain. Use this data to plan your move toward a stricter DMARC policy.

DMARC Aggregate vs Forensic Reports

DMARC defines two types of reports: aggregate reports (specified by the rua tag) and forensic reports (specified by the ruf tag). Understanding the difference is important for setting up your reporting strategy. For a complete deep-dive, see our DMARC aggregate vs forensic reports comparison.

Feature	Aggregate Reports (rua)	Forensic Reports (ruf)
Content	Statistical summary of all messages	Details of individual failing messages
Format	XML	AFRF (RFC 6591) or IODEF
Frequency	Usually every 24 hours	Near real-time per failure
Provider Support	Widely supported	Limited (many providers do not send them)
Privacy Impact	Low (aggregated data, no message content)	Higher (may include headers or message body)
Primary Use	Monitoring authentication across all sources	Investigating specific failure incidents
DMARC Tag	`rua=mailto:address`	`ruf=mailto:address`
Recommended	Always (essential for DMARC management)	Optional (useful for forensic investigation)

Aggregate reports are the foundation of DMARC management. Every domain with a DMARC record should configure a rua address. Forensic reports are a supplementary tool that can help diagnose specific incidents but should not be relied upon as your primary data source due to limited provider support.

Common DMARC Report Patterns and What They Mean

Once you have reviewed several reports, you will start to recognize recurring patterns. Here are the most common scenarios and what they tell you about your email authentication health.

Healthy

Pattern: All Pass from Known IP

SPF: pass | DKIM: pass | Alignment: pass | Disposition: none

This is the ideal result. The source IP belongs to your authorized mail server or ESP, both SPF and DKIM pass with alignment, and the message was delivered normally. If all of your legitimate sending sources show this pattern, your authentication is in good shape and you are ready to consider moving toward a stricter policy.

Expected Behavior

Pattern: SPF Fail, DKIM Pass (Forwarding)

SPF: fail | DKIM: pass | Alignment: DKIM pass | Disposition: none

This pattern is common and usually indicates email forwarding. When a recipient forwards your email to another address, the forwarding server's IP is not in your SPF record, so SPF fails. However, if the forwarding server did not modify the message body or DKIM-signed headers, DKIM remains valid. Since DMARC only needs one mechanism (SPF or DKIM) to pass with alignment, the message still passes DMARC. Look up the source IP to confirm it belongs to a known forwarding service or mail provider.

Spoofing Alert

Pattern: Both Fail from Unknown IP

SPF: fail | DKIM: fail | Alignment: fail | Disposition: none (if p=none) or reject

When an unknown IP fails both SPF and DKIM, this is almost certainly an unauthorized party sending email as your domain. Check the <count> value to understand the scale. In our XML example above, Record 3 shows 4,312 messages from IP 192.0.2.99 with complete authentication failure. This is a spoofing attempt. If your policy is p=none, these messages are still being delivered, which underscores the importance of moving toward enforcement.

Misconfiguration

Pattern: Auth Pass but Alignment Fail

SPF auth_results: pass | SPF policy_evaluated: fail | DKIM: fail | Disposition: none

This pattern indicates a configuration problem with one of your legitimate sending services. The SPF check passes (the IP is authorized), but alignment fails because the Return-Path domain does not match the From header domain. This commonly happens when a third-party ESP uses its own bounce domain (Return-Path) instead of a custom one matching your From domain. The fix is to configure a custom Return-Path domain in your ESP settings and update your SPF record accordingly. Similarly, ensure DKIM signing uses your domain rather than the ESP's default.

Best DMARC Report Analyzer Tools

While you can read raw XML reports manually, processing them at scale requires dedicated tools. DMARC analyzer tools aggregate data from multiple reports, visualize trends over time, and alert you to issues that need attention. Here are widely used options:

dmarcian: A comprehensive DMARC management platform that provides detailed visualizations, source identification, and guided policy progression. Particularly strong at helping organizations move from p=none to p=reject with a structured workflow.
Valimail: An automated DMARC enforcement platform that focuses on identifying and authorizing legitimate senders. Offers automated SPF and DKIM management alongside report analysis.
EasyDMARC: Provides report aggregation, source monitoring, and a step-by-step approach to DMARC enforcement. Includes tools for SPF, DKIM, and DMARC record generation and validation.
Postmark DMARC: A free weekly DMARC digest service that summarizes your aggregate reports into a readable email. A good starting point for smaller organizations that want basic visibility without a full platform.
MXToolbox DMARC Report Analyzer: A free tool for parsing individual DMARC XML files. Upload a report file and get a formatted, human-readable breakdown. Useful for spot-checking individual reports without committing to a paid platform.
Google Postmaster Tools: While not a DMARC-specific analyzer, Google Postmaster Tools provides authentication pass rates and domain reputation data specifically for Gmail traffic. Essential for any sender targeting Gmail recipients and a good complement to DMARC report data.

Choosing a Tool

If you are just starting with DMARC, a free option like Postmark DMARC or MXToolbox gives you basic visibility. As your domain's email complexity grows or you begin moving toward enforcement, a dedicated platform like dmarcian, Valimail, or EasyDMARC provides the workflow and automation needed to manage the process safely.

How to Set Up DMARC Reporting

Before you can receive DMARC reports, you need to publish a DMARC DNS record with the appropriate reporting tags. Here is how to configure both aggregate and forensic reporting.

The rua Tag: Aggregate Reports

The rua tag specifies where aggregate reports should be sent. This is the most important tag for DMARC monitoring. Add it to your DMARC TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

You can specify multiple rua addresses separated by commas if you want reports sent to more than one destination, such as your own mailbox and a third-party analyzer:

v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]

The ruf Tag: Forensic Reports

The ruf tag specifies where forensic (failure) reports should be sent. These reports contain details about individual messages that failed DMARC evaluation:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]

Forensic Report Limitations

Many mailbox providers do not send forensic reports due to privacy concerns. Gmail, for example, does not support ruf reporting. Do not rely on forensic reports as your primary source of DMARC data. Always configure rua for aggregate reports as your baseline.

Sending Reports to an External Domain

If your rua address is at a different domain than the one being monitored (for example, you want example.com reports sent to analyzer.example.net), the receiving domain must publish a special DNS record to authorize this. The receiving domain needs a TXT record at:

example.com._report._dmarc.analyzer.example.net  TXT  "v=DMARC1"

Without this authorization record, mailbox providers will not send reports to the external address. Most third-party DMARC analyzer services provide instructions for setting up this DNS record as part of their onboarding process.

Controlling Report Frequency

You can use the ri tag to request a specific reporting interval in seconds. The default is 86400 (24 hours). While you can request more frequent reporting, not all providers honor this tag:

v=DMARC1; p=none; rua=mailto:[email protected]; ri=43200

This requests reports every 12 hours. In practice, most providers send reports on their own schedule regardless of the ri value, so treat this as a preference rather than a guarantee.

Moving from p=none to p=reject Using Report Data

The ultimate goal of DMARC is to reach p=reject, which instructs receiving servers to block any message that fails DMARC evaluation. Getting there safely requires a methodical, data-driven approach using your aggregate reports. Rushing this process can cause legitimate email to be blocked. This progression is also important for meeting the evolving requirements from Gmail and Yahoo, both of which now require DMARC and recommend enforcement policies.

Phase 1: Monitor with p=none

Start with p=none and a rua address. At this stage, no email is affected by your DMARC policy regardless of authentication results. Your only goal is to collect data.

Collect reports for at least 4 to 6 weeks to capture all sending sources, including infrequent ones like monthly newsletters or quarterly notifications.
Build a complete inventory of every IP address and service that sends email as your domain.
For each source, determine whether it is authorized, and if so, whether it passes both SPF and DKIM with alignment.

Phase 2: Fix Authentication Failures

Before changing your policy, every authorized sending source must pass DMARC. Common fixes include:

SPF failures: Add the sending service's IP ranges or include mechanism to your SPF record. Ensure the Return-Path domain aligns with your From domain.
DKIM failures: Configure DKIM signing for each sending service using your domain. Verify signatures are valid and the signing domain aligns with your From domain.
Alignment failures: Configure custom Return-Path domains and DKIM signing domains in your ESP and third-party service settings so they match your From header domain.

After making fixes, continue monitoring reports for another 2 to 4 weeks to confirm that the changes resolved the failures across all providers.

Phase 3: Move to p=quarantine with a Low Percentage

Once all legitimate sources consistently pass, move to p=quarantine with a low pct value to limit the impact:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=10

This applies the quarantine action to only 10% of failing messages. Monitor your reports closely for any unexpected impact on legitimate email. If you see authorized sources suddenly appearing with quarantine dispositions, stop and fix the issue before proceeding.

Gradually increase the percentage: 10% for one to two weeks, then 25%, then 50%, then 100%. At each stage, review reports to confirm no legitimate email is being quarantined.

Phase 4: Move to p=reject

After running at p=quarantine; pct=100 for several weeks with no impact on legitimate email, you are ready for full enforcement:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

At this point, any message that fails DMARC evaluation will be rejected outright by receiving servers. Continue monitoring reports permanently. New sending sources, configuration changes, or service migrations can introduce authentication failures that need to be addressed promptly.

The Payoff of p=reject

Reaching p=reject means that unauthorized parties can no longer successfully spoof your domain to major mailbox providers. This protects your brand reputation, reduces phishing risk for your customers and partners, and improves your overall email deliverability. Domains with p=reject also qualify for BIMI (Brand Indicators for Message Identification), which displays your logo next to authenticated messages in supported email clients.

Troubleshooting Common DMARC Report Issues

Not Receiving Any Reports

If you have published a DMARC record with a rua tag but are not receiving reports, check the following:

Verify your DMARC record is published correctly at _dmarc.yourdomain.com using a DNS lookup tool.
Confirm the rua email address is correct and the mailbox exists and is not full.
Check your spam folder. Report emails from providers like Google may be filtered by your own spam rules.
If using an external reporting domain, ensure the authorization DNS record is in place.
Allow 48 to 72 hours after publishing your DMARC record before expecting the first reports.

Reports Show Unexpected Source IPs

Unknown IPs in your reports are not always malicious. Before taking action, investigate:

Third-party services: SaaS tools that send email on your behalf (helpdesks, CRMs, marketing platforms) may use IP addresses you do not recognize. Check with your team to identify all authorized services.
Forwarding servers: When recipients auto-forward your email, the forwarding server's IP appears in reports. These are generally low-volume and show SPF fail with DKIM pass.
Cloud infrastructure: If you use cloud hosting, IP addresses may change. Ensure your SPF record covers the current ranges used by your cloud provider.

High Volume of Failures Despite Correct Configuration

If you have configured SPF and DKIM correctly but still see a high failure rate in reports, the failures may come from spoofing attempts. This is actually DMARC working as intended. The reports are showing you the volume of unauthorized email claiming to be from your domain. At p=none, these messages are still delivered, but moving to p=reject will block them.

How to Read and Interpret a DMARC Report