A client publishes a DMARC record because an audit or a vendor asked for one, and a few days later a compressed XML file starts showing up in whatever inbox the rua tag points to. Nobody on the team can read it, so it sits there, and the domain's authentication problems stay invisible until a real phishing attempt using that domain gets reported by a recipient instead. That gap between "we published a DMARC record" and "we know what our mail is actually doing" is a common blind spot for a reseller managing several client domains, and it has nothing to do with which platform hosts the mailboxes: the report format is set by an internet standard, not by Atriomail or anyone else.

This walks through what's actually inside that XML file, field by field, so a report stops being noise and starts being a list of exactly which senders are passing, which are failing, and which need a decision from you. The last section covers how the DMARC record is generated, and what Atriomail does and doesn't do with the reports that come back, when a domain is hosted here.

Table of Contents

Key Takeaways

Point Details
A DMARC report is XML, not a summary The current standard, RFC 9990 (published May 2026, obsoleting the older RFC 7489), defines a machine-readable <feedback> document meant for software to parse, not for a person to read as-is.
Every record has two different "pass or fail" answers auth_results shows the raw SPF or DKIM check; policy_evaluated shows whether that check also aligned with the domain in the message's visible From address. A row can pass one and fail the other.
One unfamiliar source_ip isn't automatically an attack It's just as often a forwarding service, a legitimate vendor nobody documented, or a subdomain's own mail flow. The identifiers and auth_results fields tell you which.
Atriomail generates the DMARC record; reading the reports is still your job The panel puts a ready-to-copy DMARC record in the DNS Setup dialog and can publish it automatically on a connected Cloudflare or Namecheap account, but it doesn't state a policy for you or parse the reports that come back; a normal Atriomail mailbox can receive them like any other IMAP mailbox.

The DMARC record is the easy part; the reports are where the real signal is. Atriomail's DNS Setup dialog puts a ready-to-copy DMARC record in front of every domain, and on a connected Cloudflare or Namecheap account it can publish that record automatically once the domain clears the security check.

Create your account   Read the setup guide

Before You Start

  • The domain's current DMARC record, so you know which mailbox its rua tag points reports to and what policy (p=none, quarantine or reject) it currently publishes.
  • Access to that reports mailbox, or whichever inbox the address in rua actually delivers to. Reports arrive as attachments, usually once a day per reporting organization, so a single day's mail can easily hold more than one file.
  • A way to unzip a .gz or .zip file and open plain text. Any operating system's built-in archive tool and a text or code editor is enough; no special DMARC software is required to do a single manual read-through.
  • A list of every service that sends mail as that domain: the mail host itself, any marketing or invoicing tool, a help desk, and anything forwarding mail on the domain's behalf. You'll need this list to tell a legitimate unlisted sender apart from something that shouldn't be sending as this domain at all.

What You Actually Received

What lands in the reports mailbox is an email with an attached file, not a dashboard. The current aggregate-reporting standard, RFC 9990 (rfc-editor.org, checked September 2026, obsoleting the earlier RFC 7489 as part of the "DMARCbis" revision published in May 2026), requires that attachment to be an XML document, and states it "MUST be subjected to GZIP compression" for mail delivery, so most reports arrive as a single .xml.gz file rather than plain XML or the older .zip format some receivers used previously.

The filename itself carries information worth reading before you open the file. RFC 9990 specifies the exact format: receiver!policy-domain!begin-timestamp!end-timestamp.xml.gz, for example google.com!clientdomain.com!1758844800!1758931200.xml.gz. The two numbers are Unix timestamps marking the reporting window, almost always a 24-hour period, and the first segment identifies who's sending the report, a first clue about which mailbox provider's users are seeing this domain's mail.

Unzip it and you'll find one XML document with a single root element, <feedback>, containing exactly three kinds of section: one report_metadata block, one policy_published block, and one or more record blocks, one per unique combination of sending source and result, the same per-source detail worth tracking alongside the rest of a domain's DNS setup and branding once a client book grows past a handful of domains.

Reading report_metadata and policy_published

These two sections don't tell you anything about your mail's authentication; they tell you who's reporting and what they believe your policy says, which matters because either one can be wrong or stale.

  • report_metadata > org_name names the reporting mailbox provider (Google, Microsoft and similar large receivers are the most common senders of these reports).
  • report_metadata > report_id is a unique identifier for this specific file, useful mainly for deduplicating if the same report is somehow delivered twice.
  • report_metadata > date_range > begin and end repeat the same Unix-timestamp window as the filename, in the body of the file itself.
  • policy_published > domain, p, sp, adkim and aspf restate the DMARC record as the reporting receiver actually saw and applied it at the time: the domain, the policy (none, quarantine or reject), the subdomain policy if set, and the DKIM and SPF alignment modes (r for relaxed, s for strict).

The reason this section is worth checking even once you know the record by heart: if a domain's real DNS record was changed recently, a receiver's cached copy of the old record can still show up here for a day or two, and a policy_published block that doesn't match what's actually published is itself a useful signal that a change hasn't fully propagated yet, something worth cross-checking the same way you'd confirm any other DNS automation change actually took.

A stale policy_published block usually means propagation, not a mistake. Comparing what a report says a domain's DMARC record was against what's actually published today is the same habit worth building into checking any DNS change on a client's domain.

See pricing   Read the DNS troubleshooting guide

Reading a Record: The Part Everyone Misreads

Each record block covers one sending source and breaks into three parts; the last two are where most people misread a report.

  • row holds the source_ip that sent the mail, the count of messages matching this exact combination during the window, and a nested policy_evaluated block.
  • identifiers holds header_from, the domain shown in the message's visible From address (the one a recipient sees), and separately envelope_from, the domain used in the SMTP transaction itself. These are often the same domain, but not always, and DMARC alignment is checked against header_from.
  • auth_results holds the raw outcome of each authentication check actually performed: a dkim block with the signing domain and whether that signature verified, and an spf block with the domain checked and whether SPF passed.

Here's the part worth reading twice: policy_evaluated, inside row, is not the same thing as auth_results. auth_results answers "did this specific SPF or DKIM check pass on its own terms." policy_evaluated answers a stricter question: "did a passing check also belong to a domain that aligns with header_from." A DKIM signature can verify perfectly, in auth_results, for d=sendingtool.com, while policy_evaluated still reports dkim=fail, because that signing domain doesn't align with the domain in the visible From address. That gap is how a legitimate third-party sending tool can pass its own authentication check while still failing DMARC for the domain your client cares about.

Field Answers Example
auth_results > dkim > result Did this DKIM signature verify at all? pass, signed by d=sendingtool.com
row > policy_evaluated > dkim Did a passing signature also align with header_from? fail, because sendingtool.com isn't clientdomain.com
row > policy_evaluated > disposition What did the receiver actually do with the mail? none, quarantine or reject, per the published policy

A message can still pass DMARC overall with only one of SPF or DKIM aligned; it doesn't need both. So the question for each record isn't "did everything pass," it's "did at least one of SPF or DKIM align with header_from," which is exactly what policy_evaluated already tells you once you know what it means.

Turning Records Into a Decision

Once you can read a record, the actual work is sorting each source_ip into one of three buckets:

  • Aligned and expected. policy_evaluated shows a pass, and the source_ip or signing domain matches a sender on your list from before you start. Nothing to do.
  • Failing, but a real sender you forgot to document. The volume is small and steady, and the source resolves to a known vendor (a help desk, an invoicing tool, a forwarding service) that just hasn't been set up to align. This is a configuration task: add it to SPF, get it DKIM-signed under the domain, or accept it will keep failing once the policy tightens.
  • Failing, unexplained, and not on anyone's list. An unfamiliar source_ip, sending volume that doesn't match any known campaign, with both SPF and DKIM failing alignment, is worth treating as a possible spoofing attempt, exactly what DMARC reporting exists to surface before a customer reports a phishing email that appears to come from a client's own domain.

This sorting is also where a domain's SPF record matters directly: a sender that should be aligned but keeps failing SPF is worth checking against the domain's total DNS lookup budget, since a record that's already past the 10-lookup ceiling returns a permerror for every sender on the domain, not just the one you're currently investigating. It's also worth folding into the same email security review a reseller already runs across a client book, alongside an autodiscover record still pointing at an old host or DNS validation that was never rechecked after onboarding.

How to Verify It Worked

A DMARC fix doesn't confirm itself on publish; the proof is in the next report:

  • Wait for the next reporting window to close, generally the next full day, then open the new report from that reporting organization and check the record for the source you fixed. policy_evaluated should now show a pass for at least one of SPF or DKIM.
  • Confirm the DMARC record itself is well-formed using Atriomail's free DNS checker at /dns-checker/, which reads a domain's public MX, SPF, DKIM and DMARC records and flags anything malformed. It doesn't read aggregate reports, only the record itself, so use it to rule out a syntax problem first.
  • Watch the count, not just the pass or fail. If the fixed sender's count in the new report roughly matches its usual volume and now aligns, the fix held. A count that drops to zero can mean the sender stopped sending, not that it started passing.

Common Mistakes and How to Avoid Them

  • Reading only auth_results and assuming that's DMARC's verdict. Symptom: a domain's disposition keeps showing quarantine or reject in report after report even though every auth_results block looks like it passes, because the passing checks never aligned with header_from in policy_evaluated.
  • Treating one report as the whole picture. Symptom: acting on a single day's file that happens to be light on a particular sender's traffic, then being surprised when the next day's report shows a pattern the first one didn't have room to show.
  • Confusing envelope_from with header_from. Symptom: a record looks like a spoofing attempt because the bounce address doesn't match the domain, when DMARC alignment was never checked against envelope_from in the first place, only against the visible From address.
  • Ignoring low-volume records because the count is small. Symptom: a genuine spoofing attempt gets dismissed as noise because it's only a handful of messages, when a low, steady count from an unfamiliar source across several reports is a more consistent phishing pattern than a single large burst, exactly the pattern a reseller's email security checklist should already be watching for.
  • Opening the report as plain text without decompressing it first. Symptom: the file appears to be binary garbage, because a .gz-compressed XML file isn't readable until it's unzipped, not because the report itself is corrupted.
  • Trying to fix alignment by editing the qualifier at the end of SPF (~all vs -all). Symptom: no change in the next report's alignment results, because that qualifier only affects what happens after SPF fails, not whether a given sender aligns in the first place.

Doing This on Atriomail

For every domain added to Atriomail, the panel generates the SPF, DKIM and DMARC records that domain needs, ready to copy from the DNS Setup dialog, and on a connected Cloudflare or Namecheap account it can publish them into the zone automatically once the domain clears the security check; on any other DNS host, they're added from that same dialog by hand. If the zone already has an SPF or DMARC record, Atriomail leaves it in place rather than adding a second one, which matters here specifically, since a domain may only have one DMARC record and a second one breaks evaluation the same way a duplicate SPF record does.

What the panel doesn't do is choose a DMARC policy or a report address for you, and it doesn't read or summarize the reports that come back once you set one. That stays the manual process covered above, on Atriomail or anywhere else. Where Atriomail does help: point a domain's rua tag at an address on that same domain, and a standard Atriomail mailbox, working over ordinary IMAP, receives those reports the same way it receives any other mail. It doesn't parse the XML for you; it's simply a real mailbox that gets the attachment this post has been about reading. Pricing doesn't change based on whether a mailbox is used for client mail or for collecting DMARC reports: it's still $1.39 per mailbox with 15 GB included either way, on a 200-mailbox client book billed at $5/mailbox that's $722/month above wholesale before card fees, support time and any white-label fee. Create your account, add the domain, and copy the DMARC record from the DNS Setup dialog once you've decided what policy and report address it should carry.

The record is generated for you; the report still needs a human to read it. Point a domain's DMARC report address at a mailbox on Atriomail and it arrives like any other mail, ready for the read-through covered in this post.

Create your account   Talk to the team

Frequently Asked Questions

Do I need special software to read a DMARC report?

Not for a single manual read-through: an archive tool to decompress the .gz file and a text editor to read the XML is enough. Dedicated parsing tools exist and become worth it once you're reading reports for many domains regularly, but they're not required to understand what one file is telling you.

Why did I get more than one report for the same day?

Each report comes from one reporting organization covering its own window, so a domain with mail passing through Gmail, Microsoft and other large receivers will get a separate file from each of them, typically once a day per receiver, not one combined file.

Does a failing record always mean someone is spoofing the domain?

No. It's at least as often a legitimate sender, like a help desk or invoicing tool, that was never configured to align with the domain's SPF or DKIM. Check the source against your own list of senders before assuming it's an attack.

Does Atriomail generate a DMARC record with a specific policy?

The panel generates a DMARC record ready to copy from the DNS Setup dialog, and can publish it automatically on a connected Cloudflare or Namecheap account, but it doesn't set the policy (p=none, quarantine or reject) for you; that decision, and the report address the record points to, is yours to make.

Can Atriomail receive and summarize my DMARC reports for me?

A standard Atriomail mailbox can receive the reports like any other mail if you point a domain's rua tag at an address on it, since it works over ordinary IMAP. Atriomail doesn't parse or summarize the XML itself; reading the report is the process covered in this post.

What's the difference between rua and ruf?

rua requests the aggregate reports this post covers, sent roughly daily and summarizing authentication results across many messages. ruf requests failure reports for individual failing messages; far fewer receivers send these in practice, and they're a separate topic from the aggregate reports this post is about.

Latest from the blog