Monitor

Getting to p=reject is a milestone, not a finish line. The day after you enforce, your email setup keeps changing: a team buys a new SaaS tool that sends on your behalf, a provider quietly swaps its sending IPs, someone edits a DNS record during an unrelated migration. Any one of those can start failing authentication, and without monitoring you will not know until legitimate mail lands in spam or a regression quietly reopens the door you just shut. Step 4 is the work that keeps enforcement honest.

Why enforcement is not a one-off

DMARC enforcement protects a moving target. Your authorised senders are not a fixed list you write once and forget. They drift, and they drift constantly:

• New tools get added. Sales signs up for an outreach platform. Support adopts a new helpdesk. Finance switches invoicing software. Each one wants to send from @yourcompany.com, and if nobody updates SPF or sets up DKIM for it, that mail fails alignment and gets quarantined or rejected.
• Providers change their infrastructure. An email service updates its sending IP ranges, or rotates the DKIM keys it manages. If you flattened SPF to fixed IPs without tracking the upstream, your record can go stale and start failing for senders that were fine last month.
• People edit DNS. A well-meaning change to a TXT record, a registrar migration, a copy-paste error that drops a mechanism. DNS is shared infrastructure, and the person touching it rarely realises a DMARC, SPF or DKIM record is load-bearing.
• Keys and certificates expire. A 2048-bit DKIM key you rotated out, a VMC certificate for BIMI, an MTA-STS policy you forgot to renew. Time alone can break a working setup.

None of these announce themselves. The failure mode of email authentication is silent: mail just stops arriving, or starts arriving in the junk folder, and the first you hear of it is a customer asking why your invoice never came through. Monitoring is how you turn a silent failure into a notification you can act on the same day.

What continuous monitoring watches

Every mailbox provider that receives your mail sends back a daily aggregate report to the address in your rua= tag. These XML reports are the raw material. On their own they are unreadable, thousands of lines of source IPs, message counts and pass or fail verdicts per provider. Parsed and trended over time, they tell you exactly what is happening to mail claiming to be from your domain.

Continuous monitoring watches a handful of signals that matter:

• Pass-rate trend. What percentage of your mail passes DMARC today, and is that number stable, climbing or slipping? A healthy enforced domain sits near 100% for legitimate traffic.
• New sending sources. An IP or provider that has never sent for your domain before suddenly appears. Sometimes it is a new tool a team added. Sometimes it is a spoofer testing your defences.
• Alignment drops. Mail that passes raw SPF or DKIM but fails alignment because the signing d= domain or the SPF domain no longer matches your visible From. This is the subtle failure flattening and provider changes tend to cause.
• Policy changes. The published policy itself moving from p=reject back to p=quarantine or p=none, whether by accident or by someone reverting a change they did not understand.
• Volume anomalies. A sudden spike in failing mail from a single source, the signature of an active spoofing campaign against your brand.

Our analytics turn those daily reports into trend lines and a per-source breakdown, so you can see at a glance whether your domain is healthy or whether something needs attention.

Alerting that reaches you

A dashboard you have to remember to open is not monitoring. The point of Step 4 is that the system watches so you do not have to, and tells you when something changes. Alerts can reach you by email, Slack or webhook, so the warning lands wherever your team already works.

Email suits a domain owner who wants a daily or weekly digest. Slack suits a team that lives in a channel and wants the on-call person to see a failure immediately. Webhooks suit anyone who wants to wire alerts into an existing incident tool, a ticketing system or a status page. The transport matters less than the trigger: an alert is only useful if it fires on the events that actually mean trouble, and stays quiet otherwise.

The regression risk you are guarding against

The reason monitoring earns its keep is regression: a change somewhere quietly undoes the protection you spent weeks building. The three most common ways enforcement regresses are worth naming, because each is invisible without reports coming back to you.

A record reverted to p=none

Someone restores an old DNS zone from backup, or a templating tool overwrites your record with a default, and your policy drops from v=DMARC1; p=reject back to v=DMARC1; p=none. Mail still flows, nothing visibly breaks, and your domain is now spoofable again. The only sign is in the reports: receivers start applying no policy, and the protection you announced to the world is gone. Monitoring catches the policy change the day it happens.

An expired or rotated DKIM key

You published a key at s1._domainkey.yourcompany.com, rotated to s2, and removed the old selector too soon while some mail systems still signed with it. Or a provider rotated a key they manage and the new public key never made it into DNS. Suddenly a slice of your mail fails DKIM, and because SPF does not survive forwarding, forwarded copies of that mail fail DMARC entirely. Aggregate reports show the DKIM pass rate dropping for a specific selector.

SPF creeping back over 10 lookups

RFC 7208 caps SPF at 10 DNS lookups. You flattened your record to get under it, then over the following months someone added include: mechanisms for two new tools. The eleventh lookup tips you over, SPF returns permerror, and every receiver that relies on SPF for alignment now fails it. This is the classic creep: each addition is reasonable on its own, and the total quietly breaks the limit. Monitoring flags the permerror the moment it appears in the reports.

Periodic reviews and key rotation hygiene

Alerts handle the urgent. Periodic reviews handle the slow drift that never quite trips an alert. A sensible cadence is a quarterly review where you check a few things by hand:

• Confirm your sender list still matches reality. Walk through the sending sources in your reports and confirm each is a tool you still recognise and still use. Remove SPF mechanisms and DKIM selectors for services you have retired, because every leftover entry is attack surface and SPF lookup budget you do not need.
• Rotate DKIM keys on a schedule. Plan key rotation so a new selector is published and signing before the old one is withdrawn. Rotating little and often, with overlap, means no window where mail fails because the key it was signed with is gone. Selectors exist precisely so you can do this without downtime.
• Check certificate and policy expiry. A BIMI VMC certificate, an MTA-STS policy version, any record with a renewal date attached. Put the dates somewhere you will see them before they lapse.
• Re-read your own records. Count the SPF lookups again. Confirm the policy is still the one you intend. Confirm the rua= address still points somewhere you read.

This is hygiene, not heroics. Twenty minutes a quarter prevents the kind of slow erosion that turns a clean enforced domain into a leaky one over a year.

How this ties into MTA-STS and TLS reports

DMARC, SPF and DKIM protect mail leaving your domain: they stop other people sending as you. They do nothing for mail arriving at your domain. The inbound half of the picture is MTA-STS and TLS reporting, and the same monitoring discipline applies to both.

MTA-STS publishes a policy at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt alongside a _mta-sts TXT record, and it forces sending servers to use TLS when delivering mail to you, so an attacker cannot strip encryption and read or tamper with messages in transit. TLS-RPT, a _smtp._tls TXT record with its own rua=, collects daily reports on TLS handshake failures from the servers that tried to reach you.

Those daily TLS reports deserve a place in the same monitoring view as your DMARC reports. A rising count of TLS failures can mean a certificate problem on your inbound mail servers, a misconfigured MTA-STS policy, or an active attempt to downgrade your connections. If your MTA-STS mode is still testing, the reports tell you whether it is safe to move to enforce. Watching outbound authentication and inbound TLS together gives you the complete health of your mail flow in one place.

A misconfiguration cannot quietly undo months of work

The reassurance Step 4 buys you is simple: a single bad change cannot silently reverse everything you built in steps one to three. The reports keep coming, the trends keep updating, and the moment a policy weakens, a key fails or an SPF record breaks the lookup limit, the alert fires and you fix it the same day. Enforcement without monitoring is a setting you hope is still correct. Enforcement with monitoring is a setting you can prove is correct, every day, with evidence from the receivers themselves.

This is also where compliance lives. PCI DSS 4.0 requirement 5.4.1, mandatory since 31 March 2025, treats DMARC as the recognised anti-phishing control, and the same questions appear in cyber-insurance forms and vendor security reviews. Those reviewers do not just want to know you published a record once. They want to know it is still enforced and still watched. Continuous monitoring is the evidence trail that answers them.

Where this fits in the four steps

Step 4 only makes sense once you have reached enforcement. The earlier work, monitoring at p=none to learn your senders, fixing SPF and DKIM alignment, then moving to p=quarantine and p=reject, gets you to a clean policy. This step keeps it clean. If you have not yet checked where your domain stands, a free scan shows your current policy, your SPF lookup count and whether your records are aligned, in a few seconds. If you are already enforced, the question is no longer whether you are protected today. It is whether you will still be protected next month, after the next new tool, the next provider change and the next DNS edit.

Enforcement is an event. Authentication health is a state, and states drift. Monitoring is the discipline that holds the state where you put it, turning every silent regression into a notification you can act on before it costs you a delivered email or a passed audit. You do the hard work once; monitoring is what makes it stay done.