DMARC Monitoring for UK Organisations and MSPs
Publishing a DMARC record takes five minutes. Knowing whether it is safe to enforce takes weeks of report data. Monitoring is the part in between — collecting the aggregate reports receivers send back, turning them into a list of everything that sends as your domain, and using that list to decide when enforcement will not break anything. This page covers what those reports contain, what monitoring shows that a lookup cannot, and how it works across a portfolio of UK client domains rather than one.
A checker reads your DNS. Monitoring reads your mail.
Almost everyone starts with a lookup tool, and they should. Our DMARC checker tells you whether a record exists, whether it parses, what policy it declares and where its reports go. Pair it with the SPF analyzer for the include chain, a DNS lookup to confirm what is published, and the DMARC generator to build the record.
Every one of those answers a question about configuration. None answers the question that decides whether you can enforce: who is currently sending email claiming to be this domain, and are they authenticating? That data does not live in DNS. It arrives afterwards, from the receivers, as aggregate reports — and only if you have published an address for them to be sent to.
So a domain can pass every lookup you throw at it and still be one policy change away from silently dropping its own invoices. The record is valid; the sender inventory is incomplete. Only report data closes that gap.
A checker answers: is the record correct?
- check_circlePoint-in-time, on demand, no setup, free.
- check_circleSyntax, policy value, reporting addresses, alignment mode.
- check_circleWorks on any domain, including a prospect you cannot access.
- cancelSays nothing about real message flow, senders or pass rates.
Monitoring answers: is the record safe to enforce?
- check_circleContinuous, cumulative, built from reports receivers send you.
- check_circleNamed sender inventory, volumes, SPF and DKIM alignment results.
- check_circleDetects change over time — new senders, dropping pass rates, rotated keys.
- cancelRequires a published reporting address and a few days before it is useful.
The NCSC's free Email Security Check remains available after Mail Check and Web Check were retired on 31 March 2026, and it sits firmly in the left-hand column above: an on-demand configuration lookup that does not ingest aggregate reports. To be explicit, DMARC AI is not affiliated with, approved by or endorsed by the NCSC, and the NCSC does not endorse individual DMARC products.
What is actually in the XML.
Aggregate reports — named after the rua= tag that points at your collection address — are XML documents receivers generate and send back, typically once a day. They contain no message content and are not per-message: each report is a set of counted rows grouped by source IP and authentication outcome.
Who generated the report, a contact address, a unique report ID and the date range covered. This is how you tell a quiet week from a receiver that stopped reporting.
The DMARC record as the receiver read it: domain, policy, subdomain policy and alignment modes. Useful for confirming a DNS change actually propagated to the receivers that matter.
The substance. Per source IP: message count, DMARC disposition, and the SPF and DKIM results with the domains and selectors that produced them.
The row is where the real information sits. One says, in effect: this IP sent 412 messages, the header From domain was example.co.uk, DMARC passed, SPF passed against mail.example.co.uk, and a valid DKIM signature came from example.co.uk using selector s1.
Under DMARCbis, published in May 2026, aggregate reporting has its own specification — RFC 9990 — alongside RFC 9989 for the core protocol and RFC 9991 for failure reporting. One change matters directly here: DKIM detail in aggregate reports is now required rather than optional. Some receivers used to return an SPF verdict and little else, which made diagnosing a DKIM alignment failure guesswork. Reports produced to the new specification carry the signing domain and selector — exactly what you need to identify a third-party sender.
Two properties follow from the format: you get counts rather than individual messages, and reports arrive on the receiver's schedule — which is why a full picture takes days rather than hours.
Alignment is the concept everything hinges on
DMARC does not simply ask whether SPF or DKIM passed. It asks whether the domain that passed matches the domain in the header From address a human sees. That match is alignment, and a message passes DMARC when at least one of SPF or DKIM both passes and aligns.
Strict mode requires an exact match. Relaxed mode — the default — requires a shared organisational domain. That is a UK trap, because .co.uk is a public suffix: the organisational domain of example.co.uk is example.co.uk, not co.uk. So news.example.co.uk can align relaxed with example.co.uk, while example-news.co.uk never will.
This is why a report showing "SPF: pass" alongside "DMARC: fail" is normal rather than contradictory. The mail authenticated against the sending platform's own bounce domain, which does not align with the client's brand. The fix is not more SPF — it is a DKIM signature on the client's domain, or a custom return-path.
Four things a lookup will never tell you.
These are the findings that make monitoring worth paying for, and they are the same four every time — every sector, portfolios of five domains and five hundred.
Shadow senders
The systems nobody mentioned during onboarding: the appointment reminder tool a practice manager signed up for, the recruitment platform HR pays for on a card, the on-premise server still sending scanned documents. They appear as source IPs sending real volume, and they are invisible to DNS inspection because nobody ever added them to SPF. The inventory this produces is usually the most valuable artefact of month one.
Forwarding, and why it looks like an attack
Forwarding breaks SPF almost by definition: the forwarding server relays from its own IP, which is not in your SPF record, so SPF fails at the next hop. DKIM usually survives, because the signature covers the headers and body rather than the connection — as long as nothing rewrites the content, it still verifies and still aligns. That asymmetry is why DKIM alignment matters more than SPF for reaching enforcement, and why failing forwarded mail is not evidence of spoofing.
DKIM key rotation that quietly failed
Signing keys get rotated — by policy, by a platform migration, or automatically by a provider. If the DNS record for the new selector never got published, messages keep being signed and keep failing verification. Nothing in the sending system alarms, because from its perspective it is signing correctly. In aggregate reports it shows up immediately as an unfamiliar selector with a DKIM result that is not a pass.
Third-party SaaS drifting out of alignment
Marketing platforms, e-signature services, helpdesks and payroll tools each have their own default: some sign with their own domain, some offer a custom signing domain only on request, some change infrastructure without notice. Reports show the drift the day it happens, not the week a client rings to say the newsletter has vanished. For one message, the email header analyzer shows the full authentication trail.
From p=none to p=reject.
Worth saying plainly, because it is the most misunderstood point about DMARC: monitoring does not protect anything. A domain at p=none collects data while telling receivers to take no action, so it is as spoofable on day ninety as on day one. Protection begins at quarantine and completes at reject. Monitoring is what makes those steps safe to take.
p=none — build the inventory
Publish with a reporting address and wait. Reports normally start arriving within 24 to 48 hours; a usable inventory takes two to four weeks, longer where finance, marketing and HR all send independently. Watch the monthly cycle — statement runs, payroll notifications and quarterly mailings will not appear in week one.
p=quarantine — first enforcement
Move only when every legitimate sender is aligned and the pass rate has been stable across a full reporting cycle. DMARCbis removed the pct= tag, so there is no partial ramp to hide behind — each policy level applies to all mail, and inventory quality rather than a percentage is the safety mechanism. Keep a one-business-day rollback window and put the change in the client change calendar.
p=reject — steady state
Advance when quarantine has run clean for several reporting cycles. Monitoring does not stop; it changes job, from discovery to regression detection. New SaaS signups, acquired brand domains, delegated subdomains and key rotations all show up as a change in the reports, and at reject a missed one has consequences the same day.
Subdomains need their own decision at each step: without an explicit subdomain policy, the organisational domain policy applies to them.
What UK organisations end up watching in the reports.
The protocol is identical everywhere. What differs is which findings a UK organisation must act on, and who is asking.
The reporting address left over from a retired service. Plenty of UK domains still carry a rua= address pointing at a service that no longer processes reports. The record still validates, so no checker flags it, and the reports go into a void. Auditing a book for stale reporting addresses is a short job with an immediate finding.
Public sector evidence. GOV.UK guidance on securing government email (updated 4 March 2024) states that public sector organisations must support DMARC and have DMARC, DKIM and SPF records in place. That is policy guidance under the Government Cyber Security Policy rather than statute, but the effect is that a public sector body has to evidence its position to an assurance process rather than merely know it. A monthly report answers that; a screenshot of a lookup does not.
Delivery to consumer mailboxes. Google bulk sender requirements have applied since 1 February 2024: senders of 5,000 or more messages a day to personal Gmail accounts must have SPF, DKIM and DMARC with a policy of at least p=none, keep spam complaints below 0.3% and offer one-click unsubscribe on marketing mail. From November 2025 Gmail escalated enforcement with temporary and then permanent rejections, and Microsoft has comparable requirements for high-volume senders to Outlook.com. UK organisations that mail consumers feel this first.
What nobody requires. Cyber Essentials includes no DMARC, SPF or DKIM control — its five technical controls are firewalls, secure configuration, security update management, user access control and malware protection. Monitoring is worth doing on its own merits, but presenting it as a Cyber Essentials deliverable will not survive contact with an assessor.
One domain is a task. Sixty domains is a service.
Reading aggregate reports for one domain with two senders is tedious but survivable. Across a client book it fails structurally: the volume of XML grows with domains multiplied by receivers multiplied by days, while the signal you care about — one new sender, one pass rate slipping — stays the same size. The MSP practice guide covers the commercial shape; this is the operational one.
Portfolio first, domain second
Every client domain in one view with per-tenant separation, so the daily question is "what changed anywhere" rather than sixty logins.
Exceptions, not dashboards
A dashboard nobody opens is not monitoring. What matters is being told when a new source appears or a pass rate moves against a domain that is already at enforcement.
Reporting a client can read
The monthly output has to go to a client without an engineer rewriting it first. That difference is what turns monitoring from unbillable effort into a service line.
Cost that scales the right way
Transparent MSP pricing from just £1 per domain per month, with volume-based pricing where the per-domain price falls as you add domains. Detail on the UK pricing page.
Migrating a book of domains from a retired reporting service? Repointing rua= is mechanical, but historic findings do not transfer — plan a fresh monitoring window. The Mail Check replacement page walks through it.
The rest of the UK cluster.
Questions UK MSPs ask us.
What is the difference between a DMARC checker and DMARC monitoring? add
A checker is a point-in-time lookup: it reads your DNS and tells you whether the record parses and what policy it declares. Useful, instant, and free — but it tells you nothing about your actual mail.
Monitoring collects the aggregate (RUA) reports that receivers send back, which is the only way to learn which sources are sending as your domain and whether they pass authentication. You need the checker to publish a valid record and monitoring to act on what happens next.
Does the NCSC Email Security Check do this? add
Not the monitoring part. The NCSC's free Email Security Check is an on-demand lookup that inspects your published DMARC configuration and your transport security. It does not ingest aggregate reports, so it cannot tell you who is sending as your domain over time.
It is a sensible free first check. It is not a replacement for report-based monitoring, which is what Mail Check used to provide before it was retired on 31 March 2026.
How long should we stay at p=none? add
Long enough to build a complete sender inventory — typically two to four weeks for a straightforward domain, longer where marketing platforms, ticketing systems, payroll providers and finance tools all send on the domain's behalf.
The signal to move on is not elapsed time but stability: when a full reporting cycle produces no unexplained senders and legitimate mail is passing consistently, you are ready for p=quarantine.
What are aggregate reports and why can't we just read them ourselves? add
Aggregate reports are XML documents that receiving mail providers send to the address in your rua= tag, usually daily, summarising which IPs sent mail claiming to be your domain and whether SPF and DKIM aligned.
You can read them manually, and for one domain with two senders it is tolerable. Across a portfolio it is not: the volume is high, the format is designed for machines, and the useful signal — a new sender appearing, a pass rate dropping — is easy to miss by eye.
Will monitoring alone stop spoofing? add
No, and this is the most important thing to understand about DMARC. A policy of p=none collects data but instructs receivers to take no action, so the domain remains spoofable throughout the monitoring phase.
Protection begins when you reach p=quarantine and completes at p=reject. Monitoring is the mechanism that gets you there safely, not the protection itself.
What about forwarded mail breaking authentication? add
Forwarding commonly breaks SPF, because the forwarding server is not in the original domain's SPF record. DKIM usually survives forwarding as long as the message body is not modified, which is why DKIM alignment matters so much for reaching enforcement.
Mailing lists are the harder case, since they often rewrite headers and bodies. ARC exists to preserve the original authentication result across such hops, though receiver support for it varies.
See who is really sending as your domain.
Add a domain, point its aggregate reports at DMARC AI, and read a parsed sender inventory instead of XML. Transparent MSP pricing from just £1 per domain per month, with volume-based pricing where the per-domain price falls as you add domains.