Reading your first DMARC report

What a DMARC report actually is

Once a day, every major mailbox provider that received mail claiming to be from your domain bundles up what they saw and sends you a single XML file. That's it. You're not getting a report per message — you're getting a daily digest from each receiver, summarizing the previous 24 hours.

Each report tells you: who sent it (the receiver, e.g. Google), the time window it covers, what DMARC policy you had published when they checked, and a row-by-row breakdown of the messages they saw — grouped by source IP. That's the entire structure.

On our side, we parse the XML, store the rows in a database, run sender-IP identification to attach a vendor name (Google Workspace, SendGrid, whoever), and surface the result in plain English. You don't have to read the XML yourself — but understanding the shape helps when you're trying to figure out whether a row is normal or suspicious.

The report header — who, when, what policy

Open any report drill-down on the dashboard and the first card is the header. It tells you four things:

• Reporting organization — the receiver. Google, Yahoo, Microsoft, Mail.ru, Proofpoint. Each one sends a separate report. If you have customers across all the major mailbox providers, you'll see a daily report from each.
• Date range — typically the previous calendar day in UTC. Aggregated reports are after-the-fact; receivers don't send a report per message in real time.
• Domain — your domain. If a receiver got mail claiming to be from acme.com, you get the report. (If a receiver got spoofed mail with a forged From: header pointing at your domain, that also shows up — which is the whole point of DMARC.)
• Published policy — what your DMARC record said when the receiver checked. Usually p=none for new setups. Worth glancing at — if it doesn't match what you think you published, your record changed and you didn't notice.

The records section — one row per source IP

Below the header is the part that matters. Each row is a sending source the receiver saw, with:

• Source IP — the IP address that connected to the receiver and tried to send mail claiming to be from your domain. We attach a vendor name when we can match it (Google Workspace, Amazon SES, etc.), or call it Unknown if we can't.
• Message count — how many messages from that source IP the receiver saw in the report window.
• Disposition — what the receiver actually did with the mail. none = delivered normally, quarantine = sent to spam, reject = bounced. With p=none in your DMARC record, the disposition is always none — the receiver isn't enforcing yet, just observing.
• SPF and DKIM results — pass / fail / softfail / etc. for each authentication mechanism that ran on the message.
• Alignment — the most important column, and the one most people miss. SPF and DKIM can each pass or fail; alignment is a separate check that asks "did the authenticated identity match the From: header domain?" A message can pass SPF but fail SPF alignment. We have a whole article on this.

The three patterns to recognize

Pattern 1: Your ESP, all aligned, all pass — the happy case

Most rows on a healthy report will look like this. The source IP belongs to Google Workspace, Microsoft 365, SendGrid — whoever you actually use. SPF passes and is aligned, DKIM passes and is aligned, disposition is none because you're at p=none, and the count is consistent with how much mail you sent that day.

This is what you want. The bulk of your daily reports should be these rows. Once you see a week of clean reports, you can start progressing past p=none with confidence.

Pattern 2: Unknown source IP, all aligned, all pass — a vendor you forgot about

Aligned + passing means the sender is producing valid SPF and/or DKIM for your domain. They have legitimate authority to send. So if the IP shows up as Unknown but everything passes, it's almost always a vendor you set up at some point and forgot — a marketing tool, an invoicing platform, a Helpdesk app, an old transactional sender.

These are the rows the dashboard's Identify button is for. Click it, name the vendor, set the category, and the row turns into a known sender for every future report. Your team's mental model of "who sends mail as us" becomes accurate.

Worth doing this even when the volume is small — a single legitimate vendor you don't recognize today is the vendor you'll forget about when something breaks in three months.

Pattern 3: Unknown source IP, NOT aligned, mass volume — likely spoofing

This is what DMARC was built to surface. A source IP we don't recognize, with a meaningful message count, and SPF/DKIM either failing outright or passing but failing alignment. That last case is the most common — spoofers can pass SPF or DKIM for some domain they control, but they can't pass alignment to your From: header without actually being authorized to send as you.

At p=none these messages are still being delivered (the disposition is none regardless). The report is the smoking gun; the enforcement comes later when you progress past p=none. The whole reason DMARC has a monitoring phase is so you can identify these patterns BEFORE turning on enforcement — so legitimate mail stays through and only the spoofers get caught.

On the dashboard, these rows usually show up in the Needs-attention panel or flagged on the Senders tab. If you see one, the response is:

1. Don't panic — this is what monitoring is supposed to find.
2. Check the volume. A few messages might be a misconfigured legitimate sender; thousands of messages from a foreign IP block is plausibly an active campaign.
3. Confirm it's not yours — check with team members or your IT lead before flagging it as spoofing.
4. Once you're confident the rest of your sender corpus is identified and clean, progress your DMARC policy to p=quarantine and then p=reject. Now those spoofed messages stop getting delivered.

What "report from receiver X" doesn't tell you

A few things people expect to find in DMARC reports that aren't there:

• Message contents. Reports are aggregate metadata only — no subject lines, no message bodies, no recipient names. Just source IP + count + auth results. (Forensic / failure reports — RUF — include more context but most receivers stopped sending those years ago.)
• Specific recipients. The receiver's report tells you what they saw, not where any individual message went. You don't get a "user X received Y messages" breakdown.
• Real-time data. Reports are daily aggregates of the previous calendar day. If something started happening 2 hours ago, the first report covering it lands tomorrow.
• Outbound delivery confirmation. A DMARC report says "the receiver saw mail claiming to be from you" — it doesn't confirm any specific outbound message reached its inbox. For that you'd need separate delivery telemetry from your ESP.

What to do after reading your first report

Three concrete moves:

1. Identify any Unknown vendors with material volume — turning Unknown into known shrinks the risk of false positives later.
2. Set a calendar reminder for 7 days from now. Look at the accumulated reports as a series, not as a single snapshot. Patterns that take a week to surface are the ones that matter.
3. Don't change your policy yet. One report isn't enough signal to ramp from p=none to enforcement. Two clean weeks of reports is the cadence we recommend, walked through in Progressing past p=none safely.

Related

• DMARC alignment, in plain English — the most important column in any report row.
• Progressing past p=none safely — what to do once your reports look healthy.
• What is DMARC? — the 5-minute primer if you skipped it.