How to Prevent Email Spoofing with SPF, DKIM, and DMARC

Email spoofing — where a malicious actor sends emails that appear to come from your domain — is one of the most persistent and damaging cyber security threats facing UK businesses. A spoofed email that looks like it comes from your managing director, your accounts team, or your HR department can trick employees into transferring funds, sharing credentials, or opening malicious attachments. It can also damage your brand reputation if clients receive fraudulent emails purporting to come from your business.

The good news is that three well-established email authentication protocols — SPF, DKIM, and DMARC — provide robust protection against email spoofing when configured correctly. Together, they form a layered defence that verifies the legitimacy of emails sent from your domain and instructs receiving mail servers on how to handle emails that fail authentication.

Despite their effectiveness, a surprising number of UK businesses still have not implemented these protocols, or have implemented them incorrectly — leaving their domains vulnerable to abuse. This guide explains how each protocol works, how to implement them, and the common pitfalls to avoid.

Understanding Email Spoofing

To understand why SPF, DKIM, and DMARC are necessary, it helps to understand how email spoofing works. The Simple Mail Transfer Protocol (SMTP), which underpins all email communication, was designed in the early 1980s without any built-in authentication mechanism. The "From" address in an email is simply a text field that the sender can set to anything — there is no inherent verification that the sender actually controls the domain they claim to be sending from.

This means that without additional authentication mechanisms, anyone with basic technical knowledge can send an email that appears to come from your domain. The email will show your company name and email address in the "From" field, and without SPF, DKIM, and DMARC in place, receiving mail servers have no reliable way to determine that it is fraudulent.

SPF: Sender Policy Framework

What SPF Does

SPF is the first layer of email authentication. It works by allowing you to publish a DNS record that specifies which mail servers are authorised to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to see whether the sending server's IP address is on the authorised list. If it is not, the email fails SPF authentication.

How to Configure SPF

An SPF record is a TXT record published in your domain's DNS. It lists the IP addresses and third-party services that are permitted to send email from your domain. A typical SPF record for a UK business using Microsoft 365 might look like this:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.50 -all

This record authorises Microsoft 365 mail servers, Google's mail servers (if you also use Google services), and the specific IP address 203.0.113.50. The -all at the end is critical — it tells receiving servers to reject emails from any server not listed in the record. Using ~all (soft fail) instead of -all (hard fail) provides a weaker level of protection and should only be used during initial testing.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM adds a digital signature to every email sent from your domain. This signature is generated using a private key held by your mail server and can be verified by receiving servers using a public key published in your DNS. DKIM serves two purposes: it confirms that the email was genuinely sent by an authorised system, and it confirms that the email content has not been altered in transit.

How DKIM Works

When your mail server sends an email, it generates a cryptographic hash of specified email headers and the body content, then encrypts this hash using your private key. The encrypted hash is added to the email as a DKIM-Signature header. When the receiving server gets the email, it retrieves your public key from your DNS records, decrypts the hash, and compares it against its own hash of the email content. If they match, the email passes DKIM authentication.

Configuring DKIM

DKIM configuration involves two steps: enabling DKIM signing on your mail server or email provider, and publishing the corresponding public key in your DNS. If you use Microsoft 365, DKIM can be enabled through the Microsoft Defender portal. The public key records (typically two CNAME records for key rotation) are then added to your DNS. If you use Google Workspace, the process is similar — generate the DKIM key in the admin console and publish the TXT record in DNS.

For third-party services that send email on your behalf (marketing platforms, transactional email services), you will need to configure DKIM signing for each service separately. Most reputable email service providers offer DKIM configuration as standard.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

What DMARC Does

DMARC builds on SPF and DKIM by adding a policy layer and a reporting mechanism. It tells receiving mail servers what to do when an email fails SPF and DKIM authentication, and it provides you with reports on authentication results so you can monitor how your domain is being used — and abused.

DMARC Policies

DMARC supports three policy levels, each providing an increasing level of protection. Understanding these levels and the correct progression between them is essential for successful implementation.

The p=none policy is the starting point. It does not instruct receiving servers to take any action on failing emails — it simply collects reporting data. This allows you to identify all legitimate sources of email from your domain before enforcing a stricter policy. The p=quarantine policy instructs receiving servers to send failing emails to the recipient's spam folder. The p=reject policy instructs receiving servers to block failing emails entirely — this is the ultimate goal and provides maximum protection against spoofing.

Implementing DMARC

A DMARC record is published as a TXT record in your DNS under the _dmarc subdomain. A typical starting record looks like this:

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

The rua tag specifies where aggregate reports should be sent, and the ruf tag specifies where forensic reports (detailed information about individual failing emails) should be sent. The pct tag specifies the percentage of failing emails to which the policy should be applied — start at 100% for monitoring, then use this to gradually ramp up enforcement when moving to quarantine or reject.

DMARC Tag	Purpose	Example Value	Notes
v	Version	DMARC1	Must always be DMARC1
p	Policy	none / quarantine / reject	Start with none, progress to reject
rua	Aggregate reports	mailto:dmarc@yourdomain.co.uk	Essential for monitoring
ruf	Forensic reports	mailto:forensic@yourdomain.co.uk	Detailed per-message data
pct	Percentage applied	100	Use for gradual rollout
sp	Subdomain policy	reject	Policy for subdomains
adkim	DKIM alignment	r (relaxed) / s (strict)	Relaxed is more forgiving
aspf	SPF alignment	r (relaxed) / s (strict)	Relaxed is more forgiving

The Implementation Roadmap

Implementing SPF, DKIM, and DMARC should follow a deliberate, phased approach. Rushing to a p=reject DMARC policy without proper preparation risks blocking legitimate emails from reaching their intended recipients.

Phase One (Week 1-2): Audit all sources of email from your domain. This includes your primary mail system, any marketing email platforms, transactional email services, CRM systems, helpdesk software, and any other system that sends email using your domain. Configure SPF and DKIM for all identified sources.

Phase Two (Week 2-4): Publish a DMARC record with p=none and begin collecting reports. Analyse the reports to identify any legitimate email sources you missed in Phase One. Address any gaps.

Phase Three (Week 4-8): Once you are confident that all legitimate sources are authenticated, move to p=quarantine. Monitor for any reports of legitimate emails being quarantined and address any issues.

Phase Four (Week 8-12): Move to p=reject. This is your end state — full protection against email spoofing. Continue monitoring reports to catch any new legitimate sources that may be added in the future.

NCSC Recommendations for UK Businesses

The National Cyber Security Centre (NCSC) strongly recommends that all UK organisations implement SPF, DKIM, and DMARC. Their guidance specifically advises progressing to a p=reject DMARC policy for maximum protection. The NCSC also provides a free tool — Mail Check — that UK public sector organisations can use to monitor their email authentication configuration. Private sector businesses can use commercial alternatives such as Postmark's DMARC monitoring tool, dmarcian, or Valimail.

For businesses pursuing Cyber Essentials Plus certification, having robust email authentication is increasingly considered as part of the overall security assessment. While not a formal requirement of the scheme as of 2026, auditors will often note the absence of DMARC as a risk factor during assessment.