Email Domain Health: MX, SPF, DKIM, DMARC, Sender Reputation

Q: How do I read a DMARC aggregate report?

Aggregate reports go to the address in your DMARC record's rua= value. They arrive as XML attachments. They show which IP addresses and services sent mail as your domain, and whether each passed or failed SPF, DKIM and alignment. At any real mail volume they are hard to read by hand. Most organisations use a DMARC reporting service, or build light automation, to turn them into something reviewable. The aim is to find every legitimate mail source before moving the policy from p=none towards enforcement.

TL;DR: MX, SPF, DKIM and DMARC are four settings in your domain’s DNS (its public address book) that decide whether your organisation’s email is trusted, not just delivered. Most IT admins set them up once, often during a move to Microsoft 365, and never look again. That is a problem. A domain can have all four “configured” and still fail quietly. The usual cause is a DMARC record published at p=none, which only monitors and enforces nothing. This article explains what each check does, why they only work as a set, and what to monitor on a regular basis instead of once.

MX: does mail reach you?

Start with the basic check. It is the one most likely to be right already, and the least likely to drift. An MX (Mail Exchanger) record tells the internet which server accepts mail for your domain. For a Microsoft 365 domain, this is normally one record pointing to <domain-key>.mail.protection.outlook.com. It is created automatically when you add and verify the domain in the admin centre. Microsoft’s guidance says a domain using Exchange Online should have exactly one MX record. A second record, or an old one left from a previous email provider, is a common and avoidable reason for inbound mail going the wrong way or being rejected.

MX rarely breaks by itself once it is right. It goes wrong during a change, such as moving providers, adding a subdomain for a new sending purpose, or reorganising DNS at your registrar. Any of these can leave an old MX record next to the new one. Checking costs nothing and confirms the base for everything else here: mail is arriving.

SPF, DKIM and DMARC: the checks that decide trust

MX gets mail delivered. SPF, DKIM and DMARC decide whether the mail that arrives is trusted. The three do not work on their own, so it helps to see how they relate.

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers may send on behalf of your domain. A standard Microsoft 365 setup needs one include:spf.protection.outlook.com entry, next to anything else that legitimately sends as your domain. That might be a marketing platform, a CRM, or an on-premises server in a hybrid setup. SPF often fails in one particular way. Say your 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 now has two SPF TXT records, which breaks SPF checks for every sender, not just the new one. There must only ever be one.

DKIM (DomainKeys Identified Mail) works differently. Why Adding an Email Signature Can Break DKIM and S/MIME covers it in full, including the failure that matters most for signature and disclaimer tools. In short: Microsoft 365 signs outgoing mail with a private key for your domain. The receiving mail system checks 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) ties the other two together. It is the one most organisations switch on without getting any protection from it. DMARC does not check anything by itself. It uses the results of the SPF and DKIM checks and adds one more rule: the domain that passed SPF or DKIM must match the domain in the visible From address. This check is called alignment. A message can pass SPF, pass DKIM and still fail DMARC if the aligned domain does not match the sender the recipient sees. Spoofed and lookalike-domain emails depend on exactly that mismatch.

This is the technical side of the human signal in Consistent Email Signatures as a Phishing and BEC Defence. That article covers what a consistent signature does for a person reading a suspicious email. This one covers what stops the spoofed email looking authenticated in the first place.

The gap almost nobody notices: `p=none`

Here is what makes DMARC different from SPF and DKIM in practice. Publishing a DMARC record does not, by itself, do anything to stop spoofed mail. The record includes a policy value, p=none, p=quarantine or p=reject. It tells receiving mail systems what to do with a message that fails.

Microsoft’s recommended rollout starts every domain at p=none. That means no action is taken. It only monitors, while the aggregate reports (rua=) show which of your legitimate mail sources pass and which fail. That is the right way to start. If you move straight to enforcement without seeing what is in your own mail, you risk blocking legitimate email, sometimes a lot of it.

But it means a domain can have a DMARC record, so it technically “has DMARC”, and still give no protection against spoofing, because nothing is enforced. This is the most common gap in domains that look complete on paper. DMARC was set up once, at p=none, during the first migration, and nobody went back.

The rollout from there is gradual:

p=none: watch the aggregate reports and fix any legitimate mail sources that fail.
p=quarantine: failing mail goes to junk instead of being delivered or rejected.
p=reject: failing mail is refused.

Microsoft’s guidance also supports a pct= value, which applies the policy to only a share of failing mail, such as 10%, 25% or 50%. This lowers the risk of the final move to full enforcement even more. There is no fixed timeline. 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 bring each one into alignment or deliberately exclude it.

Reading the aggregate reports is the dull but unavoidable part. The raw XML is not pleasant to read by hand. Most organisations either build light automation around it or use one of the DMARC reporting services that dmarc.org’s own resources point to.

Sender reputation: the layer authentication does not fix

SPF, DKIM and DMARC show that a message really came from your domain and was not altered on the way. They say nothing about whether receiving mail systems trust your domain to send wanted mail. That is a separate signal called sender reputation. It is built up over time from delivery patterns: bounce rates, spam-complaint rates, and whether your sending volume and behaviour look like a real organisation and not a hacked account or a new spam source.

A domain can pass everything, with SPF, DKIM and DMARC all passing and p=reject enforced, and still land in Junk. Reputation is judged on top of authentication, not instead of it. There are two places to check it directly:

Google Postmaster Tools is Google’s dashboard for domains that send to Gmail addresses. It shows the spam-rate and delivery data Google itself uses.
Microsoft’s Smart Network Data Services (SNDS) is the equivalent for mail sent to Outlook.com and Hotmail addresses.

One caution about SNDS. Microsoft has recently been changing how access to it works, including how automated data-access links are issued and renewed. If you are setting it up for the first time, start from Microsoft’s current sender-support guidance. Do not use an old bookmark or a third-party walkthrough, which may describe a process that has been replaced.

Authentication alone cannot fix reputation. A newly set up domain with perfect SPF, DKIM and DMARC can still see poor delivery at first, simply because it has no sending history. Reputation has to be built, not just configured. It is worth setting that expectation before a domain migration, not after.

Why this is infrastructure, not a setup step

The same pattern runs through all of this. MX, SPF, DKIM and DMARC get configured once, usually during a Microsoft 365 migration, then ticked off and rarely revisited. Each one can quietly stop working:

A new marketing tool starts sending as your domain without being added to SPF.
A DMARC policy sits at p=none for years after anyone meant it to.
A subdomain is set up for a new purpose without its own DKIM and DMARC settings.

None of these shows up as an outage. They show up as a slow drop in delivery, or as a customer reporting a phishing email that used your domain. By then you are auditing under pressure instead of on a schedule. The NCSC’s guidance on email security and anti-spoofing frames DMARC the same way: a staged, monitored process, not a box to tick once.

There is also a reason this sits next to signature and disclaimer tools on this site. Content added to a message after it has been DKIM-signed can quietly break that signature. Some third-party signature and disclaimer services do this, because they route mail out to add content and then back. Why Adding an Email Signature Can Break DKIM and S/MIME covers the mechanism in full. Domain health and signature design are different problems. But the tools you deploy for one can undermine the other if you do not understand the routing. Keep that in mind in any tool evaluation.

A practical monitoring checklist

Each layer can look “done” while quietly failing. So the answer is a recurring check, not a one-off project:

MX: confirm there is exactly one MX record and that it points where it should.
SPF: confirm there is exactly one SPF TXT record, and that every legitimate sending source is in it. That includes Microsoft 365, your marketing platform, CRM, invoicing tool and any on-premises server.
DKIM: confirm signing is on and the CNAME records are valid. Separately, test whether anything in your mail flow, including a signature or disclaimer tool, breaks the signature after the fact.
DMARC: check the current policy value. If it is p=none, that is not a finished state. It is the first step of a rollout that should be moving towards p=quarantine and then p=reject, with the aggregate reports watched along the way.
Sender reputation: check Google Postmaster Tools and Microsoft’s SNDS (or their current equivalents) from time to time. Do not wait for a delivery problem to prompt it.

Treat this as a standing item and revisit it on a schedule. Quarterly is a reasonable default for most organisations. The same applies to the signature rollout covered in Centralised Email Signatures in Microsoft 365: Complete Guide. Domain health and signature deployment are different pieces of infrastructure, but IT sets both up once and needs a reason to revisit them.

The list does not stop at DMARC. Enforcing DMARC at p=reject (or p=quarantine) is the technical prerequisite for BIMI, the standard that lets your logo appear next to your emails in supporting inboxes. That is a topic of its own, covered in BIMI Explained.

Frequently asked questions

How do I read a DMARC aggregate report?

Aggregate reports go to the address in your DMARC record’s rua= value. They arrive as XML attachments. They show which IP addresses and services sent mail as your domain, and whether each passed or failed SPF, DKIM and alignment. At any real mail volume they are hard to read by hand. Most organisations use a DMARC reporting service, or build light automation, to turn them into something reviewable. The aim is to find every legitimate mail source before moving the policy from p=none towards enforcement.