alesian.security

Resources  / DMARC and mail

What is a DMARC aggregate report?

A DMARC aggregate report is a summary that a mail provider sends to a domain's owner. It counts the mail the provider received that day with the domain in the From address, groups it by the server that sent it, and says whether each group passed DMARC. It is an XML file, usually compressed and attached to an email. Providers send one a day for each domain that asks.

Why did I get a DMARC report from Microsoft?

Because your domain asked for it. Your DMARC record, the text record at _dmarc.yourdomain.com, has an rua= tag with your address in it. Every provider that supports DMARC reads that tag and sends its reports there. Microsoft's come from dmarcreport@microsoft.com, with a subject that starts "Report Domain:" and names the submitter, such as protection.outlook.com. Google, Yahoo, Comcast and others send their own, each with an attachment that ends in .xml.gz or .zip.

The report is not spam and it is not an alert. A report says mail was received with your domain on it, which is true every day you send mail. A report from a provider you do not use only means people at that provider got mail from you, or mail that claimed to be from you. One check before you open the attachment: the sender's domain should be the provider's own. Fake reports with harmful attachments exist.

What is in one

A shortened report, as Microsoft might send it for a day of newsletter mail:

<feedback>
  <report_metadata>
    <org_name>Enterprise Outlook</org_name>
    <email>dmarcreport@microsoft.com</email>
    <report_id>a1b2c3d4e5f6</report_id>
    <date_range><begin>1760486400</begin><end>1760572800</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>quarantine</p><sp>quarantine</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.24</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_to>contoso.com</envelope_to>
      <envelope_from>bounce.mail.example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>k1</selector><result>pass</result></dkim>
      <spf><domain>mcsv.net</domain><scope>mfrom</scope><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>
report_metadata
Who sent the report and which day it covers. The times are Unix seconds, usually one day.
policy_published
Your DMARC record as the receiver read it that day.
source_ip
The server that sent the mail. Put a name to it and you know which service sent it.
count
How many messages that server sent with your domain in the From address.
policy_evaluated
The DMARC answer: did DKIM and SPF pass and align, and what did the receiver do (none, quarantine, reject).
header_from
The domain a person sees in the From address. DMARC protects this one.
auth_results
The raw SPF and DKIM results, with the domain each one proved. When that domain is not yours, the check passed but did not align.

How to read it

DMARC passes when SPF or DKIM passes and the domain that check proved matches the domain in the From address. In the example, 412 messages came from one server. DKIM passed for example.com, which is the From domain, so DMARC passed. SPF also passed, but for mcsv.net, Mailchimp's return path, so on its own it would not have counted. That is the most common shape of a report row for a marketing service: DKIM carries it, and SPF passes for somebody else.

For each row, ask three questions:

  1. Who is the source address? The reverse DNS name and the network usually name the service.
  2. Is it one of ours? A service you use is a sender to fix. A service you do not use is somebody sending as you.
  3. Did it pass, and on which check? A sender that passes only on SPF breaks when mail is forwarded. One that passes on DKIM survives forwarding.

From the applications you use to DMARC pass or fail goes through what to change when a sender of yours fails.

Too many reports

A domain that sends a lot of mail gets dozens of reports a day, and a mailbox is a poor place to read XML. There are three choices, and removing DMARC is not one of them: the record is what tells receivers to refuse forged mail.

Check what your domain asks for

The DMARC checker reads your record and says where your reports go, what the policy is, and which of the senders in your SPF record can pass.

Read next

From the applications you use to DMARC pass or fail → Every tool that sends mail as you is a sender behind an application. Why each one passes or fails DMARC, and what to change so it passes before you move to reject.