Skip to main content
Reference DMARC

What Is DMARC Monitoring?

DMARC monitoring tracks how your domain is used to send email and whether SPF and DKIM are passing. Here is what it is, how the six email authentication protocols fit together, and what a monitoring tool does day to day.

June 2, 2026 · 9 min read

DMARC monitoring is the ongoing collection and analysis of the aggregate reports that email receivers (Gmail, Outlook, Yahoo and others) send back about messages claiming to come from your domain. It tells you which senders are using your domain, whether their mail is passing SPF and DKIM, and whether your DMARC policy would block or allow it. Monitoring is the step that lets you move a domain safely from a passive policy (p=none) to an enforced one (p=reject) without dropping legitimate email.

You publish a DMARC record because you want to stop people from spoofing your domain. But the record by itself does not tell you whether it is working, whether your own mail is passing, or whether flipping it to enforcement will bounce real customer email. That is what monitoring is for.

What does DMARC actually do?

DMARC (Domain-based Message Authentication, Reporting and Conformance, defined in RFC 9989, which obsoleted the original RFC 7489) is a policy layer that sits on top of two older protocols, SPF and DKIM. It does two jobs at once.

First, it ties SPF and DKIM together through alignment. An attacker can pass SPF using their own infrastructure and their own envelope address while putting your domain in the visible From header. DMARC closes that gap by requiring that the domain that authenticated (via SPF or DKIM) match the domain a human sees in the From line. If neither aligns, DMARC fails.

Second, it lets you publish a policy telling receivers what to do with mail that fails: p=none (take no action, just report), p=quarantine (send to spam), or p=reject (refuse outright). And critically, DMARC is the only one of the email-authentication protocols that asks receivers to send reports back. SPF and DKIM produce a pass or fail at the receiver and that is the end of it. DMARC produces a daily paper trail.

In plain terms: you publish a DMARC record, mailbox providers mail you daily XML reports, and a monitoring tool turns those reports into a readable picture of who is sending as you and what is breaking.

The six protocols and how they fit together

DMARC monitoring is really about a stack of six protocols. Each one covers a different part of the problem.

SPF

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers and IP ranges allowed to send mail for your domain. Receivers check the connecting IP against that list. SPF is the oldest and simplest of the stack, and it does not survive forwarding, which is why DKIM exists.

DKIM

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outbound message. Receivers verify it against a public key you publish in DNS. Because the signature travels with the message, DKIM survives forwarding, which makes it the protocol DMARC alignment relies on most.

DMARC

DMARC requires alignment between the authenticated domain and the visible From domain, declares your fail policy, and requests reporting. It is the keystone that makes SPF and DKIM enforceable per domain rather than just per message.

BIMI

BIMI (Brand Indicators for Message Identification) displays your verified brand logo next to authenticated messages in supporting inboxes, but only once your domain is at DMARC enforcement. BIMI is the payoff for finishing the journey, not a control in itself.

MTA-STS

MTA-STS (RFC 8461) publishes a policy that forces sending servers to deliver mail to your domain over TLS. It blocks downgrade attacks where an attacker strips the encryption and reads inbound mail in plaintext. This protects the transport layer, which DMARC does not touch.

TLS-RPT

TLS-RPT (RFC 8460) is the reporting partner to MTA-STS. It asks sending servers to send you daily reports of every TLS connection failure they hit delivering to your domain, so you can see downgrade attempts and broken certificates rather than guessing.

How monitoring and reporting tie them together

The engine behind DMARC monitoring is the rua= tag in your DMARC record, which points at a mailbox or endpoint where receivers send daily aggregate XML reports. Each report lists every source IP that sent mail claiming to be your domain, the message volume from each, and the SPF, DKIM, and alignment result for each.

TLS-RPT works in parallel for the transport layer, sending JSON reports of TLS failures to the endpoint in your _smtp._tls record.

Raw, this is unreadable: dozens of XML files a day from different receivers, each with its own quirks. A monitoring tool parses every report, groups sources together, flags senders that are not authenticating, and shows you what your policy would do to each one. The output is a list of senders with a clear pass or fail, the new senders that appeared since yesterday, and an honest view of what enforcement would block.

Why p=none to enforcement matters

A DMARC record at p=none is monitor-only. It collects reports but takes no action, which means a spoofed message that fails DMARC is still delivered to the recipient. You are watching the spoofing happen, not stopping it.

The goal is p=reject, where receivers refuse failing mail outright and your domain becomes genuinely spoof-resistant. But you cannot jump there safely. Going from p=none straight to p=reject will bounce every legitimate sender you forgot to authenticate, which on most domains is several of them.

The discipline is to stage it: none to observe, then quarantine with a rising percentage, then reject, and only escalate once the reports show that every real sender is authenticating. Monitoring is what makes each step a data-backed decision instead of a guess.

What a DMARC monitoring tool does day to day

A monitoring tool earns its place by doing the boring work continuously. Day to day it:

  • Ingests your RUA aggregate reports (and RUF forensic reports, where receivers send them).
  • Shows every sending source with a per-source pass or fail and message volume.
  • Flags new senders the moment they appear, so a newly added SaaS tool or a spoofing campaign both surface.
  • Generates the DNS records you need (SPF, DKIM, DMARC, MTA-STS, TLS-RPT) so you are not hand-writing syntax.
  • Alerts you by email, Slack, or webhook when something changes.
  • Tracks your progress toward p=reject and tells you when it is safe to take the next step.

Where PhishFence fits

PhishFence gives your domain a single A-to-F posture grade across the whole stack, ingests your RUA and RUF reports, and runs an enforcement wizard that walks you from p=none to p=reject without breaking real mail.

But there is a second half most DMARC tools ignore, and it is the part worth understanding before you buy anything. DMARC stops exact-domain spoofing. It does nothing about lookalike domains. If an attacker registers acmme.com or acme-login.com instead of forging acme.com, DMARC never enters the picture, because the attacker controls that domain and can authenticate it perfectly well. Those two threats, spoofing your real domain and impersonating you with a lookalike, are the two halves of domain impersonation, and most products solve only one.

PhishFence pairs both: DMARC monitoring and enforcement on one side, and lookalike and typosquat detection with takedown on the other. Email Security is free for one domain, so you can start monitoring today and add the brand-protection half when you are ready.

Frequently asked questions

Is DMARC monitoring the same as having DMARC set up?

No. Setting up DMARC means publishing the DNS TXT record at _dmarc.yourdomain. Monitoring means ingesting and reading the daily aggregate reports that record asks receivers to send. A record with no one reading the reports gives you a policy but no visibility, which is how domains end up stuck at p=none for years or break real mail when they finally flip to enforcement.

What is the difference between SPF, DKIM, and DMARC?

SPF is a DNS record that lists which servers are allowed to send mail for your domain. DKIM is a cryptographic signature on each message that receivers verify against a public key in your DNS. DMARC sits on top of both: it requires that an SPF or DKIM pass also aligns with the visible From domain, tells receivers what to do when neither aligns (none, quarantine, or reject), and is the only one of the three that asks receivers to report back.

What are RUA and RUF reports?

RUA reports are the daily aggregate XML reports a receiver sends summarising every source that sent mail claiming to be your domain, with per-source SPF, DKIM, and alignment results and message counts. RUF reports are per-message forensic reports of individual failures, sent by far fewer receivers and often redacted for privacy. RUA is what DMARC monitoring runs on day to day; RUF is supplementary.

Do I need MTA-STS and TLS-RPT if I already have DMARC?

They solve a different problem. DMARC, SPF, and DKIM authenticate who sent a message. MTA-STS forces inbound mail to your domain to use TLS so it cannot be downgraded to plaintext and intercepted, and TLS-RPT sends you daily reports of any TLS failures. You can run DMARC without them, but a complete email-security posture publishes all of them, and a monitoring tool that grades your domain will check for all of them.

How long does it take to reach p=reject?

For a domain with a handful of senders, six to twelve weeks is typical. The ramp is: stay at p=none for at least two weeks to identify every legitimate sender, fix SPF and DKIM gaps until the pass rate is high, move to p=quarantine and raise the percentage over several weeks, then move to p=reject once the pass rate has been stable above roughly 98 percent for two consecutive weeks. Domains with many third-party senders take longer.

Does DMARC stop lookalike domains?

No. DMARC stops exact-domain spoofing, where an attacker forges your real domain in the From header. It does nothing about lookalike or typosquat domains (for example acmme.com or acme-login.com) because those are different domains the attacker controls and can authenticate themselves. Stopping lookalikes requires separate variant detection and takedown, which is the other half of domain impersonation.

Can I monitor DMARC for free?

Yes. PhishFence Email Security has a free tier that monitors DMARC on one domain, ingests your RUA and RUF reports, and grades your posture from A to F. You only pay when you need more domains or the paid features.