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.

The Ten DNS Lookup Limit

One of the most technically important constraints of SPF is the ten DNS lookup limit. Every include: mechanism, a: mechanism, mx: mechanism, and redirect modifier in your SPF record triggers a DNS lookup. If the total number of lookups exceeds ten, the entire SPF record is considered invalid and all SPF checks will fail — effectively leaving your domain unprotected. This limit catches out many UK businesses that use multiple third-party services, each of which requires its own include: entry.

For example, a business using Microsoft 365, a marketing platform like Mailchimp, a CRM like HubSpot, a helpdesk like Zendesk, and a transactional email service like SendGrid might easily hit the ten-lookup limit. The solution is SPF flattening — a technique that replaces include: references with the actual IP addresses they resolve to, eliminating nested lookups. Several commercial services offer automated SPF flattening that keeps your record updated as providers change their IP ranges.

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.

DKIM Key Rotation

Like any cryptographic system, DKIM keys should be rotated periodically to maintain security. If a private key is compromised, an attacker could sign fraudulent emails that pass DKIM verification. Microsoft 365 uses a dual-selector system (selector1 and selector2) that allows seamless key rotation — you activate the new key on one selector while the old key remains active on the other, ensuring no emails fail authentication during the transition. Best practice for UK businesses is to rotate DKIM keys at least once a year, though quarterly rotation provides stronger security. Many organisations neglect key rotation entirely, leaving the same keys in place for years — a practice that increases risk over time.

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

UK Email Spoofing Threat Landscape

The scale of email spoofing targeting UK businesses has grown substantially in recent years. According to the National Cyber Security Centre (NCSC), the UK faces a disproportionate share of email-based attacks compared to its economic size, in part because UK businesses are perceived as high-value targets by international criminal groups. Understanding the threat landscape helps justify the investment in proper email authentication.

Business Email Compromise (BEC) attacks — where criminals impersonate senior executives to authorise fraudulent payments — cost UK businesses an estimated 236 million pounds in 2025 alone. These attacks rely almost entirely on email spoofing or compromised accounts, and SPF, DKIM, and DMARC are the primary technical defences. The average BEC loss for a UK SME is between 25,000 and 75,000 pounds per incident, and many businesses do not recover the funds because the transfers are typically routed through multiple international accounts before the fraud is detected.

Supply chain spoofing is another growing threat. Criminals research your supplier relationships (often through publicly available information or previous data breaches) and send spoofed emails that appear to come from your suppliers, requesting changes to bank account details for upcoming invoices. Without DMARC enforcement on both your domain and your suppliers' domains, these attacks are extremely difficult for staff to detect. Several high-profile UK cases have involved losses exceeding 500,000 pounds from a single spoofed supplier email.

The NCSC's Mail Check service, which monitors email authentication for UK public sector domains, has identified that approximately 67 per cent of UK government domains now have DMARC at p=reject — a significant improvement from just 12 per cent in 2018. However, the private sector lags considerably behind, with only an estimated 33 per cent of UK business domains having any DMARC record at all, and fewer than 15 per cent at p=reject.

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.

Practical Example: Implementing Email Authentication for a UK Law Firm

To illustrate the implementation process in a real-world context, consider a 30-person law firm based in Birmingham. The firm uses Microsoft 365 as its primary email platform, Clio as its practice management system (which sends automated client emails), Mailchimp for their quarterly newsletter, and an on-premises multifunction printer that sends scanned documents via email. They had no SPF, DKIM, or DMARC records configured.

The audit in Phase One identified four legitimate email sources: Microsoft 365, Clio, Mailchimp, and the printer's static IP address. The SPF record was constructed as v=spf1 include:spf.protection.outlook.com include:clio.email include:servers.mcsv.net ip4:86.14.xxx.xxx -all, totalling four DNS lookups — well within the ten-lookup limit. DKIM was enabled in Microsoft 365, Clio, and Mailchimp (the printer does not support DKIM, but SPF covers it).

Phase Two began with the DMARC record v=DMARC1; p=none; rua=mailto:dmarc@thefirm.co.uk; pct=100. Within the first week, aggregate reports revealed an unexpected email source: a legacy Xero accounting integration that a former administrator had configured to send invoice reminders from the firm's domain. This would have been missed without the monitoring phase. The SPF record was updated to include Xero's servers, and DKIM was configured for the Xero integration.

After four weeks of clean monitoring data, the firm progressed to p=quarantine. Two weeks of quarantine monitoring showed zero false positives — all legitimate emails were passing authentication. The firm then moved to p=reject in week seven, two weeks ahead of the typical schedule. Within the first month of p=reject enforcement, the DMARC reports showed that 47 spoofing attempts had been blocked — emails that would previously have reached the firm's clients appearing to come from the firm's domain. One of these was a sophisticated invoice redirection attempt targeting a corporate client with an outstanding payment of 180,000 pounds.

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.

Beyond the Basics: BIMI and MTA-STS

Once SPF, DKIM, and DMARC are fully deployed with a p=reject policy, UK businesses should consider two additional email security standards that build on this foundation: BIMI and MTA-STS.

BIMI (Brand Indicators for Message Identification) allows your organisation's logo to appear next to your emails in supporting mail clients, including Gmail, Apple Mail, and Yahoo Mail. BIMI requires a DMARC policy of p=quarantine or p=reject as a prerequisite, which means it is only available to organisations that have completed their email authentication implementation. Beyond the branding benefit, BIMI provides a visual trust indicator for recipients — if they see your verified logo, they can be confident the email genuinely came from your organisation. Implementing BIMI requires a Verified Mark Certificate (VMC) from a participating certificate authority, which costs approximately 1,200 to 1,500 pounds per year. For organisations where brand trust is commercially important — professional services firms, financial advisors, e-commerce businesses — this investment is typically well justified.

MTA-STS (Mail Transfer Agent Strict Transport Security) addresses a different vulnerability: the encryption of email in transit. Even with SPF, DKIM, and DMARC fully deployed, emails between mail servers can be transmitted unencrypted if TLS negotiation fails or is stripped by an attacker (a downgrade attack). MTA-STS publishes a policy that tells sending mail servers your domain requires encrypted connections, and to refuse delivery if encryption cannot be established. For UK businesses handling sensitive client data — particularly those subject to professional confidentiality obligations — MTA-STS provides an important additional layer of protection.

Monitoring and Maintaining Your Email Authentication

Email authentication is not a set-and-forget configuration. Ongoing monitoring is essential to catch new email sources that have not been authenticated, detect spoofing attempts, and identify configuration drift. At minimum, UK businesses should review their DMARC aggregate reports monthly and investigate any SPF or DKIM failures for legitimate email sources.

Common triggers for authentication failures include: adding a new SaaS platform that sends email from your domain without updating SPF and DKIM; a DNS provider change that accidentally removes or modifies authentication records; a third-party email provider changing their IP ranges (requiring SPF updates); and DKIM key expiry or rotation failures. Establishing a simple change management process — where any new email-sending service must be authenticated before go-live — prevents the most common issues.

For businesses with multiple domains (which is common for UK firms with .co.uk, .com, and .org.uk variants), every domain and subdomain needs its own SPF, DKIM, and DMARC configuration. Do not forget parked or dormant domains — these should have a restrictive SPF record (v=spf1 -all) and a DMARC record with p=reject to prevent them being used for spoofing. Attackers frequently target dormant domains because they know many organisations neglect them.