These three DNS records are free, they work, and yet the majority of UK SMB domains are either missing them or have them misconfigured. Here's the complete setup guide.
If someone can send an email that appears to come from your domain, your business has a serious problem. Not a theoretical one, a practical one. Attackers impersonating your domain can defraud your customers, trick your suppliers into paying fraudulent invoices, and damage the trust you've spent years building. It happens to UK SMBs every week.
SPF, DKIM, and DMARC are the three DNS records that prevent this. They're free to set up, they're supported by every major email platform, and they've been the industry standard for domain authentication for over a decade. And yet when we run checks on new client domains, a substantial proportion are either missing these records entirely or have them misconfigured, offering a false sense of protection that wouldn't stop a motivated attacker for five minutes.
This guide walks through every step for Microsoft 365 specifically. By the end, your domain will be properly authenticated and you'll have DMARC reports showing you exactly who is sending email on your behalf.
In slightly more technical terms:
SPF is a DNS TXT record that lists which mail servers are authorised to send email from your domain. When a receiving server gets an email claiming to be from yourcompany.co.uk, it looks up your SPF record and checks whether the sending IP is on the list. If it's not, SPF fails.
DKIM is a cryptographic signature applied to every outgoing email by your mail server. Your mail server holds the private key; the corresponding public key is published in your DNS. Receiving servers fetch the public key, verify the signature, and confirm the email genuinely came from your server and wasn't altered in transit. No private key, no valid signature.
DMARC is the policy layer. It tells receiving servers what to do when SPF or DKIM fail, nothing (p=none), send to spam (p=quarantine), or reject outright (p=reject). Critically, DMARC also sends you regular reports showing every source that's sending email using your domain name, whether legitimate or not. This visibility is invaluable.
Your M365 SPF record is straightforward. In your DNS provider (whether that's GoDaddy, Cloudflare, 123-reg, Namecheap, or your registrar's control panel), add the following TXT record:
Breaking down what this means:
v=spf1, declares this as an SPF recordinclude:spf.protection.outlook.com, authorises all Microsoft 365 sending IPs (Microsoft maintains this list, so it stays current automatically)-all, hard fail: any server not on the list is explicitly unauthorised. While testing, you can use ~all (soft fail) which marks but doesn't reject, switch to -all once you're confident your record is completeIf you send emails through services other than M365 (Mailchimp for marketing, HubSpot for CRM, Zendesk for support tickets, Xero for invoices), those services also need to be in your SPF record. Each provider will give you an include: statement to add. For example:
SPF has a hard limit of 10 DNS lookups. Each include: statement counts toward this limit, and some includes nest further includes. If you exceed 10 lookups, SPF will return a PermError and fail entirely, even for legitimate email. Use a tool like MXToolbox's SPF checker (mxtoolbox.com/SuperTool) to count your lookups before finalising your record.
Unlike SPF, DKIM for M365 requires configuration in two places: the Microsoft 365 admin portal and your DNS provider.
Microsoft will show you two records in this format:
Copy the exact values Microsoft shows you, the onmicrosoft.com component will be specific to your tenant. Add both CNAME records to your DNS provider and wait for propagation, which can take up to 48 hours (though in practice it's usually under an hour with modern providers).
Once DNS has propagated, return to the DKIM settings page in security.microsoft.com and click Enable again. Microsoft will verify the CNAMEs, confirm the records resolve correctly, and activate DKIM signing for your outbound mail. You'll see the status change to Enabled and a green tick.
The two selectors (selector1 and selector2) allow Microsoft to rotate the signing key periodically without disrupting mail flow, while one is active, the other is held in reserve. This key rotation happens automatically and is one of the advantages of using Microsoft's managed DKIM over self-managed keys.
DMARC is where most organisations make the most consequential mistakes, specifically, by jumping straight to an enforcement policy before they've checked what legitimate email is actually being sent from their domain. Don't do this. Always start with monitoring.
Add this TXT record to your DNS immediately. It collects data without interfering with any mail flow:
Leave this in place for at least two to four weeks. During this time, every receiving mail server will send daily aggregate reports (XML summaries) to the rua address you specified, showing you every IP address and domain sending email under your name, along with whether SPF and DKIM passed for each source. These reports are the intelligence you need before you enforce anything.
You can use a DMARC report parsing tool to make the XML readable, Postmark's free DMARC report viewer at dmarc.postmarkapp.com is clean and straightforward. Upload the XML files and it presents them as a readable table. Some organisations use dedicated services like Dmarcian or Valimail for ongoing visibility.
Once you've reviewed your reports and confirmed you understand all legitimate sending sources, step up to quarantine. The pct parameter lets you apply the policy to a percentage of failing messages first, useful for a gradual rollout:
Increase pct to 50, then 100 over subsequent weeks as you confirm there are no legitimate mail flows being incorrectly quarantined.
This is the goal. At p=reject, any email failing DMARC is outright rejected by the receiving server, it doesn't land in spam, it doesn't reach the recipient at all. This is full spoofing protection for your domain:
p=, the policy: none (monitor only), quarantine (send to spam), or reject (block entirely)pct=, percentage of failing messages to apply the policy to; defaults to 100 if omitted. Use lower values during phased rolloutrua=, destination for aggregate reports (daily XML summaries). Essential, this is your visibility into the domain's mail ecosystemruf=, destination for forensic reports (individual failure messages with headers). More granular but generates higher volume. Not all providers send thesesp=, subdomain policy; controls what happens to mail from subdomains of your domain. Add sp=reject to prevent subdomain spoofing (e.g. mail.yourdomain.co.uk) when you're at full enforcementWe see these consistently across new client environments. Avoid them.
p=reject without reviewing DMARC reports first. You almost certainly have legitimate sending sources you've forgotten about, a CRM that sends automated follow-ups, an invoice system, an HR platform, a helpdesk tool. These will all fail DMARC if they're not in your SPF record and don't sign with DKIM. Start with p=none, read the reports, fix the gaps, then escalate.include: can chain to further lookups. Go over 10 total and your SPF record returns a permanent error, which means SPF fails for everything, including your legitimate M365 mail. Use MXToolbox to count your lookups before deploying.yourdomain.co.uk applies to that domain. Subdomains inherit the policy only if you explicitly set sp=. Without it, someone could spoof billing.yourdomain.co.uk and bypass your DMARC policy.Don't rush to p=reject. Organisations that jump straight to reject regularly break legitimate mail flows from third-party tools they forgot about, finance software, HR platforms, CRM systems. The damage is invisible until a supplier calls asking why they haven't received your invoices for three weeks. Start with p=none, monitor for two to four weeks, then escalate.
Use these to check your records are configured correctly after publishing:
mxtoolbox.com/SuperTool), check SPF, DKIM, DMARC, and count SPF lookups. The most comprehensive free tool available.toolbox.googleapps.com/apps/checkmx.v=spf1 include:spf.protection.outlook.com -all (plus any third-party includes)_dmarc with p=none and an rua report addressp=quarantine; pct=25, then pct=100, then p=reject over subsequent weekssp=reject to your final DMARC record to cover subdomainsWant this set up properly without spending your afternoon in DNS panels?
KAVIX configures and monitors SPF, DKIM, and DMARC for all clients, including ongoing report review and escalation from p=none through to p=reject. We'll also audit your third-party senders and make sure nothing legitimate breaks in the process. Contact us to get it done right.