Reference

DMARC reports explained: read an aggregate report line by line, RUA vs RUF, and what to do next

A DMARC aggregate report read element by element from Google's example, why failure reports rarely arrive, and the four questions to ask every report.

By Updated Last verified

On this page
  1. Why you receive DMARC reports
  2. One aggregate report, line by line
  3. The four questions to ask every report
  4. RUA vs RUF
  5. Sending reports to another domain
  6. Check what your record publishes
  7. Sources

A DMARC report is an XML file that a receiving mail service sends to the address in your DMARC record's rua= tag. It lists the sources that sent mail using your domain during the reporting period, how many messages each sent, and whether they passed SPF, DKIM and DMARC alignment. Google's guide to DMARC reports (opens in a new tab) sums up what they tell you: which servers or third-party senders send mail for your domain, what share of your messages pass DMARC, which services fail, and what receivers did with the unauthenticated ones. RFC 9989 (opens in a new tab), the DMARC standard, defines two tags for them: rua, the addresses for aggregate feedback reports, and ruf, the addresses for message-specific failure information. The aggregate report is the one you need; RFC 9989 says a participating receiver will send aggregate reports to domain owners that request them, and might also send failure reports, for reasons covered below. This page reads one aggregate report line by line, then turns it into four questions.

Why you receive DMARC reports

Reports arrive because your DMARC record asks for them. Google explains (opens in a new tab) that if reports are turned on with the rua tag, every server that receives mail from your domain sends a report, usually once a day by email; a large organisation can get hundreds or even thousands a day, so Google recommends a dedicated group or mailbox for them. RFC 9990 (opens in a new tab), the aggregate reporting standard, describes the same thing from the receiver's side: daily or more frequent feedback reports that cover messages which passed DMARC as well as those that did not, with a separate report for each DMARC policy domain. The report travels as an email attachment, an XML file that should be gzip-compressed, with a filename built from the receiver, your policy domain, the begin timestamp and the end timestamp, ending in .xml or .xml.gz.

A record that requests aggregate reports looks like this, on example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The DMARC record generator builds one step by step: start by monitoring, then enforce once your reports show your real senders pass.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

One aggregate report, line by line

Google's example report (opens in a new tab) has one record covering two messages. Here it is in full, as Google publishes it; the element names come from RFC 9990 (opens in a new tab).

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>example.com</org_name>
    <email>noreply-dmarc-support@example.com</email>
    <extra_contact_info>example.com/dmarc/support</extra_contact_info>
    <report_id>9391651994964116463</report_id>
    <date_range>
      <begin>1335571200</begin>
      <end>1335657599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>bix-business.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.209</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>bix-business.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>bix-business.com</domain>
        <result>fail</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>bix-business.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

report_metadata says who sent the report and for which period. org_name is the reporting organisation, report_id a unique identifier for the report, and date_range the reporting period in UTC, with begin and end as seconds since the epoch.

policy_published is the DMARC record the receiver found for your domain, with unspecified tags shown at their default values. domain is the DMARC policy domain. In Google's example the policy is p=none, and adkim and aspf are both r, which RFC 9989 (opens in a new tab) defines as relaxed alignment mode.

record holds the results. Inside it, row gives the connecting system and how many messages were received from it for the policy evaluated: source_ip is the connecting IP address and count the number of messages to which the evaluated policy applied. policy_evaluated is the DMARC verdict: disposition is the result of applying the policy, and dkim and spf here are the DMARC identifier alignment results, the evaluated values as they relate to DMARC, not the raw authentication outcomes. A reason element appears when the disposition differs from the published policy, for example after a local override.

identifiers carries header_from, the RFC5322.From domain of the message, which RFC 9989 calls the Author Domain.

auth_results is the raw layer: DKIM and SPF results, uninterpreted with respect to DMARC. For DKIM it records the domain from the signature's d= tag, the selector from s=, and the verification result; for SPF the domain used during validation and its result, and only the MAIL FROM identity is used.

Read the example's two layers together. SPF passed on bix-business.com and that domain matches the From domain, so SPF alignment passed. DKIM verification failed on the same domain, so DKIM alignment shows fail. With p=none published, the disposition is none, the result of applying that policy. That is why the two layers matter: auth_results tells you what failed, policy_evaluated tells you whether DMARC counted it.

The four questions to ask every report

Every record is a source IP with a count and two alignment results. RFC 9989 (opens in a new tab), the DMARC standard, describes what reports reveal: mail streams using your domain that do not pass, which may be a mix of illegitimate use and legitimate mail from your own services that is unaligned or unauthenticated. Four questions sort every row.

  1. Is this source mine, and failing? A service you use whose policy_evaluated shows fail on both DKIM and SPF. RFC 9989 requires these to be fixed before you publish an enforcement policy. The dmarc=fail guide covers the alignment fixes.
  2. Is this source mine, and passing? RFC 9989 defines a DMARC pass as an SPF or DKIM pass whose domain is aligned with the Author Domain, so one aligned identifier is enough. Nothing to do; this is the evidence you need before tightening the policy.
  3. Is this source not mine? An IP you do not recognise. Google's reading guidance (opens in a new tab) is that reports let you review who sends mail for your domain and can alert you to potential spammers; the DemiSignal check puts it the other way round: reports show which services send email as your domain, including ones nobody remembers setting up, so check before assuming abuse.
  4. What disposition did it get? none, quarantine or reject, which is what the receiver did under your published policy. As you understand how receiving servers authenticate your messages, Google suggests considering a move from none to quarantine or reject; the DMARC policy guide covers that order.

RUA vs RUF

In RFC 9989 (opens in a new tab), rua lists the addresses for aggregate feedback reports and ruf the addresses for message-specific failure information; if either tag is absent, receivers must not generate that kind of report for the domain. RFC 9991 (opens in a new tab), the failure reporting standard, describes what a failure report adds: besides the header fields or the entire contents of the failed message, details about transmission and authentication, normally sent almost immediately after the receiver detects a DMARC failure. It also explains why you will rarely get one. Failure reports may contain message content and trace headers, so they can expose personal information and non-public information, and the standard records that many large-scale providers limit or entirely disable them, preferring aggregate reports. Its summary is that aggregate reports remain the recommended mechanism for visibility.

RFC 9989 puts the same asymmetry in the receiver's duties: a participating receiver will send aggregate reports to domain owners that request them, and might also send failure reports. So publish rua, and treat ruf as optional. The RFC 9989 guide covers the split of reporting into RFC 9990 and 9991.

Sending reports to another domain

If the rua address is on a different domain from the one that publishes the DMARC record, the receiving domain has to say it accepts them. RFC 9990 (opens in a new tab) explains the reason: without a check, a bad actor could publish a record pointing reports at a victim address, send a large volume of failing mail, and flood the victim with unwanted reports. The receiver therefore builds a name from your policy domain, the string _report._dmarc and the report destination's host, and queries DNS for a TXT record there. Google gives the concrete form (opens in a new tab): for a record at examplepetstore.com sending reports to an address at myownpersonaldomain.com, add a TXT record at examplepetstore.com._report._dmarc.myownpersonaldomain.com whose value is the version tag alone, v=DMARC1; with no policy after it. The DMARC record generator explains the same requirement: without that record, receivers do not send the reports, and reporting services set it up for you.

Check what your record publishes

The free DemiSignal check reads the public DNS records of the domain you enter, with no account, and for DMARC flags a missing record, a policy of none, no reporting address, a policy that covers only part of your email, and subdomains left at none. A DNS finding shows how your domain is set up; it does not show where a particular message landed, which is what the reports are for.

Sources

Tools for this

Frequently asked questions

How often are DMARC reports sent?

Usually once a day. Google states that every mail server you send email to sends a daily report, and RFC 9990 describes aggregate feedback as daily or more frequent. A large sender can receive hundreds of reports a day.

Why am I not receiving any DMARC reports?

The usual causes: your record has no rua tag, the rua address is on another domain that has not published the authorising _report._dmarc record, or no receiver that sends reports has seen mail from your domain yet. The free DemiSignal check flags a DMARC record with no reporting address.

Is rua required for DMARC to work?

No. RFC 9989 marks rua as optional, and without it receivers do not generate aggregate reports. Reports are how you find out which sources using your domain pass and fail, which RFC 9989 asks you to fix before moving to an enforcement policy, so most domains want them.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account