Email

What the DMARC reports you receive by email are

Reviewed on 5 min read DMARC reports XML deliverability

If your DMARC record contains an rua address, providers such as Google, Microsoft or Yahoo may periodically send messages with subjects like Report Domain and an XML file, usually compressed as ZIP or GZIP.

They are not bounces. Receiving them does not in itself mean there is a problem or that the domain has sent spam: they are aggregate reports about the systems that delivered messages using your domain and about the SPF, DKIM and DMARC results. The IP observed may belong to the original sender, a relay or a forwarder; do not classify it as authorised or malicious without reviewing the route and the alignment.

What the report contains

The XML groups information such as:

  • IP of the system that delivered the messages to the receiver that generated the report.
  • Number of messages observed.
  • SPF and DKIM result.
  • DMARC policy applied.
  • Domain shown in the From header.

The raw SPF or DKIM result is not the same as the DMARC result. Also check whether the authenticated domain is aligned with the domain shown in From: DMARC passes when there is alignment in SPF or in DKIM.

Aggregate reports do not normally include the full body of the messages. Even so, avoid publishing the files, because they contain technical information about your sending sources.

Difference between rua and ruf

  • rua requests aggregate reports and is the usual option for monitoring.
  • ruf requests forensic failure reports. Many providers do not send them and, when they do, they may contain headers, fragments or even the original message. Do not turn them on without deciding who can access them and how long they will be kept.

Stop receiving them or change the recipient

Edit the TXT record for _dmarc.tudominio.com and change the address or remove the whole rua= or ruf= tag. Do not delete the entire DMARC record just to stop the reports, because you would also remove the policy that protects the domain against spoofing.

There must be a single DMARC record. If you want to analyse the XML files without receiving them in a personal mailbox, use a dedicated address or a report-processing service.

If the rua or ruf address belongs to an organisational domain other than the one publishing the policy, the receiving domain must authorise those reports through DNS. For example, for a policy on tudominio.com that sends to dmarc@informes.example, there must be a TXT record with this name:

tudominio.com._report._dmarc.informes.example

Its value is v=DMARC1. Without this authorisation, compliant generators ignore that external destination. The provider receiving the reports should give you the exact record. An address under another subdomain of the same organisational domain does not need this external authorisation.

What to check in the results

Look for unknown IPs with many messages and legitimate sources that fail SPF or DKIM alignment. Before tightening the policy from p=none to quarantine or reject, identify and authenticate every authorised service: hosting, forms, shop, CRM, Microsoft 365, Google Workspace or marketing platforms. Make the change gradually and review the reports; p=reject is not appropriate until you have confirmed it will not block legitimate sources.

The guide Set up the DMARC record explains the policy and its main tags.

Read a case without mixing up the results

If a row shows valid DKIM for a platform domain and the visible sender belongs to your company, check the alignment before taking it as correct. The signature can be valid and still not help your domain pass DMARC. It can also pass DMARC through aligned SPF even if that signature is not aligned.

Match each IP and domain to a known service and to the report period. Unexpected volume deserves a look, but a single unknown IP may be a forwarder. Do not automatically authorise every IP that appears in the XML.

The reports describe what each receiver observed; they are not a complete list of everything you send, nor a measure of inbox placement. Keep comparable periods and note when you changed the policy so you can interpret how things evolve.

You may also find useful

Something wrong or out of date? Tell us and we will review it.