Email spoofing costs UK businesses millions each year. SPF, DMARC, and DKIM are the three DNS records that stop attackers from impersonating your domain. Here's how to set them up.
Email spoofing — sending emails that appear to come from your domain without your authorisation — is one of the most damaging and underappreciated threats facing UK businesses. Attackers use spoofed emails for:
The solution lies in three DNS records that together form an email authentication framework: SPF, DKIM, and DMARC.
SPF is a DNS TXT record that lists the IP addresses and mail servers 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 verify the sending server is on the approved list.
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.1 -all
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.1 -all
This record says: "Email from this domain may come from Google Workspace, SendGrid, or the IP 203.0.113.1. Reject everything else."
The -all at the end is critical — it tells receiving servers to reject (hard fail) emails from unauthorised sources. Using ~all (soft fail) only marks them as suspicious, which many spam filters ignore.
SPF only validates the envelope sender (the technical MAIL FROM address), not the From header that users see in their email client. This is why SPF alone is insufficient — you need DKIM and DMARC too.
DKIM adds a cryptographic signature to outgoing emails. Your mail server signs each email with a private key; the corresponding public key is published in your DNS. Receiving servers verify the signature, confirming the email has not been tampered with in transit and genuinely originated from your infrastructure.
Most modern email platforms generate the DNS record for you — you just need to add it to your DNS provider.
DMARC ties SPF and DKIM together and adds a policy layer. It tells receiving servers what to do when an email fails authentication checks, and provides reporting so you can see who is sending email on behalf of your domain.
| Policy | Effect | When to Use |
|---|---|---|
| p=none | Monitor only — no action taken | Starting out, collecting data |
| p=quarantine | Failed emails go to spam folder | Transitioning to enforcement |
| p=reject | Failed emails are rejected outright | Full enforcement — the goal |
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100
The rua tag specifies where aggregate reports are sent (daily summaries of authentication results). These reports are invaluable for identifying legitimate email sources you may have missed in your SPF record.
In February 2024, Google and Yahoo began requiring bulk senders (those sending more than 5,000 emails per day to Gmail/Yahoo addresses) to have SPF, DKIM, and DMARC configured. Emails that do not comply are rejected or sent to spam. Even if you send fewer than 5,000 emails per day, these requirements signal the direction of travel — DMARC enforcement is becoming the industry standard.
WebGuard checks for the presence and correct configuration of SPF, DKIM, and DMARC records as part of every scan. The report shows whether each record exists, whether the policy is in enforcement mode (-all for SPF, p=reject for DMARC), and common misconfigurations (too many DNS lookups in SPF, missing DKIM selector, DMARC in monitor-only mode).
Run a free scan [blocked] to check your domain's email authentication configuration today.
Free scan, no account required. See exactly which issues affect your site.
Start Free ScanSecurity headers are the fastest way to improve your website's security posture. Here's what each one does, why it matters, and the exact code to add it.
From DV to EV certificates, Let's Encrypt to paid CAs — everything UK website owners need to know about choosing, installing, and maintaining SSL/TLS certificates.
CSP and HSTS together block the majority of injection attacks and protocol downgrade attacks. Here's how to implement both correctly without breaking your site.