Understanding DMARC Reports

You set up DMARC. Reports are arriving. Now you’re staring at XML files wondering what any of it means.

This guide explains what DMARC reports contain, how to read them, and what to do with the information. By the end, you’ll know exactly what’s happening with email sent from your domain.

What Are DMARC Reports?

When you publish a DMARC record with an rua tag, you’re asking email receivers to send you reports about messages they see claiming to be from your domain.

These reports tell you:

• Which IP addresses sent email as your domain
• Whether those messages passed or failed SPF and DKIM
• What the receiver did with the messages (delivered, quarantined, rejected)
• How many messages came from each source

The data helps you identify legitimate sending sources, find authentication problems, and spot unauthorized senders.

Who Sends Reports?

Any email receiver that supports DMARC can send reports. In practice, you’ll get reports from:

• Google (Gmail, Google Workspace)
• Microsoft (Outlook.com, Office 365)
• Yahoo
• Apple (iCloud Mail)
• Comcast, Verizon, and other ISPs
• Enterprise email gateways (Proofpoint, Mimecast, Barracuda)

The volume of reports depends on where your email goes. If most of your recipients use Gmail, most of your reports come from Google.

Aggregate vs Forensic Reports

DMARC defines two report types:

RUA (Aggregate Reports)

These are the reports you’ll actually receive. They contain summary statistics about authentication results over a time period, usually 24 hours.

Aggregate reports include:

• Counts of messages per source IP
• Pass/fail status for SPF and DKIM
• The policy you had published
• What the receiver did with the messages

They don’t include message content, subject lines, or recipient addresses.

RUF (Forensic Reports)

Forensic reports contain details about individual messages that failed authentication. They were designed to help debug specific failures.

In practice, almost no one sends them anymore. Privacy regulations and abuse concerns led most major providers to stop generating RUF reports years ago. Google doesn’t send them. Microsoft doesn’t send them.

Don’t bother adding a ruf tag to your DMARC record. Focus on aggregate reports. For more details, see our RUA vs RUF comparison.

Report Delivery

Reports arrive as email attachments. The attachment is a gzip-compressed XML file.

Filename format:

receiver!yourdomain.com!start_timestamp!end_timestamp.xml.gz

Example:

google.com!yourcompany.com!1704067200!1704153599.xml.gz

This tells you Google sent a report for yourcompany.com covering January 1, 2024 (timestamps are Unix epoch format).

Subject line format:

Report Domain: yourcompany.com Submitter: google.com Report-ID: 1234567890

Timing

Most providers send reports once per day, but timing varies:

• Google usually sends reports mid-morning UTC
• Microsoft sends throughout the day
• Yahoo sends once daily
• Smaller providers may batch reports less frequently

If you’re just starting out, expect your first reports within 24-48 hours of publishing your DMARC record (assuming email was sent from your domain during that time).

Reading the XML

Here’s what a DMARC aggregate report looks like, annotated:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <!-- Who sent this report -->
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <report_id>17045678901234567890</report_id>
    <date_range>
      <begin>1704067200</begin>  <!-- Start: Jan 1, 2024 00:00 UTC -->
      <end>1704153599</end>      <!-- End: Jan 1, 2024 23:59 UTC -->
    </date_range>
  </report_metadata>

  <!-- Your DMARC policy as the receiver saw it -->
  <policy_published>
    <domain>yourcompany.com</domain>
    <adkim>r</adkim>   <!-- DKIM alignment: r=relaxed, s=strict -->
    <aspf>r</aspf>     <!-- SPF alignment: r=relaxed, s=strict -->
    <p>quarantine</p>  <!-- Policy: none, quarantine, or reject -->
    <sp>quarantine</sp> <!-- Subdomain policy -->
    <pct>100</pct>     <!-- Percentage of messages policy applies to -->
  </policy_published>

  <!-- One record per unique source/result combination -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1547</count>  <!-- Messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>  <!-- What receiver did -->
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourcompany.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourcompany.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>yourcompany.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <!-- Another record for a different source -->
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>23</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourcompany.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>otherdomain.com</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>otherdomain.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

</feedback>

Key Sections Explained

report_metadata: Information about the report itself. The org_name tells you who sent it. The date_range shows the time period covered in Unix timestamps.

policy_published: The DMARC policy the receiver saw when they checked your DNS. If this doesn’t match what you think you published, your DNS might have propagation issues or someone changed your record.

record: One entry per unique combination of source IP and authentication result. A single report typically contains many records.

row: The core data. source_ip is who sent the email. count is how many messages. disposition is what the receiver did (none = delivered normally, quarantine = spam folder, reject = blocked).

policy_evaluated: The DMARC verdict. Did DKIM pass or fail? Did SPF pass or fail? This is after alignment checking.

auth_results: The raw authentication results before alignment. Shows which domain was checked and what the result was.

Understanding Results

Pass vs Fail vs None

Result	Meaning
pass	Authentication check succeeded
fail	Authentication check failed
none	No authentication record found or check not performed

Disposition

Disposition	Meaning
none	Message delivered normally
quarantine	Message sent to spam/junk folder
reject	Message rejected, not delivered

The disposition depends on your published policy AND whether authentication passed. If your policy is p=none, disposition will be none regardless of authentication results. If your policy is p=reject and authentication fails, disposition will be reject.

Alignment

DMARC doesn’t just check whether SPF or DKIM passed. It checks whether the domain that passed matches the From header domain.

Relaxed alignment (adkim=r, aspf=r): The organizational domains must match. mail.yourcompany.com aligns with yourcompany.com.

Strict alignment (adkim=s, aspf=s): The exact domains must match. mail.yourcompany.com does NOT align with yourcompany.com.

Most organizations use relaxed alignment. Strict alignment breaks too many legitimate use cases.

Common Patterns

Pattern: High-Volume Passes from Recognized IPs

What you see:

• Thousands of messages from a handful of IPs
• All passing SPF and DKIM
• Disposition: none

What it means: This is your legitimate email infrastructure working correctly. The IPs likely belong to Google Workspace, Microsoft 365, or your email service provider.

What to do: Nothing. This is good.

Pattern: Failures from IPs You Don’t Recognize

What you see:

• Messages from unfamiliar IPs
• Failing both SPF and DKIM
• Various dispositions depending on your policy

What it means: Either someone is spoofing your domain, or you have a legitimate sending service you forgot about.

What to do:

1. Look up the IP to identify the sender (use MXToolbox or WHOIS)
2. Check the ASN and organization name
3. If it’s a service you use, add it to your SPF record and configure DKIM
4. If it’s not legitimate, this is your DMARC policy doing its job

Verkh identifies known providers automatically. Instead of seeing a raw IP address, you’ll see “SendGrid” or “Mailchimp” with their authorization status.

Pattern: SPF Pass, DKIM Fail (or Vice Versa)

What you see:

• Messages from a known service
• One authentication method passes, the other fails
• DMARC might still pass (only one needs to pass and align)

What it means: Your configuration is incomplete. The service is partially set up.

What to do: Configure the failing authentication method:

• SPF fails: Add the service’s include to your SPF record
• DKIM fails: Set up DKIM signing with the service

See our setup guides for specific providers:

• Google Workspace
• Microsoft 365
• SendGrid
• Mailchimp

Pattern: Auth Passes But From Wrong Domain

What you see:

• SPF or DKIM passes
• But the domain that passed doesn’t match your From domain
• DMARC fails due to alignment

What it means: The sending service is authenticating with its own domain instead of yours.

What to do: Configure the service to use your domain for authentication:

• For SPF: Set up a custom return path / envelope sender
• For DKIM: Configure custom DKIM signing with your domain

Most email service providers support this. Look for “branded sending,” “custom domain,” or “authenticated domain” in their settings.

Pattern: Forwarded Email Failures

What you see:

• Failures from IPs belonging to other mail servers
• SPF fails (expected)
• DKIM might pass or fail depending on whether the forwarder modified the message

What it means: Someone is forwarding your email to another address. The forwarding server’s IP isn’t in your SPF record, so SPF fails.

What to do: This is normal and expected. DKIM was designed to survive forwarding (SPF wasn’t). If DKIM is properly configured, DMARC will pass based on DKIM even when SPF fails. Learn more in our guide to why email forwarding breaks DMARC.

If you see lots of forwarding failures, make sure DKIM is configured for all your sending sources.

Pattern: Low-Volume Unknown Senders

What you see:

• Small numbers of messages (single digits) from unfamiliar IPs
• Usually failing authentication

What it means: Could be:

• Spam/phishing attempts (your policy is stopping them)
• One-off legitimate services (conference registration, web forms)
• Email testing tools

What to do: Investigate if the volume is concerning. For single-digit counts, it’s usually noise. For persistent sources with higher volumes, identify the sender and decide whether to authorize or ignore them.

What to Do With Report Data

Step 1: Identify All Legitimate Sources

Go through your reports and list every IP or service sending email as your domain. Categorize them:

• Known and authorized: Your primary email (Google Workspace, M365), your ESP (SendGrid, Mailchimp), your CRM (Salesforce, HubSpot)
• Known but not configured: Services you use but haven’t set up authentication for
• Unknown: IPs you don’t recognize

Step 2: Fix Authentication for Known Sources

For each known service that’s failing authentication:

1. Add the service to your SPF record (if SPF is failing)
2. Configure DKIM signing (if DKIM is failing)
3. Set up custom domains for alignment (if alignment is failing)

Step 3: Investigate Unknown Sources

For each unknown source:

1. Look up the IP address to find the organization
2. Check if it’s a service you might have forgotten about
3. Ask around your company if anyone recognizes it
4. If it’s not legitimate, leave it unauthorized

Step 4: Progress Toward Enforcement

Once you’ve identified and configured all legitimate sources:

1. Move from p=none to p=quarantine
2. Monitor reports for a few weeks
3. Address any new failures
4. Move from p=quarantine to p=reject

This is the path to enforcement. Your DMARC policy starts protecting your domain when you reach p=reject.

Reading Reports at Scale

Raw XML is fine for one or two reports. When you’re getting dozens of reports daily from multiple receivers, manual parsing doesn’t work.

Options:

Email forwarding to a parsing service: Point your RUA address at a service that parses reports for you.

Local parsing scripts: Open source tools exist to parse DMARC XML into databases or spreadsheets.

DMARC platforms: Purpose-built tools that ingest reports, identify sources, and guide you through remediation.

Verkh parses your reports automatically and presents the data in a dashboard. You’ll see which sources are passing, which are failing, and whether each source is a known provider. When you’re ready to fix something, you get the exact DNS records to add. When you need to coordinate with a vendor, you can generate a report or share a live dashboard link directly with their support team.

Troubleshooting Report Issues

Not Receiving Reports

Check your DMARC record:

dig +short TXT _dmarc.yourdomain.com

Make sure it includes rua=mailto:[email protected]

Verify the email address works: Send a test email to your RUA address. Make sure it arrives.

Check spam filters: Some email systems filter DMARC reports as spam. Add an exception for dmarc-reports or similar.

Wait for email volume: Reports only generate when email is sent from your domain. Low-volume domains might not see reports for days.

Reports Going to Spam

DMARC reports often trigger spam filters because they:

• Come from automated systems
• Contain XML attachments
• Have generic subject lines

Create a filter or rule to bypass spam filtering for messages with “DMARC” in the subject or from known reporter addresses like [email protected].

Can’t Open the Attachment

DMARC reports are gzip-compressed XML. Most operating systems can open .gz files natively. If not:

• Windows: Use 7-Zip
• Mac: Double-click the file
• Linux: gunzip filename.xml.gz

Timestamps Look Wrong

Report timestamps are Unix epoch (seconds since January 1, 1970 UTC). Use an online converter or:

date -d @1704067200

Quick Reference

DMARC Record Tags

Tag	Meaning
v=DMARC1	Version (required)
p=	Policy for domain (required): none, quarantine, reject
sp=	Policy for subdomains
rua=	Address for aggregate reports
ruf=	Address for forensic reports (rarely used)
pct=	Percentage of messages to apply policy (1-100)
adkim=	DKIM alignment: r (relaxed) or s (strict)
aspf=	SPF alignment: r (relaxed) or s (strict)

Sample DMARC Record

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

Authentication Result Meanings

Field	Values	Meaning
dkim	pass, fail, none	DKIM signature verification result
spf	pass, fail, softfail, neutral, none	SPF check result
disposition	none, quarantine, reject	What receiver did with message

Major Report Senders

Provider	Report Sender Domain
Google	google.com
Microsoft	microsoft.com
Yahoo	yahoo.com
Apple	apple.com
Comcast	comcast.net

---

Reading DMARC reports manually works, but it doesn’t scale. Verkh processes your reports automatically, identifies known providers, highlights problems, and shows you exactly what to fix. One domain is free.

Start monitoring your DMARC reports with Verkh