How to read DMARC reports for a cold email domain

A DMARC report is a daily summary that inbox providers send back to your sending domain, listing every source that sent mail claiming to be from it and whether that mail passed authentication. For a cold email domain it is the only feedback loop that shows who else is sending as you, and whether your own mail is passing cleanly.

This page walks through the fields in a DMARC aggregate report, plus a worked example that is labeled invented, and what to do with what you see. It follows on from our page on SPF, DKIM and DMARC for cold email, which covers the records themselves. That page recommends starting a new sending domain on p=none with a rua address set.

What is a DMARC report for a cold email domain?

A DMARC report is an XML file that a mailbox provider generates and emails to the address in your domain's rua tag, once a day, summarizing every message it received claiming to be from your domain. It is sometimes called an aggregate report or a rua report, after the tag that requests it.

The report does not contain message content. It groups mail by sending IP address and shows, for each one, how many messages arrived, whether SPF and DKIM passed, and what the receiver did with the mail.

That is enough to spot problems without reading a single email.

Who sends DMARC reports for a cold email domain?

Any mail provider that receives mail claiming to be from your domain and supports DMARC sends a report, as long as your DMARC record includes a working rua address. Google, Microsoft and Yahoo are the most common senders, because most cold email lands at Gmail, Outlook.com or Yahoo addresses.

Reports usually cover a 24 hour window and arrive once a day per provider. A domain with reasonable reach will see several reports land every morning, one from each large provider that saw mail from it that day. A domain with low mail volume may go a day or two without a report from a smaller provider.

What fields matter in a DMARC aggregate report for cold email?

The fields that matter are the source IP, the message count, the disposition, and the SPF and DKIM results with their alignment. Google's own walkthrough of a DMARC report defines these in plain language, and RFC 9990, the current DMARC aggregate reporting standard that replaced the original RFC 7489 in 2026, defines the XML tags formally inside the <record> block.

Alignment is the comparison between header_from and the domain in auth_results. DMARC only passes a record when SPF or DKIM passes and the aligned domain matches the "From" domain, the same rule covered on the parent SPF, DKIM and DMARC page.

What does a DMARC aggregate report look like for a cold email domain?

A DMARC aggregate report is one XML file with a metadata block, your published policy as the receiver saw it, and one <record> per sending source. The example below is invented, using a fictional domain and placeholder IPs, to show the shape without any real data.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <date_range><begin>1738368000</begin><end>1738454400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>examplecold.com</domain>
    <p>none</p>
    <pct>100</pct>
  </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>examplecold.com</header_from></identifiers>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.77</source_ip>
      <count>3</count>
      <policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
    </row>
    <identifiers><header_from>examplecold.com</header_from></identifiers>
  </record>
</feedback>

In this invented example, the first record is 42 messages from one of the domain's own sending IPs, all passing. The second is 3 messages from an unrecognized IP, both checks failing. On a p=none policy, both sets of mail still get delivered; the report is only telling you what happened.

What does a good DMARC report look like for a cold email domain?

A good report for a cold email domain shows one or two source IPs: the ones your sending tool actually uses. Every record passes SPF and DKIM, and the disposition stays at none because nothing is failing in the first place. There should be no surprise sources sending real volume.

A small number of records with a handful of messages each, all passing, day after day, is the sign of a clean domain. New cold email domains often look sparse at first because volume is still low and warm-up schedules are deliberately slow.

What should you do about unknown sources in a cold email DMARC report?

Treat an unknown source as worth checking before you treat it as a problem. Look up the IP address, and check whether it belongs to a known provider you forgot to authorize, a forwarding service, or something unrelated to your setup.

1. Note the source IP and the count. A single-digit count from an unfamiliar IP is usually noise.
2. Check whether that IP is one of your own sending servers, or belongs to a step in your cold email domain setup that was never added to SPF.
3. If it is a legitimate sender you missed, add it to your SPF record. The SPF rules are covered on the parent authentication page.
4. If it is genuinely unrelated to your domain and the count stays low, keep monitoring; on p=none it is not being delivered because of you, so there is nothing urgent to fix.
5. If the same unfamiliar source sends a large and growing count, that is the pattern worth watching before tightening policy.

When should a cold email domain move from p=none to quarantine?

A cold email domain should move from p=none to p=quarantine once several consecutive reports show every record passing and no unexplained sources sending meaningful volume. That is the same guidance given on the parent page for choosing a DMARC policy, and reading the reports is how you confirm it.

Rushing the move before reports are clean risks quarantining your own mail if an IP was missed from SPF, which is one of the fastest ways cold emails go to spam. Reports from only one or two of your own IPs, all passing, for a stretch of time, is the signal to move. There is little reason for a sending domain used only for cold email to go further to p=reject.

What are free ways to read a cold email DMARC report's XML?

Free ways to read a DMARC report include opening the XML directly, or pasting it into a browser-based converter that turns it into a readable table without asking you to sign up.

Most providers send the file as a .xml or .xml.gz attachment on the daily email.

• Open small files directly in a browser or text editor; the structure in the worked example above is short enough to scan by eye once you know the field names.
• Use a free online tool such as the dmarcian XML to Human converter or MxToolbox's DMARC Report Analyzer, which paste or upload the XML and render it as a table of sources, counts and results.
• For several domains at once, forward all the rua mailboxes to one inbox and work through them in a batch rather than checking one domain at a time.

Pipefire's DMARC record sets rua=mailto:dmarc@<domain> with fo=1 on every sending domain it sets up, and checks that the record is published. That address needs an inbox that actually receives mail before reports arrive anywhere you can read them, and Pipefire does not create one. Setting up that inbox, and reading and acting on what lands in it, is a manual step outside what the platform automates today. Our setup page covers what Pipefire does configure and verify on each domain before it can send.

Reading DMARC reports for cold email FAQ

What is a DMARC rua report for cold email?

A rua report is another name for the aggregate report, named after the rua tag in a DMARC record that tells receivers where to send it. It is the daily summary of sending sources, not a per-message failure report.

How often do DMARC reports arrive for a cold email domain?

Most providers send one report per 24 hour window, so a domain seen by several large providers gets several reports a day, one per provider. A low-volume new domain may not get a report from every provider every single day.

Do I need special software to read a cold email DMARC report?

No. The XML can be read directly in a text editor, or pasted into a free browser-based converter such as dmarcian's XML to Human converter. Paid analyzers add dashboards and history across many reports, which matters more once you run several domains.

Why does my cold email DMARC report show an IP I don't recognize?

It usually means a mail server is sending as your domain that you have not added to SPF, or it is unrelated mail that was never really from you. Check the count: a handful of messages is rarely urgent, a large or growing count is worth investigating.

Does Pipefire read my cold email DMARC reports for me?

No. Pipefire sets the DMARC record with a rua address, and it checks that the record exists on every sending domain. Reading and acting on the aggregate reports that arrive is a manual step for now, not something the platform processes.