SPF, DKIM and DMARC explained: stop criminals sending email as you

SPF, DKIM and DMARC are three records you publish for your email domain so that other email systems can check whether a message really came from you. SPF lists the services allowed to send your email, DKIM adds a digital signature to every message, and DMARC tells receiving systems what to do with messages that fail those checks, and sends you reports. With all three in place and a DMARC policy of “reject”, criminals can’t send email that appears to come from your exact address. Without them, anyone can.

Why your domain needs protecting

Email was never designed to check who sent a message. Microsoft’s own documentation points out that standard internet email makes no attempt to confirm that the sender is who they say they are. So a criminal can send an email showing your address in the From line, to your clients or your own staff, asking for an invoice to be paid into a new bank account. Without the right records, the receiving system has no way to tell it’s fake.

There’s a second reason: getting your own email delivered. Since February 2024 Google has required anyone sending more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, and Microsoft has brought in similar rules for high-volume senders to Outlook.com. Most small businesses don’t send that much, but the direction is clear: email that can’t be authenticated is increasingly treated as suspicious.

SPF: who is allowed to send as you

SPF (Sender Policy Framework) is a single text record in your domain’s DNS that lists the services allowed to send email for your domain. For a business that only sends email from Microsoft 365, Microsoft’s recommended record is:

v=spf1 include:spf.protection.outlook.com -all

The -all at the end tells receivers that anything not listed isn’t authorised. Most SPF problems come from three things:

• Forgotten senders. Your accounting software emailing invoices, a marketing tool, your website’s contact form and the scan-to-email on your copier may all send as your domain.
• More than one SPF record. You’re only allowed one per domain, and two make SPF fail.
• Too many lookups. SPF fails if checking the record takes more than 10 DNS lookups, which is easy to reach once several services are added.

SPF has limits, too. It checks a hidden sending address rather than the From address people see, and it breaks when email is forwarded. That’s why it isn’t enough on its own.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) signs each message you send with a private key. The matching public key sits in your DNS, so the receiving system can check the signature and confirm the message wasn’t altered on the way. Unlike SPF, a DKIM signature usually survives forwarding.

In Microsoft 365 there’s a catch. Microsoft says no DKIM signing happens for your own domain until it’s set up: someone has to publish two records, named selector1 and selector2, with your DNS provider and then switch signing on. It’s an easy step to miss when Microsoft 365 is first set up.

DMARC: the policy and the reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together. It’s a text record published at _dmarc.yourdomain.co.uk, and it does three jobs:

• It checks alignment. A message passes DMARC only if SPF or DKIM passes for the same domain as the From address people see. This is what stops a criminal passing SPF with their own domain while showing yours.
• It sets a policy for messages that fail: p=none (take no action, just report), p=quarantine (treat as suspicious, usually the junk folder) or p=reject (refuse the message).
• It asks for reports. Receiving systems send regular summaries of who is sending email as your domain to the address in the rua tag, so you can see what’s genuine before you tighten the policy.

DMARC was first published in 2015 as RFC 7489. In May 2026 the IETF republished it on its standards track as RFC 9989, which replaces the original. Records still begin v=DMARC1, and the three policies described here are unchanged.

Why “p=none” isn’t protection

A DMARC record with p=none is a sensible first step, because the reports show you every service sending as your domain. But it asks receivers to take no action, so spoofed email still gets delivered. The standard itself calls this monitoring mode. The NCSC is clear that a policy of “reject” on all your domains is the best way to stop your email being spoofed.

How to get to “reject” without blocking real email

1. List everything that sends email as you: Microsoft 365, plus every app, website and device.
2. Fix SPF so it includes all of them, in one record, within the lookup limit.
3. Turn on DKIM in Microsoft 365, and in every other service that can sign with your domain.
4. Publish DMARC at p=none with reports going to a dedicated mailbox or a reporting service, and read them.
5. Move to p=quarantine once genuine email is passing, then to p=reject. The NCSC says many organisations move from quarantine to reject after about three months, and recommends watching reports closely for at least two weeks after the change.
6. Protect domains you don’t send from. Spare or old domains can be spoofed too. For those, Microsoft recommends an SPF record of v=spf1 -all and a DMARC record of v=DMARC1; p=reject;, and a DMARC record for your onmicrosoft.com domain if you don’t use it for email.
7. Keep checking. Every new service that sends email for you needs adding before it goes live.

Check your domain for free

The free security snapshot from AlphaSec, our security brand, checks your SPF, DKIM and DMARC set-up using public records only, along with your website certificate, website software and domain renewal. You get a one-page report showing where you stand, and nothing has to be installed.

How we can help

We can set up SPF, DKIM and DMARC across all your domains, take them to “reject” in stages and keep an eye on the reports so genuine email keeps flowing. See our email security service, or read about Microsoft 365 security and our wider cyber security work. Spoofing is one way in; stolen passwords are another, which is where passkeys help. If you’d like us to look at your domain, book a call.

Sources

• Email security and anti-spoofing, NCSC.
• Spoof emails being rejected, NCSC.
• How email authentication works in Microsoft 365, Microsoft Learn.
• Set up SPF to identify valid email sources for your Microsoft 365 domain, Microsoft Learn.
• How to use DKIM for email in your custom domain, Microsoft Learn.
• Set up DMARC to validate email in Microsoft 365, Microsoft Learn.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), March 2015.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF, May 2026.
• Email sender guidelines, Google.
• Fix NDR error 550 5.7.515 in Outlook.com, Microsoft Support.