Email Domain Health: What IT Admins Should Be Monitoring (MX, SPF, DKIM, DMARC, and Sender Reputation)
Drafted with AI assistance and reviewed before publishing. How we write and source articles →
TL;DR: MX, SPF, DKIM, and DMARC are the four DNS-level checks that determine whether your organisation’s email is trusted, not just delivered. Most IT admins set these up once — often as part of migrating to Microsoft 365 — and never revisit them. That’s a problem, because a domain can have all four “configured” and still be failing silently, most commonly because its DMARC record is published at p=none (monitoring only, not enforcing anything). This article walks through what each layer actually checks, why they only work as a set, and what to monitor on an ongoing basis rather than a one-time setup.
MX: does mail even route correctly
Start with the basic check, because it’s the one most likely to already be right and least likely to silently drift. An MX (Mail Exchanger) record tells the internet which server accepts mail for your domain — for a Microsoft 365 domain, this is normally a single record pointing to <domain-key>.mail.protection.outlook.com, created automatically when the domain is added and verified in the admin centre. Microsoft’s own guidance is explicit that a domain enrolled in Exchange Online should have exactly one MX record — more than one, or a stale record left over from a previous email provider, is a common and avoidable cause of inbound mail routing incorrectly or getting rejected.
MX rarely breaks on its own once it’s set up correctly. Where it does go wrong is during a change: migrating providers, adding a new subdomain for a specific sending purpose, or restructuring DNS at a registrar — any of which can leave an old MX record in place alongside the new one. Checking it costs nothing and confirms the foundation the rest of this article builds on: mail is actually arriving.
SPF, DKIM, and DMARC: the layer that determines trust
MX gets mail routed. SPF, DKIM, and DMARC determine whether the mail that arrives is trusted — and it’s worth being precise about how the three relate, because they don’t work independently.
SPF (Sender Policy Framework) publishes a DNS TXT record listing which mail servers are authorised to send on behalf of your domain. For a standard Microsoft 365 setup, that’s a single include:spf.protection.outlook.com entry alongside anything else that legitimately sends as your domain — a marketing platform, a CRM, an on-premises server in a hybrid setup. SPF fails closed in a specific, common way: if a domain already has an SPF record from a previous provider and someone adds a second, separate SPF record for Microsoft 365 instead of merging the two, the domain ends up with two SPF TXT records — which breaks SPF validation for everyone, not just the newer sender. There should only ever be one.
DKIM (DomainKeys Identified Mail) works differently — it’s covered in full detail, including the specific failure mode that matters most for signature and disclaimer tools, in Why Adding an Email Signature Can Break DKIM and S/MIME. The short version for this article: Microsoft 365 signs outbound mail using a domain-specific private key, and the receiving mail system verifies that signature against a public key published as a DNS CNAME record. If anything in the signed content changes after signing, the signature breaks.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the layer that ties the other two together, and it’s the one most organisations get technically “on” without actually getting any protection from it. DMARC doesn’t authenticate anything by itself — it uses the result of SPF and DKIM checks and adds one further requirement: that the domain which passed SPF or DKIM actually matches the domain in the visible From address (a check called alignment). A message can pass SPF, pass DKIM, and still fail DMARC if the aligned domain doesn’t match what the recipient sees as the sender — exactly the kind of mismatch a spoofed or lookalike-domain email relies on, and the technical counterpart to the human-layer signal covered in Consistent Email Signatures as a Phishing and BEC Defence: that article covers what a consistent signature does for the person reading a suspicious email, this one covers what stops the spoofed email from looking authenticated in the first place.
The gap almost nobody notices: p=none
Here’s the detail that makes DMARC different from SPF and DKIM in practice: publishing a DMARC record doesn’t, by itself, do anything to stop spoofed mail. A DMARC TXT record includes a policy value — p=none, p=quarantine, or p=reject — that tells receiving mail systems what to actually do with a message that fails. Microsoft’s own recommended rollout starts every domain at p=none: no enforcement action, purely monitoring, while the aggregate reports (rua=) show which of your legitimate mail sources are and aren’t currently passing. That’s the correct way to start — moving straight to enforcement without first seeing what’s in your own mail stream risks blocking legitimate email, sometimes in significant volume. But it means a domain can have a DMARC record published, technically “have DMARC,” and provide zero actual anti-spoofing protection, because nothing is enforcing anything. This is the single most common gap in domain configurations that otherwise look complete on paper — DMARC set up once, at p=none, during initial migration, and never revisited.
The rollout from there is deliberately gradual: p=none → monitor the aggregate reports and fix any legitimate mail sources that show up failing → p=quarantine (failing mail gets sent to junk rather than delivered or rejected outright) → p=reject (failing mail is refused). Microsoft’s guidance also supports a pct= value to enforce the policy against only a percentage of failing mail at a time — 10%, 25%, 50% — for organisations that want to de-risk the final move to full enforcement further still. There’s no fixed timeline for the whole rollout; it depends on how much non-obvious mail infrastructure sends as your domain (marketing platforms, help desk tools, invoicing software) and how long it takes to either bring each one into alignment or explicitly exclude it. Reading the aggregate reports themselves is the unglamorous but unavoidable part of this — the raw XML is not pleasant to read by hand, and most organisations either build light automation around it or use one of the DMARC reporting services dmarc.org’s own resources point to.
Sender reputation: the layer authentication doesn’t fix
SPF, DKIM, and DMARC establish that a message genuinely came from your domain and wasn’t altered in transit. They say nothing about whether receiving mail systems actually trust your domain to send wanted mail — that’s a separate, harder-to-audit signal called sender reputation, built up over time from delivery patterns: bounce rates, spam-complaint rates, and how consistently your sending volume and behaviour look like a legitimate organisation rather than a compromised account or a new spam source.
A domain can be fully, correctly authenticated — SPF, DKIM, and DMARC all passing, p=reject and enforcing — and still land in Junk, because reputation is evaluated on top of authentication, not instead of it. Two places worth knowing about for checking it directly: Google Postmaster Tools, Google’s own dashboard for domains sending to Gmail addresses, showing spam-rate and delivery data Google itself uses; and Microsoft’s Smart Network Data Services (SNDS), the equivalent for mail sent to Outlook.com and Hotmail addresses. One honest caveat on SNDS specifically: Microsoft has been actively changing how access to it works recently, including how automated data-access links are issued and renewed — if you’re setting it up for the first time, start from Microsoft’s current sender-support guidance rather than an old bookmark or a third-party walkthrough that may already be describing a superseded process.
Reputation is also the part of this that authentication alone genuinely cannot fix. A newly configured domain with perfect SPF/DKIM/DMARC can still see poor initial deliverability simply because it has no sending history yet — reputation has to be built, not just configured, which is a useful thing to set expectations around before a domain migration rather than after.
Why this is infrastructure, not a setup step
The pattern across all of this is the same: MX, SPF, DKIM, and DMARC get configured once, typically as part of a Microsoft 365 migration project, ticked off, and rarely revisited — even though each one can silently regress. A new marketing tool starts sending as your domain without being added to SPF. A DMARC policy sits at p=none for years past the point anyone intended it to stay there. A subdomain gets stood up for a new purpose without its own DKIM and DMARC configuration. None of these show up as an outage; they show up as a slow deliverability decline, or as a phishing email using your domain that a customer reports, at which point the organisation is auditing under pressure rather than on a schedule. NCSC’s own guidance on email security and anti-spoofing frames the DMARC rollout the same way: a staged, monitored process, not a one-off box to tick.
It’s also worth flagging, without repeating the full detail, why this sits next to signature and disclaimer tooling on this site specifically: content inserted into a message after it’s been DKIM-signed — including some third-party email signature and disclaimer services that route mail out to apply content and back — can quietly invalidate that signature, which is exactly the mechanism covered in full in Why Adding an Email Signature Can Break DKIM and S/MIME. Domain health and signature deployment architecture aren’t the same problem, but the tools an organisation deploys for one can directly undermine the other if the routing isn’t understood — a point worth carrying into any tool evaluation, not just this article.
A practical monitoring checklist
Given how easily each layer can look “done” while quietly failing, the practical answer is a recurring check rather than a one-time project:
- MX — confirm there’s exactly one MX record, and it points where it should.
- SPF — confirm there’s exactly one SPF TXT record, and every legitimate sending source (Microsoft 365, marketing platform, CRM, invoicing tool, any on-premises server) is actually included in it.
- DKIM — confirm signing is enabled and the CNAME records are valid, and separately, test whether anything in your mail flow (including any signature or disclaimer tool) is invalidating the signature after the fact.
- DMARC — check the current policy value. If it’s
p=none, that’s not a finished state — it’s the first step of a rollout that should be actively progressing towardsp=quarantineand thenp=reject, monitored via the aggregate reports along the way. - Sender reputation — periodically check Google Postmaster Tools and Microsoft’s SNDS (or their current equivalents) rather than waiting for a delivery problem to prompt it.
Treat this as a standing item revisited on a schedule — quarterly is a reasonable default for most organisations — rather than something checked once during a migration and never again, in the same spirit as the broader IT-owned checklist in How to Manage Email Signatures Across a Company: domain health and signature deployment are different pieces of infrastructure, but they’re both things IT sets up once and needs a reason to revisit. It’s also worth knowing this list doesn’t stop at DMARC: enforcing DMARC at p=reject (or p=quarantine) is the direct technical prerequisite for BIMI, the standard that lets your organisation’s logo appear next to your emails in supporting inboxes — a separate topic in its own right, covered in full in BIMI Explained.
Frequently asked questions
What’s the difference between SPF, DKIM, and DMARC?
SPF lists which mail servers are authorised to send as your domain. DKIM cryptographically signs outbound messages so tampering in transit can be detected. DMARC ties the two together by requiring that whichever one passes (SPF or DKIM) also matches the domain the recipient actually sees in the From address, and tells receiving mail systems what to do — nothing, quarantine, or reject — when that fails.
Why would a domain with SPF, DKIM, and DMARC all “configured” still be vulnerable to spoofing?
The most common reason is that the DMARC policy is published at p=none, which is monitoring-only and takes no enforcement action against mail that fails. Microsoft’s own recommended rollout starts every domain at p=none deliberately, to avoid blocking legitimate mail before it’s been reviewed — but a domain that never progresses past that starting point has DMARC published without DMARC actually protecting anything.
How do I read a DMARC aggregate report?
Aggregate reports (sent to the address specified in a DMARC record’s rua= value) arrive as XML attachments showing which IP addresses and services sent mail as your domain, and whether each passed or failed SPF, DKIM, and alignment. They’re not pleasant to read by hand at any real mail volume — most organisations use a dedicated DMARC reporting service, or build light automation, to turn them into something reviewable. The goal is identifying every legitimate mail source before moving the policy from p=none towards enforcement.
What’s the difference between email authentication and sender reputation?
Authentication (SPF, DKIM, DMARC) proves a message genuinely came from your domain and wasn’t altered. Sender reputation is a separate signal receiving mail systems build up over time from your actual sending behaviour — bounce rates, spam complaints, sending patterns — and it sits on top of authentication, not instead of it. A domain can be fully authenticated and still have poor deliverability due to weak reputation, which is why it’s worth checking directly via tools like Google Postmaster Tools and Microsoft’s SNDS rather than assuming authentication alone is sufficient.
Can an email signature or disclaimer tool break DKIM?
Yes, if it modifies message content after Microsoft 365 has already applied its DKIM signature — a specific, well-documented failure mode covered in full in Why Adding an Email Signature Can Break DKIM and S/MIME. It’s a good example of why domain-health monitoring and signature deployment architecture aren’t separate concerns in practice, even though they’re separate topics.
SigHQ is building an add-in-first email signature management tool for Microsoft 365 organisations of 50–250 employees — signatures applied in Outlook at compose time, without email routing through third-party infrastructure. Join the waitlist to follow progress.