SPF, DKIM and DMARC Explained: A Guide for UK Businesses

Anyone can send an email that claims to come from your domain. That is not a flaw in your setup. It is how email was built.

SPF, DKIM and DMARC are the three DNS records that fix this. Together they let receiving mail servers check whether a message really came from you, and tell them what to do when it did not.

This guide explains what each one does how they work together, and how to set them up without accidentally blocking your own invoices.

Why email needs authentication at all

The protocol that carries email, SMTP, was first published in 1982 (RFC 821). It has no built-in way to confirm who sent a message. The “From” address works much like the return address on an envelope: you can write whatever you like.

Criminals rely on that. Phishing remains the most common type of cyber attack against UK businesses, experienced by 38% of businesses in the last year, according to the government’s Cyber Security Breaches Survey 2025/2026. Among organisations that had a breach or attack, 69% rated phishing as the most disruptive.

Email authentication will not stop every phishing email. It does stop criminals from sending convincing emails from your exact domain, which is the version your customers and suppliers are most likely to trust.

SPF, DKIM and DMARC in one analogy

Imagine your business sends letters through a post room.

• SPF is a published list of the post offices allowed to send letters on your behalf.
• DKIM is a wax seal on each letter that only you can make, and that breaks if anyone tampers with the contents.
• DMARC is a note to every recipient’s post room explaining what to do with letters that fail those checks, and asking them to send you a report.

SPF and DKIM do the checking. DMARC ties the results to the address your recipient actually sees, and turns them into a policy.

What is SPF?

SPF (Sender Policy Framework) lets you publish a list of the servers and services allowed to send email for your domain. The NCSC describes it as a way to publish the IP addresses that should be trusted for your domain (NCSC email security guidance). The current standard is RFC 7208.

How SPF works

When a message arrives, the receiving server looks up the SPF record for the sending domain. It then checks whether the server that delivered the message is on the list. If it is, SPF passes. If it is not, SPF fails.

A typical SPF record for a business using Microsoft 365 looks like this:

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

The include part authorises Microsoft’s mail servers. The -all at the end tells receivers that anything else is not authorised. A softer ~all means “probably not authorised”, which is common while you are still auditing your senders.

SPF’s limitations

SPF has two well-known weak spots. First, it checks the hidden “envelope” sender used by mail servers, not the From address your recipient sees. Second, it usually breaks when an email is forwarded, because the forwarding server is not on your list.

The standard also caps SPF at 10 DNS lookups per check (RFC 7208, section 4.6.4). Each include counts, and so do the includes nested inside it. Add enough marketing platforms, CRMs and helpdesk tools and you can exceed the limit without noticing, at which point SPF fails for everything.

What is DKIM?

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The NCSC explains that it lets you cryptographically sign your email to show it came from your domain. The standard is RFC 6376.

How DKIM works

Your mail service holds a private key and signs each outgoing message with it. You publish the matching public key in your DNS. The receiving server fetches that public key and uses it to check the signature.

If the signature checks out, two things are proven. The message was signed by someone holding your private key, and the signed parts of the message have not changed in transit.

You rarely write a DKIM record by hand. Microsoft 365, Google Workspace and most email platforms generate the key and give you a record to publish. It sits at a “selector” address such as selector1._domainkey.yourdomain.co.uk.

Why DKIM matters alongside SPF

Because the signature travels with the message, DKIM usually survives forwarding. The NCSC highlights this as its key advantage over SPF. In practice, DKIM is often what keeps legitimate mail passing when SPF cannot.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It tells receiving servers what to do with email that claims to be from you but fails authentication. It also asks them to send you reports, so you can see who is sending email using your domain.

Alignment: the part most people miss

DMARC does not just ask “did SPF or DKIM pass?” It asks whether the domain that passed matches the domain in the visible From address. This is called alignment.

Here is why it matters. Say your newsletter platform sends email from its own servers. SPF might pass, but for the platform’s domain, not yours. Without alignment, a scammer could do the same trick. With DMARC, that message only passes if SPF or DKIM passes for a domain that matches yours.

The fix is usually simple: set up the platform to sign with DKIM for your domain. Most reputable platforms walk you through this in their settings.

The three DMARC policies

A DMARC record is a TXT record published at _dmarc.yourdomain.co.uk. A starter record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.co.uk

The p= tag sets the policy. The rua= tag says where to send aggregate reports. There are three policy levels:

Policy	What receivers do with failing email	When to use it
p=none	Deliver as normal, but send you reports	At the start, while you find all your legitimate senders
p=quarantine	Send it to spam or junk	Once SPF and DKIM are working for every known sender
p=reject	Refuse it outright	The end goal, once you are confident nothing legitimate fails

The NCSC is clear that a policy of none does not prevent anyone spoofing your domain. It only gives you visibility. It describes a reject policy on all your domains as the best way to stop spoofing (NCSC: reject spoof emails).

DMARC has a new standard as of 2026

The original DMARC specification, RFC 7489, was published in 2015 as an informational document rather than a formal standard. In May 2026 the IETF replaced it with three standards-track documents: RFC 9989 for the core protocol, plus RFC 9990 and RFC 9991 for reporting.

If you already have a DMARC record, you do not need to start again. Existing records remain valid, though the pct, rf and ri tags are now deprecated and can be removed at your next DNS change (DMARCguard summary of the changes).

How SPF, DKIM and DMARC work together

Here is what happens when your accounts team sends an invoice to a customer:

1. Your mail service signs the email with your DKIM key and sends it from an approved server.
2. The customer’s mail server checks your SPF record to confirm the sending server is allowed.
3. It checks the DKIM signature against your published public key.
4. It checks your DMARC record to see whether at least one of those passes and aligns with your From address.
5. If it passes, the email is delivered. If it fails, the server follows your DMARC policy and adds the result to your next report.

Now picture a scammer sending a fake invoice from your domain. Their server is not in your SPF record, and they cannot produce your DKIM signature. With p=reject in place, the customer’s server refuses the message before anyone sees it.

Are SPF, DKIM and DMARC now required?

For many senders, effectively yes. The biggest mailbox providers now require them.

Google (Gmail)

Since February 2024, every sender to Gmail needs at least SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail accounts needs SPF, DKIM and a DMARC record, which can be set to p=none, with the From domain aligned to SPF or DKIM (Google email sender guidelines).

Google began ramping up enforcement in November 2025. Non-compliant messages can now face temporary and permanent rejections, not just the spam folder (Google sender guidelines FAQ).

Microsoft (Outlook.com, Hotmail and Live)

From 5 May 2025, Microsoft began requiring SPF, DKIM and DMARC for domains sending more than 5,000 emails a day to its consumer mailboxes. Messages that fail are rejected with an “Access denied” error rather than sent to junk (Microsoft Tech Community).

Most small businesses do not send 5,000 emails a day. But these thresholds count everything leaving your domain, including marketing campaigns and automated notifications. Setting all three up properly is simply the baseline now.

How to set up SPF, DKIM and DMARC safely

The order matters. Jump straight to p=reject and you may block your own payroll emails. The NCSC recommends a staged approach, which looks like this in practice.

1. List everything that sends email as you

Start with the obvious: Microsoft 365 or Google Workspace. Then look further. Newsletter tools, CRM systems, accounting software, booking platforms, website contact forms and your EPOS system might all send email using your domain.

2. Publish SPF and enable DKIM

Create one SPF record that covers every legitimate sender. Keep it to one record only, because publishing two causes SPF to fail. Then turn on DKIM signing in each platform that supports it.

3. Start DMARC at p=none and read the reports

Publish a DMARC record with p=none and a reporting address. According to the NCSC, reports start arriving from major mail providers within 24 hours (NCSC: implement a DMARC policy of none).

The raw reports are XML files, which nobody enjoys reading. A DMARC reporting tool turns them into a readable list of who is sending as you, and whether they pass.

4. Fix what fails, then tighten the policy

Use the reports to find legitimate senders that are failing, and fix their SPF or DKIM setup. Once you are confident every known sender passes, move to p=quarantine. When quarantine runs cleanly, move to p=reject.

There is no fixed timescale. A small business with two or three senders might get there in weeks. An organisation with a dozen platforms and a few forgotten ones will take longer.

5. Keep it maintained

Email authentication is not a one-off job. The NCSC advises putting a process in place so SPF and DKIM are updated whenever a sending service is added or retired (NCSC: continuous improvement). Otherwise a new marketing tool fails silently, or an old one stays authorised long after you stopped paying for it.

Common SPF, DKIM and DMARC mistakes

• Staying on p=none forever. It is a monitoring setting, not protection. Plenty of domains publish it and never move on.
• Two SPF records on one domain. This usually happens when a new platform’s setup guide says “add this SPF record” and someone does exactly that. Merge them into one.
• Going over the 10-lookup limit. Check your SPF record with a lookup tool whenever you add a new service.
• Relying on SPF alone for third-party platforms. Set up DKIM for your own domain on each one, so alignment works.
• Forgetting unused domains. The NCSC advises that every domain you own should have a DMARC record, including domains you never send email from. Parked domains are easy targets for spoofing precisely because nobody is watching them.

Frequently asked questions

Do I need all three: SPF, DKIM and DMARC?

Yes. SPF and DKIM each verify part of the picture, and each has gaps. DMARC is what connects them to your visible From address and tells receivers what to do. Bulk senders to Gmail and Outlook.com are required to have all three.

Will DMARC stop all phishing emails?

No. DMARC stops criminals sending email from your exact domain. It does not stop lookalike domains, such as swapping a letter or adding a hyphen. Staff awareness and email filtering still matter.

Can setting up DMARC stop my own emails being delivered?

Only if you move to quarantine or reject before every legitimate sender passes authentication. Starting at p=none and reading the reports first avoids this.

How do I check my current records?

Free online lookup tools will show your SPF and DMARC records in seconds. The NCSC also offers an email security check service, linked from its email security and anti-spoofing guidance, which tests your domain against its recommended standards.

Where to start

Look up your domain’s DMARC record today. If there is no record, or it says p=none and has done for months, your domain can still be used to send convincing fake emails to your customers.

The fix is a handful of DNS records and some patience with the reports. It is one of the cheapest security improvements a business can make, and one of the few your customers benefit from directly.