What Is DMARC Monitoring? The Visibility Layer Explained

DMARC monitoring is the ongoing practice of collecting, parsing, and analyzing the aggregate reports that email receivers send back about your domain, so you can see every source sending as you, whether those sources are authenticating correctly, and whether anyone is spoofing your domain. It's the visibility layer that sits on top of a published DMARC record. Setting up DMARC tells receivers what to do with mail that fails. Monitoring tells you what's actually happening.

The two get conflated constantly. Publishing a _dmarc TXT record is a one-time DNS change. Monitoring is the thing you do every day after that, and it's where the actual value lives, because a DMARC record without monitoring is just a policy you can't see the effects of.

What DMARC monitoring actually watches

DMARC monitoring watches aggregate reports: the XML feedback files that participating mail receivers (Google, Microsoft, Yahoo, and most large providers) generate for your domain and send to the address in your record's rua= tag.

You opt into these reports by publishing a rua= address. Per RFC 9989, the DMARC core specification, if the rua tag isn't present, receivers must not generate aggregate reports for your domain at all. So the first thing monitoring depends on is a record like this:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

Once that's live, receivers start mailing you a report, typically once per day per receiver, summarizing the mail they saw claiming to be from your domain.

What's in an aggregate report is statistical, not content. For each sending IP address it saw during the reporting window, the report records:

• The source IP that sent the mail
• A message count for that IP
• The disposition the receiver applied (none, quarantine, reject)
• The DKIM result and whether it aligned with your From: domain
• The SPF result and whether it aligned with your From: domain

Aggregate reports deliberately contain no message subjects, no bodies, no recipient addresses, and no individual message IDs. The smallest unit is a group of messages from one IP in one reporting period. They're designed to give you sending-source visibility without exposing private mail. (We cover exactly what arrives in what DMARCdrift receives and what's in a DMARC aggregate report.)

That's the raw material. Monitoring is what turns it into something you can act on.

Why raw reports are unreadable, and what a monitor does

Here's the catch that makes monitoring a product rather than a habit: aggregate reports are gzipped XML attachments, one per receiver, arriving daily. Open one and you get a few hundred lines of nested <record> elements with IP addresses, policy evaluations, and counts. Get mail from Google, Microsoft, Yahoo, and a handful of smaller providers and you're decompressing and reading multiple XML files every single day, then mentally diffing them against yesterday's to notice anything changed.

Nobody does this for long. It's the reason most domains publish a DMARC record, point rua= at an inbox, and then never look again. The reports pile up unread because parsing raw gzipped XML by hand is tedious and easy to abandon.

A DMARC monitor does three things with that stream:

1. Parse: decompress each report and extract the structured records, normalizing across every receiver's slightly different output into one schema.
2. Aggregate: roll those records up across all reporters and across time, so "Mailchimp sent 1,240 messages last week, 98% aligned" replaces forty XML files.
3. Alert: watch the aggregated picture for changes that matter: alignment dropping, a brand-new sending source appearing, your DNS policy changing, spoofing volume climbing, and tell you, instead of waiting for you to go digging.

That's the whole job. Parse the unreadable, aggregate the scattered, surface the important.

Monitoring is not the same as setting up DMARC

This is the distinction worth being precise about, because it's the source of most confusion.

Setting up DMARC is publishing the record: choosing your policy (p=none, quarantine, or reject), your alignment modes, and your reporting address, then putting one TXT record in DNS. It's configuration. You do it once, and you revise it occasionally. Our getting-started overview and the DMARC record reference walk through every tag.

Monitoring DMARC is the ongoing visibility layer that runs forever after. The record is a directive aimed at receivers; monitoring is a feedback loop aimed at you. The record never tells you whether your legitimate senders are passing, whether a new vendor you onboarded last month is aligned, or whether someone started spoofing you on Tuesday. Only the reports do, and only if something is reading them.

Put bluntly: setting up DMARC without monitoring is like installing a security camera and never watching the footage. The deterrent record is published, but you have no idea what it's catching.

What monitoring surfaces

A good DMARC monitor turns the report stream into a small number of answers you actually care about:

Alignment rate: the percentage of your reported mail where at least one mechanism (DKIM or SPF) passed and aligned with your From: domain. This is the headline number. It tells you how much of your real mail would survive an enforcement policy. It's rarely 100% at first. Forwarding breaks SPF, and a not-yet-configured vendor drags it down, so watching it climb as you fix sources is the core loop. (See how the alignment rate is calculated.)

Sending sources: every IP and service sending as your domain, grouped and labeled. This is where you discover the SendGrid account a teammate set up, the invoicing tool nobody told you about, or the marketing platform that's been failing DKIM for a month. You can't align a source you don't know exists.

Spoofing signals: mail from sources you don't recognize, failing authentication, claiming to be you. At p=none this is exactly the data you're collecting reports to see: is someone impersonating your domain? Aggregate reports won't name the attacker, but they show the unauthorized IPs and the volume.

Policy and DNS drift: changes to the DMARC record itself. Someone edits DNS, a registrar migration drops a tag, or your p=reject quietly reverts to p=none. Monitoring catches the record changing out from under you, which a one-time setup check never would.

How monitoring fits the p=none → quarantine → reject journey

DMARC enforcement is a progression, and monitoring is what makes each step safe.

You start at p=none: receivers deliver everything normally and just send reports. RFC 9989 calls this Monitoring Mode, and it exists for exactly one reason: to let you collect aggregate reports and confirm your legitimate mail is authenticating before you ask receivers to start junking or rejecting anything. The reports are the entire point of this stage.

You read those reports (monitoring), identify every legitimate sender, and fix their SPF and DKIM until your alignment rate is consistently high, generally well above 98%, before you tighten. Then you move to p=quarantine (failing mail goes to spam) and keep watching to confirm nothing legitimate started getting junked. Finally p=reject (failing mail is refused outright), with monitoring still running so a newly-added vendor doesn't silently start bouncing.

At every stage, the question monitoring answers is the same: if I tighten the policy right now, what legitimate mail breaks? Without the reports, you're guessing. The full path is laid out in the DMARC enforcement roadmap and the enforcement readiness checklist.

A practical note on the current spec: the DMARCbis revision (RFC 9989, 9990, and 9991, published May 20, 2026, obsoleting the original RFC 7489 from 2015) removed the old pct= "ramp to enforcement gradually" tag. It's now marked historic. You no longer dial enforcement up by percentage; you move policy levels deliberately, which makes monitoring more important, not less, because the jump from none to quarantine is now all-or-nothing for the mail that fails.

A note on what monitoring needs underneath it

Monitoring shows you alignment results, but the things it reports on are SPF and DKIM doing their jobs:

• SPF authorizes which IPs may send for your domain. A common failure monitoring will surface is the SPF 10-lookup limit: per RFC 7208 §4.6.4, an SPF check that triggers more than 10 DNS-querying mechanisms (include, a, mx, ptr, exists, or redirect) must return permerror, which means SPF fails even for legitimate mail. If your alignment rate is mysteriously capped, this is a frequent culprit. (SPF flattening is the fix.)
• DKIM attaches a cryptographic signature tied to a signing domain (d=), and per RFC 6376 verifying it proves the signed content wasn't altered in transit. DMARC checks whether that d= domain aligns with your From:.

DMARC alignment passes when either SPF or DKIM passes and aligns. That's why monitoring reports both, and why DKIM and DMARC aren't alternatives: DMARC is the policy and reporting layer that sits on top of both.

Who needs DMARC monitoring

If you send email from your own domain and anyone could be harmed by mail that fakes your address, whether customers, employees, or partners, you need monitoring. Concretely:

• You're at p=none collecting reports. Monitoring is the only way to use them. Otherwise you're paying the deliverability tax of a DMARC record with none of the visibility payoff.
• You want to reach p=reject safely. You cannot tighten policy without knowing which legitimate senders would break, and that knowledge lives only in the reports.
• You send through multiple services. Transactional, marketing, invoicing, support: every SaaS sender is a source that can quietly fall out of alignment. Monitoring is your inventory of who's sending as you.
• You're worried about spoofing. Aggregate reports are the cheapest way to see unauthorized senders impersonating your domain.

See it on your own domain

The fastest way to understand monitoring is to look at your domain's current posture. Run a free DMARC record check to validate your record and see whether rua= is even set, or paste a report into the DMARC report analyzer to see what one of those gzipped XML files actually says once it's parsed. To check SPF, DKIM, and DMARC together in one view, use the email authentication checker.

If your reports have been piling up unread, that's not a discipline problem. It's a tooling problem. DMARCdrift parses them, aggregates them, and alerts you when alignment drops, a new sender appears, or your policy drifts, so the visibility layer runs without you opening a single XML file. Point your rua= at it and start watching your domain.