SPF, DKIM and DMARC: How We Set Up Email Authentication on Microsoft 365

Today we spent an afternoon putting SPF, DKIM and DMARC on all seven of the email domains we run through Microsoft 365. Before we started, only three had DMARC, DKIM was switched off on every one of them, and one domain still gave sending permission to a server we no longer use. None of it had stopped our email working, which is exactly why it had been left. But the big email providers now check these records properly, and the same day we saw what happens when the checks fail.

What went wrong today

A club we help has a Gmail account that automatically forwards its email to a volunteer's BTconnect address. Since late October, 48 of those forwarded messages had bounced, including enquiries from members of the public. The person they were meant for never received them.

The bounces gave the reason as error 450 4.7.26. BTconnect email now runs on Microsoft's servers, and Microsoft has a rule: an email arriving over an IPv6 connection must pass either SPF or DKIM. These forwards arrived over IPv6. SPF failed because Google's servers are not on the original sender's list of approved senders. Forwarding does not always break DKIM, but on these messages it did not pass either, because the signature was missing or no longer matched. A 450 is a "try again later" refusal, so Gmail kept retrying, then gave up and sent each one back.

Nothing was wrong with the club's website or its Gmail account. Automatic forwarding is fragile now that providers check these records. The fix is to stop relying on the forward: have the volunteer read the Gmail account directly, or forward to an address that accepts it. It is worth checking your own business for the same thing, especially if anyone forwards work email to a personal or old ISP address.

The three records in plain English

• SPF is a list, published in your domain's DNS, of the servers allowed to send email as you. If a server not on the list sends an email claiming to be from you, the check fails, or the email is marked as suspicious, depending on how the record ends.
• DKIM is a signature added to each email you send. The receiving server checks it against a key in your DNS. If the signature matches, the email was signed by your domain and was not changed on the way.
• DMARC ties the two together. An email passes if either SPF or DKIM passes for the same domain as the From address, and the record tells other servers what you would like done with email that fails: nothing, junk or reject. It can also ask for reports, so you can see who is sending email in your name.

Gmail and Yahoo tightened their rules in 2024, and Microsoft followed for Outlook and Hotmail in 2025. Large senders, which Gmail and Microsoft define as around 5,000 emails a day, must have all three. Smaller senders need at least SPF or DKIM, and email without them is more likely to land in junk or be refused, as the club found. They also make it harder for a fraudster to send email that looks like it came from your domain, which is how many fake invoice scams start.

Setting it up on Microsoft 365

Our DNS is on Cloudflare, but the steps are the same with any DNS provider.

SPF. For a business that only sends through Microsoft 365, the record is a single TXT record on the domain: v=spf1 include:spf.protection.outlook.com -all. If you also send from a website, a newsletter service or an accounts package, they may need adding too: follow each service's own setup instructions, and keep it to one SPF record per domain. One of ours still listed an old server and ended in ?all, which means "no opinion" and gives very little protection. We replaced it with the line above.

DKIM. In the Microsoft Defender portal, go to Email and collaboration, then Policies and rules, Threat policies, Email authentication settings and the DKIM tab. Click a domain and Microsoft shows two CNAME records to add to your DNS. Add both, wait, then switch the domain to Enabled.

DMARC. This is a TXT record named _dmarc. We started with v=DMARC1; p=none, which asks other servers not to block or junk anything because of DMARC. That is the safe first step, because if you have missed a service that sends email for you, DMARC will not stop its email while you find out. We have not added a reporting address yet, which is the usual next step.

Your situation may be slightly different. ask a question below ↓ and our editorial team will reply with our advice.

The problems we hit

Microsoft said the records were missing when they were not. After we added the DKIM records for four domains, Microsoft kept showing "CnameMissing" and would not let us switch them on. Our records were correct. The problem was on Microsoft's side: the records point to keys that Microsoft publishes, and for these domains it had not created them yet. Later the same day all four went through. If you see this, check your records carefully, then give it time before changing anything.

The records do not all look the same. On our older domains, the DKIM records point to an address ending in onmicrosoft.com. On newer ones, Microsoft now gives a different style of address ending in dkim.mail.microsoft. Many guides only show the older style, so if yours looks different, copy exactly what Microsoft shows you rather than what a guide says.

Cloudflare's proxy broke a record. Microsoft flagged one domain with "possible service issues" because its autodiscover record, which helps Outlook find your mailbox, was missing. It was not missing. It had been set to Cloudflare's orange cloud, so Microsoft saw Cloudflare's addresses instead of its own. Any CNAME that Microsoft gives you, such as autodiscover and the DKIM records, should be set to DNS only, the grey cloud.

An old domain was still listed. We found a domain in Microsoft 365 that we no longer use for email. Rather than set it up, we removed it.

Checking it works

The quickest test is to send an email from each domain to a Gmail address, open it, and choose "Show original" from the menu. Gmail lists SPF, DKIM and DMARC with a result next to each, and you want PASS on all three. Test anything else that sends as you, such as a website form, in the same way. In Outlook you can view the message headers and look for the Authentication-Results line.

We have left DMARC on p=none for now. Once we are sure every service that sends as us is passing, the next step is p=quarantine, which asks receiving servers to put email that fails DMARC in junk. That should catch most fake email claiming to be from us, which is why it is worth getting right first. If you are working towards Cyber Essentials, sorting out these three records is worth doing at the same time.