Deliverability

How to read a DMARC report

Read a DMARC aggregate report by identifying each sending source, checking its message count, and comparing aligned SPF and DKIM results with the receiver's disposition.

Before tightening your DMARC policy, account for the systems that send legitimate mail using your domain. Reports can reveal a sender that needs authentication changes before enforcement would block its mail.

Which report should you use?

Use aggregate reports to compare sending sources and authentication results over a reporting period. Your DMARC record's rua address requests these XML summaries from participating receivers.

The ruf address requests individual failure reports, sometimes called forensic reports. They use an authentication failure reporting format and can contain headers or message content. Receivers may redact or omit them because that content can expose personal information. RFC 7489's reporting rules describe the two report types.

Aggregate reports cover the traffic each reporting receiver observed. A missing report is not proof that no messages used your domain. The DMARC record explanation covers where to set the reporting addresses.

What does an aggregate report contain?

An aggregate report identifies the reporting organization, reporting period and published policy, followed by records grouping messages with shared characteristics. A source IP can appear in several records when their authentication results or other grouping fields differ.

This illustrative excerpt retains the fields needed to compare a source with its authentication results:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
  <domain>example.com</domain>
  <p>none</p>
</policy_published>
<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</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></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

This record represents 42 messages from 203.0.113.10 using example.com in the visible From address. Both authentication methods passed and aligned. The receiver applied no DMARC enforcement to those messages; this does not establish their inbox placement.

Which fields identify an authentication problem?

Compare policy_evaluated with auth_results to distinguish an authentication failure from a domain-alignment failure.

FieldWhat to check
source_ipIdentify the sending server and the service responsible for it.
countCount the messages represented by this record, not the whole report.
header_fromConfirm the domain shown to the recipient.
dispositionCheck whether the receiver applied none, quarantine or reject.
dkim and spf in policy_evaluatedCheck whether each method passed and aligned for DMARC.
auth_resultsCompare the raw authentication results and the domains they authenticated.

For example, SPF can pass under auth_results but fail under policy_evaluated when its authenticated domain does not align with the From domain. An aligned DKIM pass can still make that message pass DMARC. How DMARC works explains that relationship.

What should you do with each sending source?

Match each source to a service you authorize before changing policy. Authentication results alone do not tell you whether your organization intended that service to send.

  1. For a known sender that passes and aligns, confirm its reported volume matches the traffic you expect.
  2. For a known sender that fails, correct its authentication or alignment and check later reports for the result.
  3. For an unknown sender that passes, identify who configured it and whether it should retain authorization.
  4. For an unknown sender that fails, investigate whether it is a misconfigured legitimate service or unauthorized use of your domain.

Resolve legitimate failures before moving from monitoring to quarantine or rejection, because those messages would otherwise be candidates for enforcement. Fixing DMARC failures covers common causes.

How do you inspect reports for a Bird sending domain?

You can route aggregate reports to your own mailbox through the rua address in your DMARC record. Use the DMARC report analyzer to inspect the XML, or open a report in a text editor.

Bird's DNS verification checks your published policy; receiver reports describe authentication results for messages. These are separate checks. The authentication guide covers the policy and DNS records to publish.

Put it into practice.

Continue with the documentation, guides and examples for this topic. Resources are in English.

Get an implementation brief

Build on the same network.

A test API key is yours immediately. Production unlocks when you add a payment method and verify a sender.

Your next idea.
Ready to connect.