Most UK businesses assume that using Microsoft 365 means their email is authenticated. It does not. Buying a licence gives you a mailbox; it does not finish the setup on your own domain. Until SPF, DKIM and DMARC are all published and enforced, anyone with a laptop can send a message that appears to come from your finance director, and some of your own invoices will land in a client's junk folder.
We check this on nearly every assessment we run, and the pattern barely changes. There is an SPF record, but it is over the DNS lookup limit. DKIM is switched off. The DMARC record has been sitting at p=none since the day it was created. Each of those is a separate job, and all three need finishing.
Why this matters more in 2026 than it did two years ago
Two commercial shifts have made authentication a deliverability problem as well as a security problem. Gmail and Yahoo brought in bulk sender rules in February 2024: senders pushing more than 5,000 messages a day to Gmail addresses must have SPF, DKIM and DMARC in place, and mail that fails authentication is rejected or filtered. Microsoft's own inbound filtering weighs authentication results, sender reputation and behavioural signals before a message reaches the inbox, so a spoofed message from your domain is treated with suspicion by the same platform your customers use.
There is a UK-specific tool worth knowing about. The NCSC runs a free email security check that reports on the SPF, DKIM, DMARC and TLS configuration of any domain you submit, and its guidance on email security and anti-spoofing is written for people without a security team. It takes a minute and gives you an honest picture before you change anything. We run that check on every client domain at the start of an engagement because it stops the conversation drifting into opinions.
One point needs to be clear. Cyber Essentials v3.2 does not require DMARC. The scheme covers firewalls, secure configuration, patch management, user access control and malware protection. If a certificate is your only reason for doing this work, you will stop halfway. Do it because invoice fraud and impersonation from your own domain are a live risk for any business that pays suppliers by bank transfer.
How the three records work together
| Record | What it actually does | Where it lives | What usually goes wrong |
|---|---|---|---|
| SPF | Lists the servers allowed to send mail for your domain | TXT record at the domain root | More than one record, or more than 10 DNS lookups |
| DKIM | Signs each message so the recipient can check it was not altered in transit | CNAME records for two selectors under _domainkey | Never switched on in the tenant at all |
| DMARC | Ties SPF and DKIM to the visible From address and sets what happens when both fail | TXT record at _dmarc | Left at p=none and never monitored |
The detail that catches people out is alignment. DMARC does not simply ask whether SPF and DKIM passed; it asks whether the domain that passed matches the domain in the From line your customer actually sees. If an invoicing system sends as yourdomain.com but uses a different envelope sender, SPF can pass and DMARC still fails. That is why the inventory step below matters more than the DNS records themselves. Microsoft's own DMARC setup guidance walks through the same alignment points.
Step 1: fix the SPF record
You should have exactly one SPF TXT record per domain. Two records do not add up; they are treated as a permanent failure. Microsoft's required entry is include:spf.protection.outlook.com, and anything else that sends on your behalf needs adding: your marketing platform, your CRM, your booking system, your accounts package.
The DNS lookup limit is real
SPF allows a maximum of 10 DNS lookups. Every include, a, mx, ptr or exists mechanism counts towards it. A typical SME ends up with four or five after adding a marketing tool and a CRM, which is fine. Where it breaks is when an agency layers in a platform that itself pulls in several includes, and the record silently stops working for everyone. There is no warning when this happens. Mail simply starts failing.
Two more decisions matter here. Use -all rather than ~all once you are confident your list is complete, because ~all tells the world to be lenient with anything you did not list. And if a third party sends on your behalf from a subdomain, publish a separate record there and set sp=reject on the parent record so unauthenticated subdomains cannot be used to spoof you. Both changes take minutes in DNS and both get forgotten.
A workable single-domain record
A 40-person firm with Microsoft 365 and one marketing platform typically ends up with something close to v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all. Change the vendor, keep the shape. Check the lookup count before you publish, and recheck it every time a new tool is added.
Step 2: turn DKIM on, because it is probably off
DKIM is the part that gets skipped. Microsoft enables signing by default for newly created custom domains, which has lulled plenty of organisations into assuming it is on. Established tenants are a different story, and we still find domains in 2026 with signing disabled and no selector records in DNS.
Enabling it in Exchange Online creates two CNAME records per accepted domain, one for each selector, and you then publish those in DNS. Use 2048-bit keys rather than 1024-bit. Exchange Online supports both, and 2048-bit is the sensible default for a business with anything worth protecting. Microsoft rotates the keys for you when signing is enabled through the portal, so there is no reason to manage them by hand.
The practical test is simple. Send a message from the domain to a Gmail account, open the message headers, and look for a dkim=pass result alongside spf=pass. If DKIM is missing, check that the selector records have propagated. A professional services firm we worked with had been running with signing off for years, and their own invoices were being filed as junk at two of their largest clients. Nobody had connected the two problems, because the mailboxes themselves looked healthy.
Step 3: deploy DMARC in three stages, not one
DMARC is the policy layer, and setting it to reject on day one is how businesses break their own inbound leads. Move through the stages, and give each one enough time to collect data.
| Stage | Record | What you watch | Typical duration |
|---|---|---|---|
| Monitor | p=none with a rua reporting address | Which senders are failing SPF or DKIM alignment | Two to four weeks |
| Quarantine | p=quarantine, moving from pct=25 to pct=100 | Whether legitimate mail is being filtered | Two to four weeks |
| Enforce | p=reject | Occasional spoofing attempts reported by receivers | Steady state |
Do not stop at the first row. We have taken over tenants where p=none has been in place since 2021 and nobody has read an aggregate report in two years. That is not a DMARC deployment. It is a DNS record that has been given a reassuring name. If you publish a rua address, someone has to open the reports, and it should not be the same mailbox that receives the company's spam.
We would go further than most guides here. If an SME cannot commit to reading DMARC reports monthly, it is better to hire half a day of help to reach p=reject and then revisit the setup annually than to leave a monitoring record in place indefinitely. A permanent p=none gives you the impression of protection with none of the enforcement, and it costs you every month you leave it there.
The mistakes we see most often
Multiple SPF records for the same domain, usually after a change of provider. A forgotten sender: the booking system, the e-signature platform, the HR portal that sends password resets. Subdomains left unprotected because nobody set sp=. And DMARC reports delivered to an unmonitored mailbox, which amounts to not collecting them at all.
The most expensive one involves hardware. Multifunction devices and older line-of-business applications often send scan-to-email or system alerts through a shared mailbox using a username and password. Microsoft has announced the retirement of basic authentication for SMTP AUTH client submission, so those devices and applications need to move to OAuth or to High Volume Email. High Volume Email allows up to 50 recipients per message and a maximum message size of 10 MB, with no recipient rate limit, but it needs an Azure pay-as-you-go billing subscription attached to the tenant. Plan that work before you set p=reject, not after.
Every sender you forget is a sender that breaks the day you move to p=reject. Inventory is the whole job; the DNS records take ten minutes.
A working checklist for a UK SME
- List every system, device and service that sends email as your domain, including scans from the office printer.
- Reduce to a single SPF record per domain and keep it under 10 DNS lookups.
- Publish the selector CNAME records and enable DKIM signing at 2048-bit for every accepted domain.
- Create the _dmarc record at p=none with a reporting address a human actually reads.
- Read the first aggregate reports properly before changing the policy.
- Step to p=quarantine, then p=reject, allowing two to four weeks at each stage.
- Set sp=reject on the parent record where subdomains do not send mail.
- Run the NCSC email security check monthly and after any change to a sending system.
- Add a rule that no new marketing or payroll tool goes live without telling whoever owns DNS.
None of this is glamorous work, and that is exactly why so many tenants are half finished. The DNS changes take an afternoon. The inventory and the monitoring take discipline, and discipline is the part that gets dropped when a business is busy.
What it costs and how long it takes
For a single domain with two or three sending platforms, we budget four to six hours of Microsoft 365 consultancy spread across the monitoring window. Most of that is not DNS; it is chasing down who sends what and reading the first set of reports with someone who knows what a failing sender looks like. Businesses with multiple domains, a marketing automation platform and an on-premises application sending alerts should expect more, and should start earlier than the week before a certificate renewal. The order of work stays the same whatever the size of the tenant.
If you would rather do this yourself, the Microsoft documentation is genuinely good and the NCSC guidance assumes no security team. If your tenant also runs Copilot, finish this work first. Copilot surfaces content across your whole environment, so the same over-permissioned, unmonitored plumbing that makes spoofing possible will make an AI rollout awkward as well.
Check whether your domain is actually covered
Book an assessment and we will review SPF, DKIM, DMARC and your Microsoft 365 sending inventory, then tell you exactly what needs fixing and in what order.
Book a Microsoft 365 assessment
Written by Dan Kennedy
Managing Consultant at EJK Consultancy
Dan is a Microsoft Certified consultant with over 25 years of hands-on IT experience, specialising in Microsoft 365 migrations, SharePoint architecture, Power Automate automation and Microsoft Copilot readiness. He works directly with UK businesses to solve real workplace technology problems.