SPF, DKIM and DMARC Explained: Email Security for Small Businesses

Imagine one of your customers gets an email from your address asking them to pay an invoice into a “new” bank account. It has your logo, your signature and your email address at the top. They pay it. The money is gone, and the email never came from you.

This is called email spoofing, and it is one of the most common ways criminals target small businesses and their customers. The good news is that there are three settings, known as SPF, DKIM and DMARC, that make it far harder for anyone to send email pretending to be you.

They sound technical, and behind the scenes they are, but the idea is simple. This guide explains what each one does in plain English, why they matter, and what to check for your own business.

Why email needs extra protection

Email was designed in the early days of the internet, when nobody expected people to lie about who they were. By default, there is nothing stopping someone typing your email address into the “From” field and hitting send.

SPF, DKIM and DMARC were added later to fix that. They are small text records that sit in your domain’s DNS settings, the same place that tells the internet where your website and email are hosted. When an email arrives claiming to be from your domain, the receiving mail server checks these records to decide whether the message is genuine.

Think of them as three layers of ID checking:

• SPF checks where the email was sent from
• DKIM checks the email hasn’t been tampered with
• DMARC tells receivers what to do if a message fails those checks, and reports back to you

SPF: who is allowed to send your email

SPF (Sender Policy Framework) is a list of the services that are allowed to send email using your domain name.

If you use Microsoft 365, your SPF record tells the world “Microsoft is allowed to send email for us”. If you also send invoices through Xero or newsletters through Mailchimp, those need to be on the list too.

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

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

In plain English, that says: “Microsoft 365 can send email for this domain. Anything else should fail.”

A few things that commonly go wrong:

• Forgetting other senders. Your website contact form, accounting software, CRM, booking system or email marketing tool may all send email as you. If they are not in your SPF record, their emails may land in spam.
• Having more than one SPF record. Your domain must only have one. If a new supplier asks you to “add an SPF record”, it needs merging into the existing one, not added alongside it.
• Too many lookups. SPF has a limit of 10 DNS lookups. Add enough services and the record quietly breaks.

SPF on its own is not enough, though. It only checks the hidden “envelope” sender, not the address your customers actually see. That’s where DKIM and DMARC come in.

DKIM: a tamper-proof signature

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The signature is created using a private key held by your email provider, and the matching public key is published in your DNS.

When your email arrives, the receiving server uses the public key to check the signature. If it matches, the server knows two things: the email really was sent by a system you authorised, and nobody changed it along the way.

You do not need to understand the cryptography. What matters is that DKIM is switched on. With Microsoft 365, that usually means adding two records to your DNS and then enabling DKIM signing in the Microsoft Defender portal. Google Workspace has a similar setting in the Admin console. Many other services, such as email marketing platforms, offer their own DKIM records you can add too.

It is surprisingly common to find businesses that have been on Microsoft 365 for years without DKIM ever being turned on.

DMARC: the rulebook and the reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It does two important jobs.

1. It tells receiving servers what to do with emails that fail. Your DMARC policy can be set to one of three levels:

• p=none: monitor only. Deliver the email as normal, but report back. This is where everyone should start.
• p=quarantine: send failing emails to the recipient’s junk folder.
• p=reject: block failing emails completely. This is the goal.

2. It sends you reports. Mail providers such as Google and Microsoft send regular reports showing every system that has sent email using your domain, and whether it passed or failed. This is how you find the forgotten services that need adding to SPF or DKIM, and how you spot anyone trying to impersonate you.

A starting DMARC record might look like this:

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

DMARC also checks something called alignment: whether the domain that passed SPF or DKIM matches the domain in the “From” address your customers see. This is what closes the loophole SPF leaves open on its own.

Why “p=none” isn’t the finish line

Many businesses add a DMARC record set to p=none, tick the box and move on. That’s a sensible first step, but a p=none policy does not actually stop anyone spoofing you. It only watches.

The right approach is to:

1. Start at p=none and collect reports for a few weeks
2. Fix any genuine services that are failing (website forms and invoicing systems are the usual culprits)
3. Move to p=quarantine
4. Once you are confident nothing legitimate is being caught, move to p=reject

Rushing straight to p=reject without checking the reports is the quickest way to stop your own invoices reaching customers, so take it in stages.

Do I really need all three?

Yes. Each one covers a gap the others leave:

Record	What it checks	On its own, it…
SPF	Which servers can send for your domain	Doesn’t protect the “From” address people see
DKIM	The email is genuine and unchanged	Doesn’t tell receivers what to do if it fails
DMARC	SPF/DKIM match the visible sender, and sets the policy	Needs SPF and DKIM in place to work

There’s also a practical reason. Since 2024, Google and Yahoo have required businesses sending large volumes of email to their users to have SPF, DKIM and DMARC in place, and Microsoft has introduced similar rules for Outlook.com. Even if you send nowhere near those volumes, mail providers increasingly treat properly authenticated email as more trustworthy, so getting these right helps your genuine emails land in the inbox rather than spam.

How to check your own domain

You can get a quick idea of where you stand in a couple of minutes:

• Use a free online checker. Tools such as MXToolbox let you type in your domain and see whether SPF, DKIM and DMARC records exist and whether they are valid.
• Look at a sent email. Send an email from your work account to a personal Gmail address, open it, click the three dots and choose “Show original”. Gmail will show whether SPF, DKIM and DMARC each say PASS.

If any of them are missing or failing, or your DMARC policy is still sitting at p=none, it’s worth getting it looked at.

What these records won’t do

SPF, DKIM and DMARC protect your domain from being impersonated. They are very effective at that, but they are only one part of email security. They won’t stop:

• Criminals using a look-alike domain, such as yourcompany-uk.com or swapping letters around
• A phishing email from someone else’s domain landing in your inbox
• An attacker who has stolen one of your team’s passwords and is sending from your real account

That’s why they work best alongside good email filtering, multi-factor authentication on every account, and a team who knows what to look out for. Our guides on business email compromise attacks and how to tell a real Microsoft email from a fake one cover those risks in more detail, and our email security best practices for UK small businesses brings it all together.

Need a hand?

Setting up SPF, DKIM and DMARC properly means finding every service that sends email for you, getting the records right, and then carefully tightening the DMARC policy without disrupting your genuine email. It’s exactly the kind of job that’s easy to half-finish and then forget about.

At My Tech Team, we check and configure email authentication as part of our cyber security services for businesses across Burgess Hill, Hailsham, East Grinstead and the wider Sussex area. If you’re not sure whether your domain is protected, get in touch or book a free IT audit and we’ll take a look.