DMARC Reporting (RUA/RUF) — Setting Up Aggregate Reports

Published April 2026 · 15 min read

Setting up DMARC with p=none is only the first step. Without collecting and analyzing DMARC reports, you're flying blind — you won't know which senders are authenticating properly, which are failing, or whether anyone is spoofing your domain. This guide covers everything you need to know about DMARC reporting: configuring RUA (aggregate) and RUF (forensic) report destinations, parsing XML report data, and using reports to tighten your email authentication.

Understanding DMARC Report Types

DMARC defines two types of reports that receivers send back to domain owners:

RUA — Aggregate Reports

Aggregate reports (RUA, "Reporting URI for Aggregate data") are XML documents sent daily by receiving mail servers. They contain summarized authentication data — how many messages were sent, how many passed or failed SPF and DKIM, and what DMARC policy was applied. RUA reports answer the question: "Overall, how is my domain's email authentication performing?"

RUF — Forensic Reports

Forensic reports (RUF, "Reporting URI for Forensic data") are individual message samples sent when a DMARC failure occurs. They include the actual message headers and sometimes a redacted version of the message body. RUF reports answer the question: "What specific message failed, and why?"

Key Difference: RUA reports are summaries (how many messages, what percentage passed). RUF reports are samples (the actual failed message). Most organizations start with RUA only — forensic reports are more granular but contain potentially sensitive data.

Configuring RUA in Your DMARC Record

The rua tag in your DMARC TXT record tells receivers where to send aggregate reports.

Basic RUA Configuration

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

This is the simplest configuration. All aggregate reports for yourdomain.com will be sent to dmarc-reports@yourdomain.com.

Multiple Report Destinations

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com,mailto:reports@partner.com"

Separate multiple addresses with commas. This is common when using a third-party DMARC analysis service alongside internal collection.

HTTPS Report Destination

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=https://dmarc.yourdomain.com/reports/aggregate"

Some DMARC processors can accept reports via HTTPS POST. The report data is sent as a gzipped XML attachment in a POST request body.

Configuring RUF in Your DMARC Record

The ruf tag specifies where forensic (failure) reports are sent.

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com"
Privacy Consideration: Forensic reports contain actual message content, which may include sensitive or personal data. Before enabling RUF, consider:
  • Who will have access to the forensic report mailbox?
  • Do you need to comply with data protection regulations (GDPR, CCPA)?
  • Will the volume of forensic reports be manageable?
Many organizations skip RUF entirely or use it only during initial DMARC deployment.

The RUA Authorization Requirement

When a receiver sends DMARC reports to an address at a different domain, it must verify that the destination domain authorizes receiving those reports. This prevents abuse where someone specifies an arbitrary email address as their report destination.

How Authorization Works

If your DMARC record specifies rua=mailto:reports@otherdomain.com, the sending server checks for a TXT record at yourdomain.com._report._dmarc.otherdomain.com:

yourdomain.com._report._dmarc.otherdomain.com. IN TXT "v=DMARC1"

This TXT record at the destination domain explicitly authorizes receiving DMARC reports for yourdomain.com.

Self-Hosted Reports (Same Domain)

If your RUA address is at the same domain as your DMARC record (e.g., rua=mailto:dmarc@example.com on the example.com DMARC record), no external authorization is needed — you're implicitly authorized to receive your own reports.

Third-Party Service Authorization

If you use a DMARC analysis service like our platform at korpo.pro, the service will provide the authorization record for you. Add it to your DNS and you're set.

DMARC Aggregate Report Format

Aggregate reports are XML documents, typically gzip-compressed and sent as email attachments with MIME type application/gzip. The filename follows the convention sender.com!receiver.com!timestamp.gz.

Report Structure

Here's what a typical aggregate report XML looks like:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1745452800</begin>
      <end>1745539199</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.50</source_ip>
      <count>1542</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>selector1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Understanding Report Fields

Step-by-Step DMARC Reporting Setup

Step 1: Set Up a Dedicated Mailbox

Create a dedicated mailbox to receive DMARC reports. Don't use a personal or team inbox — DMARC reports are voluminous, machine-generated, and not human-readable in raw form. Use an address like dmarc-reports@yourdomain.com.

With Gmail or Google Workspace, create a dedicated user account. With Microsoft 365, create a shared mailbox. You can also set up forwarding rules to send reports to a processing service.

Step 2: Configure Your DMARC Record with RUA

Add the rua tag to your DMARC record:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Keep p=none at this stage — you're collecting data before enforcing anything.

Step 3: If Using a Third-Party Service, Add Authorization

If you're sending reports to a third-party analysis service, you need two DNS records:

Your DMARC record:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com,mailto:rua@dmarc.service.com"

The service's authorization record:

yourdomain.com._report._dmarc.dmarc.service.com. IN TXT "v=DMARC1"

The service will provide the exact record to add.

Step 4: Configure Report Processing

Raw DMARC reports are XML files compressed with gzip. To make them useful, you need to parse and visualize the data. Options include:

Step 5: Analyze Reports Before Changing Policy

Wait at least 2-4 weeks after setting up reporting before considering a policy change from p=none. Use this time to:

Step 6: Progressively Tighten Your Policy

Once reports show 100% authentication pass rate:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

The pct=25 tag applies the quarantine policy to only 25% of failing messages. Increase gradually: 25 → 50 → 75 → 100. Then switch to p=reject:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

What to Look For in DMARC Reports

Pass Rate by Source IP

The most important metric: what percentage of messages from each source IP pass DMARC? If you see failures from IPs you don't recognize, that's unauthorized sending (or spoofing) that you need to address.

Alignment Failures

Reports show whether SPF and DKIM pass independently, and whether they align with the From domain. Common alignment issues:

Unknown Source IPs

IPs appearing in your reports that you don't recognize could indicate:

Volume Trends

Track message volumes per source over time. Sudden spikes may indicate a compromised account being used to send spam. Sudden drops may indicate that a legitimate sender's authentication is broken.

Setting Up Forensic (RUF) Reports

Adding RUF to Your DMARC Record

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com"

What Forensic Reports Contain

Each forensic report includes:

This level of detail makes forensic reports excellent for debugging specific authentication failures, but it also means they may contain sensitive information.

Limiting Forensic Reports

The fo tag controls when forensic reports are generated:

You can combine values: fo=1:d:s generates reports on all failures.

RUF Volume Considerations

Forensic reports can be voluminous. If your domain receives significant spoofing traffic, you could get thousands of individual forensic reports per day. Most organizations start with fo=0 and a short monitoring period before deciding whether ongoing forensic collection is worthwhile.

Important: Forensic reports are sent on a best-effort basis. Not all receivers support RUF, and major providers like Gmail do not send forensic reports at all. Don't rely on RUF as your only monitoring mechanism.

Common DMARC Reporting Problems

Not Receiving Any Reports

If you're not receiving aggregate reports after more than 48 hours:

  1. Verify DNS propagation — Check that your DMARC record is published at _dmarc.yourdomain.com using dig TXT _dmarc.yourdomain.com.
  2. Verify RUA address — The report destination must be a working mailbox that can receive external email.
  3. Check authorization records — If sending reports to a third-party domain, ensure the external authorization TXT record is in place.
  4. Check DMARC record syntax — The v=DMARC1 tag must come first and be uppercase. Use our free checker to validate.

Reports Only From Some Providers

Not all email providers send DMARC reports. Major providers that do include Google (Gmail), Microsoft (Outlook/Hotmail), Yahoo, and many European providers. Some smaller providers don't send reports. This is normal — DMARC reporting is voluntary, and you'll get reports from the providers that matter most.

Reports Show Unexpected Failures

If legitimate mail is failing DMARC:

  1. Check email headers of a failed message to see the specific authentication results.
  2. Verify that all sending infrastructure is included in your SPF record.
  3. Ensure DKIM is configured for all sending services (including third-party ESPs).
  4. Check alignment — the From domain must match the SPF envelope sender and/or DKIM signing domain.

RUA Reports Are Too Large

High-volume domains can receive very large compressed report attachments. This is normal. If mailbox quotas are an issue, consider:

DMARC Report Analysis Workflow

Here's a recommended workflow for processing DMARC reports:

  1. Collect — Set up RUA (and optionally RUF) in your DMARC record.
  2. Parse — Process raw XML/gzip reports into a structured database.
  3. Categorize — Group report records by source IP and authentication result.
  4. Identify authorized senders — Match source IPs against your known sending infrastructure.
  5. Flag unauthorized senders — Investigate unknown IPs that are sending email as your domain.
  6. Fix alignment — Address SPF and DKIM alignment issues for legitimate senders.
  7. Tighten policy — Once all legitimate senders pass, move from p=none to p=quarantine to p=reject.
  8. Monitor continuously — Even at p=reject, keep monitoring reports. New senders, infrastructure changes, and new spoofing attempts require ongoing attention.

Advanced DMARC Reporting Options

Subdomain Reports

By default, DMARC policies for apex domains also cover subdomains. But you can separate reporting:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"
_dmarc.sub.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:subdomain-reports@yourdomain.com"

This lets you monitor subdomain authentication separately from your main domain.

Percentage Tags for Gradual Rollout

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; pct=50; rua=mailto:dmarc-reports@yourdomain.com"

The pct tag tells receivers to apply the policy to only a percentage of failing messages. This is useful for gradually enforcing DMARC without cutting off all failing senders at once. However, the pct tag only affects the disposition of failing messages — RUA reports still cover all messages regardless of the pct value.

Report Interval

The ri tag specifies the report interval in seconds (default is 86400, or 24 hours). Some receivers may honor this:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ri=3600"

Note: Most major providers send reports once daily regardless of the ri value. Setting ri=3600 (hourly) may or may not be honored.

DMARC Reporting and Other Security Standards

DMARC reporting works best as part of a comprehensive email security stack:

Verify Your DMARC Reporting Setup

Check your DMARC record including RUA configuration with our free scanner:

Check DMARC Reports Now →

You can also compare your domain against best-in-class examples. Disroot.org scores 100/100 — see how your domain measures up.

Related guides: DMARC Setup Guide · SPF Records · DKIM Setup · TLS-RPT Setup · Email Header Analysis