You published a DMARC record months ago and set the policy to none, so nothing actually happens when someone spoofs your domain. Phishing mail sent as you@yourcompany.com still reaches its targets, and you have no way to tell how bad the problem is until a customer forwards you a fake invoice. The DMARC report your mail providers already send you every day has the answer, but it arrives as a zipped XML file almost nobody opens.
A DMARC report is an XML file that a receiving mail server, such as Gmail or Outlook, sends to the address in your DNS record's rua tag, listing every message it saw claiming to be from your domain and whether SPF and DKIM passed. EmailControl is an email deliverability monitoring service that checks your SPF, DKIM, and DMARC records on a schedule and flags authentication failures, but reading raw aggregate reports by hand is still the ground truth for a policy decision like this one.
What Is a DMARC Aggregate Report?
A DMARC aggregate report is a daily summary, not a real-time alert. It groups every message your domain's listed receivers saw in roughly the past 24 hours by source IP, then states whether each source passed SPF, passed DKIM, and passed overall DMARC alignment.
The report is generated because your DNS record includes a rua=mailto: tag. Major mailbox providers — Gmail, Outlook, Yahoo — honor that tag and mail you a gzipped or zipped XML file once every 24 hours per sending domain they saw traffic from. Forensic reports (the ruf tag, sent per failed message) are rarely honored anymore because they can leak message content, so the aggregate report is the practical data source almost everyone works from.
How Do You Read the XML in a DMARC Report?
The file looks intimidating the first time, but it follows the same fixed structure every time. Work through it in this order:
- Unzip the .xml.gz or .zip attachment the report arrived as.
- Open the file and find each <record> block — one per sending source for that reporting window.
- Read the <source_ip> value inside each record to identify who actually sent the mail.
- Check <policy_evaluated><dkim> and <spf> for a pass or fail verdict.
- Cross-reference <auth_results> to see which specific DKIM selector or SPF mechanism matched, or why it did not.
- Total the <count> value on each record — a source failing on 2 messages is a different problem than one failing on 20,000.
A typical small-business domain gets back 5 to 15 distinct <record> blocks per report: its own outbound server, one or two marketing or invoicing platforms, and occasionally an unfamiliar IP worth investigating. Ignore any record where both SPF and DKIM already show pass — that source is already fine under reject. Your work is limited to the failing records, which on a clean domain is usually a short list.
When Should You Move From p=none to Quarantine or Reject?
The three DMARC policy values are not a one-time choice — they are a progression, and each report cycle is the evidence for moving to the next one.
| Policy | What Receivers Do | Risk Level | When to Use |
|---|---|---|---|
| p=none | Deliver mail normally regardless of SPF/DKIM result, just send a report | None — data collection only | First 2–4 weeks after publishing DMARC |
| p=quarantine | Route failing mail to spam or junk instead of the inbox | Low, once reports come back clean | After every legitimate source has passed for 2+ straight weeks |
| p=reject | Refuse failing mail outright at the connection — no delivery, no spam folder | High if any legitimate sender is still failing | After a full quarantine cycle with zero unexplained failures |
Pro and Agency monitoring plans check your records daily or hourly instead of weekly (see pricing), which shortens how long each stage of this progression has to run before you can trust the data.
Reading these reports by hand works fine for one domain. It stops working once you manage ten, because every provider batches differently and the XML format was never built for humans to skim. EmailControl parses this for you and turns each report into a plain pass/fail per sending source — see how the underlying checks work on the FAQ page before you decide whether to automate it.
What Breaks When You Enforce Reject?
Reject fails hard, not soft, so anything still authenticating incorrectly stops being delivered at all rather than landing in spam. The usual culprits are a marketing or support platform sending on your behalf without being added to your SPF record, an employee relaying mail through a personal client that does not use your domain's DKIM key, and mailing list software that rewrites the From header without re-signing DKIM correctly. Check every failing source_ip against your actual list of authorized senders — vendors, internal tools, anything with domain access — before you flip the policy, not after.
A less obvious failure comes from the SPF record itself. RFC 7208, the SPF specification, caps every SPF check at 10 DNS lookups; each include: mechanism you add for a new vendor counts toward that limit. Cross a domain's total past 10 and SPF returns a permanent error for every sender listed in that record, including your own mail server, regardless of whether any individual sender is actually misconfigured. A DMARC report will show this as a blanket SPF failure across every source, which is easy to misread as "everything broke" when the real cause is one record with too many includes.
Do Forwarded Emails Fail DMARC Even When They're Legitimate?
Yes, and this catches almost everyone the first time. SPF checks the IP address that connected to deliver the message, not who originally sent it. When a message is forwarded, the forwarding server's IP replaces the original sender's connecting IP, so it is no longer listed in your SPF record and the SPF check fails outright. RFC 7208, the SPF specification, documents this as expected behavior rather than a bug — SPF was never designed to survive a simple forward. DKIM can survive forwarding if the signature is untouched, and DMARC only needs one of SPF or DKIM to pass and align, so forwarded mail with an intact DKIM signature still passes overall even though SPF alone fails.
Is Moving to Reject Risky for a Small Business?
Yes, some risk is real, and no monitoring service removes it entirely — that is a fair reason to hesitate. The actual risk is narrow, though: it only affects senders who are both sending as your domain and currently failing authentication, which the aggregate reports show you by name before you change anything. A business with three or four known senders (its own mail server, one marketing tool, one helpdesk) can usually verify all three in a single reporting cycle and move with confidence. The businesses that get burned are the ones that skip the reading step and flip straight to reject on the assumption that "we don't send much mail, so it's probably fine" — volume has nothing to do with it; one unverified sender is enough to break real mail.
The other honest answer is time, not technical difficulty. Reading one report is fast. Reading a report every week for a month, across every domain your business owns, is the part people skip, and skipping it is what turns a routine policy change into an outage. That is the actual argument for a scheduled check instead of a manual one — not that the reports are hard to read, but that nobody keeps reading them consistently for a month straight without a reminder.
Start With One Clean Reporting Cycle
Add your domain to EmailControl's free plan and let it collect one reporting cycle before you touch your DNS policy. Start free monitoring — it takes about two minutes, does not require a credit card, and shows you exactly which sources are passing before you decide to enforce anything.