SecVaultAuditor
PL
Guide, updated 2026-11-05

DMARC reports: how to read them and what to do

Once you add a rua address to your DMARC record, emails with XML attachments start to arrive. These are aggregate reports from the servers that receive mail from your domain. They show who sends in your name and whether that mail passes DMARC, and they tell you when it is safe to tighten the policy.

Check your domain for free

Aggregate (rua) and failure (ruf) reports

A DMARC record can name two kinds of addresses. The rua tag is the address for aggregate reports: a summary of messages over one period, with no content of individual emails. The ruf tag is the address for failure reports, which describe single messages that failed the check. Failure reports carry more detail about specific messages, so they can contain personal data: sender and recipient addresses and sometimes parts of the message. RFC 9990 notes that this level of detail carries more risk than aggregate data. There is no guarantee that a given receiver will send them at all, and the ones that arrive should be handled like mail containing customer data.

Start with rua only. Add ruf deliberately, when someone will read the reports and the mailbox is protected.

Who sends reports and how often

A report comes from a server that received mail from your domain, for example a large mailbox provider. Each receiver sends its own reports, so the more receivers your mail reaches, the more files you get. According to Google they usually arrive once a day, and large organizations can get hundreds or even thousands of reports daily. The standard defines the reporting period in the date_range field; typically it is one UTC day. The ri tag lets you request a different interval (default 86400 seconds), but the receiver does not have to follow it.

What the file looks like

A report is an email with an attachment. The RFC recommends gzip compression, so the file usually ends in .xml.gz. The name has the form receiver!your-domain!begin!end.xml.gz, where begin and end are seconds since 1 January 1970 (Unix time). The email subject contains the fields "Report Domain:", "Submitter:" and "Report-ID:". Unpack the file and open the XML in a text editor or a browser.

A shortened example with a fictional domain and addresses from the documentation ranges:

<feedback>
  <report_metadata>
    <org_name>mail.receiver.example</org_name>
    <email>[email protected]</email>
    <report_id>1234567890</report_id>
    <date_range><begin>1767225600</begin><end>1767311999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourcompany.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.10</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>yourcompany.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>yourcompany.com</domain><selector>mail2026</selector><result>pass</result></dkim>
      <spf><domain>yourcompany.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.77</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim><spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>yourcompany.com</header_from></identifiers>
    <auth_results>
      <spf><domain>newsletter.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

The most important fields

  • report_metadata: org_name is the receiver that generated the report, and date_range with begin and end is the period the data covers.
  • policy_published: the policy the receiver saw in your DNS at the time. Check that p matches what you published. The alignment modes adkim and aspf are here too (r - relaxed, s - strict).
  • record: one group of messages with identical results. It contains row, identifiers and auth_results.
  • row: source_ip is the address of the server that connected to the receiver, and count is the number of messages in the group.
  • policy_evaluated: the DMARC result. dkim and spf are pass or fail here and mean the check with alignment to the domain in the "From" header. disposition is the action taken by the receiver: none, quarantine or reject. With p=none it will be none even for messages that failed. The optional reason explains exceptions, for example forwarded or mailing_list.
  • identifiers: header_from is the domain in the visible "From" header, the one DMARC protects.
  • auth_results: raw DKIM results (the d= domain, selector, result) and SPF results (domain, result), without the alignment verdict. The difference between auth_results and policy_evaluated is the main diagnostic clue: in the second record of the example SPF "passed" for newsletter.example, but it is not aligned with yourcompany.com, so DMARC records a fail.

How to recognize the source of a message

For every source_ip ask three questions: whose address is it, which domain signed DKIM and which domain passed SPF, and is the DMARC result a pass.

  • Your own server or business mail provider: the address belongs to the provider, auth_results shows your domain and policy_evaluated shows pass. Most of the report should look like this.
  • A forgotten sending service (newsletter, CRM, shop invoices, a booking system, a website form): the address is foreign, but you can tell the service from the domain in auth_results or from the owner of the IP address. Usually DKIM is signed with the provider's domain, SPF passes for the provider's domain and DMARC gives fail, because nothing is aligned with your domain.
  • Forwarding: the message left legitimately, but someone forwarded it, so the address belongs to the forwarding server and SPF does not match. If the DKIM signature survived, DMARC still passes. The receiver may mark such cases in the reason field (forwarded, mailing_list).
  • Spoofing: a foreign address, fail results, no trace of your domain in auth_results and no link to any service you use. Typically small counts from many different addresses, or one large stream from a single address.

You can find the owner of an IP address in a public WHOIS database or through the reverse DNS record (PTR). It is not proof, but it is enough to tell a known provider from a random hosting account.

What to do in each case

  • Your own source with pass: nothing. Just make sure the DKIM signature does not disappear when you change providers.
  • A legitimate service with fail: turn on DKIM signing with your own domain in its panel and add the DNS record the panel shows. If the service sends from your address, add it to SPF as well (DKIM guide, SPF guide). One of the two passing with alignment is enough, but both is best. If the service cannot sign with your own domain, consider replacing it before you tighten the policy.
  • Forwarding: usually needs no change on your side. Messages that passed through DKIM are safe under a stricter policy. Forwarded messages without a signature may be rejected then.
  • Spoofing: do not turn the reports off. Bring the legitimate sources to pass and raise the policy, because reject is what blocks such mail. Details: spoofing of your domain.
  • An unknown address, but the messages look genuine: ask your team who recently connected a new service. Until you know, do not assume it is an attack.

When to raise the policy from none

There is one criterion: all legitimate sources pass DKIM or SPF with alignment to the domain in the "From" header, and you see it in reports from several consecutive periods that also cover rare mailings, such as monthly invoices or a seasonal newsletter. There is no fixed number of days, because it depends on how rarely your systems send. If the only fails left in the report come from spoofing and from forwarded mail without a signature, you can go on.

  1. Move from p=none to p=quarantine. Failing messages will go to spam. Watch the reports and any complaints about missing mail.
  2. When nothing legitimate fails after the change, move to p=reject.
  3. Remember subdomains: the sp policy covers them separately, and each subdomain that sends mail has its own rows in the reports.

A full description of the tags and a safe rollout: DMARC guide. You can prepare the record in the DMARC generator.

Reports to an address in another domain

When the host in rua belongs to a different organizational domain than the domain with the DMARC record (for example reports for yourcompany.com go to an address at reports-company.example), the report receiver must confirm it in its own DNS. Without that confirmation the sender of reports ignores the address. The record name in the receiver's DNS is <your-domain>._report._dmarc.<receiver-domain>, type TXT, value v=DMARC1:

yourcompany.com._report._dmarc.reports-company.example. TXT "v=DMARC1"

The owner of the receiver's domain adds this record, not you. The receiver can also publish a wildcard record *._report._dmarc.<receiver-domain>, which authorizes reports for any domain. Report analysis services usually do this themselves. A missing record is a common reason why nothing arrives after you set rua.

A dedicated mailbox and tools for reading

  • Create a separate address or group for reports, not a manager's mailbox. The volume grows with your mail traffic and quickly floods an ordinary inbox. Google also recommends a dedicated mailbox or group.
  • Set a rule that moves reports to a separate folder and limit access to it, because the reports contain the IP addresses of your servers and a list of the services you use.
  • Reading XML by hand is enough for a few reports a day. For more, the files can be loaded into a database or transformed into HTML with an XSL style sheet, as Google describes.
  • A separate category is report analysis services: they receive reports at their own address, merge them and show the sources in a table. Before choosing one, check where it stores the data (reports reveal which services you use) and whether it has a privacy policy.

You can check the DMARC, SPF and DKIM state of your domain in the free SecVault Auditor scan, and DMARC alone in the DMARC checker. If mail from your domain lands in spam, see the spam guide.

Sources