Email remains the backbone of professional communication for UK businesses, yet it remains one of the most exploited attack vectors for fraud, impersonation and data theft. If your organisation sends emails without proper authentication protocols, your messages could be spoofed, your domain reputation damaged, or worse—your clients' trust eroded. Setting up DKIM, SPF and DMARC together is no longer optional; it's essential infrastructure. This guide walks you through each protocol, explains why they work best in combination, and provides practical steps for implementation tailored to professional services firms, legal practices and financial advisers operating in the UK.
Email authentication rests on three distinct but complementary technologies. Each addresses a different vulnerability in how email operates, and together they form a robust defence against impersonation and fraudulent use of your domain.
SPF is the foundation. It allows you to publish a list of authorised mail servers for your domain in a simple DNS text record. When a recipient's mail server receives an email claiming to be from your domain, it checks your SPF record to verify that the sending server is on your approved list. If the server is not listed, the recipient's system can reject or flag the message.
SPF alone has limitations—it doesn't prevent someone from modifying the "From" header, and it doesn't sign the message content—but it's straightforward to implement and provides immediate value.
DKIM adds cryptographic signature to your emails. Your mail server signs outgoing messages with a private key; recipients' servers verify the signature using your public key, published in DNS. This proves two things: that the email genuinely came from your domain, and that the message content hasn't been tampered with in transit.
DKIM is particularly valuable for professional services firms handling sensitive client communications, because it provides non-repudiation—proof that the message originated from your organisation.
DMARC ties SPF and DKIM together. It lets you define a policy: what should happen if an email fails both SPF and DKIM checks? Should it be rejected, quarantined, or accepted? DMARC also generates detailed reports on authentication failures, giving you visibility into phishing attempts, configuration errors, and legitimate services that may need adjustment.
Crucially, DMARC enables subdomain policy alignment and supports external reporting—meaning third-party email service providers, marketing platforms and staff using gmail for client communication can all fall under your authentication policy.
Before writing your SPF record, list every service that sends email on behalf of your domain. This includes:
Each service provider publishes SPF-approved IP ranges or domain names in their documentation. Gather these identifiers, then construct your SPF record. A typical SPF record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.45 ~all
The ~all at the end means "softfail"—messages that don't match are flagged but not rejected, which is safer during testing. Once you're confident all legitimate sources are included, change it to -all (hard fail).
DKIM configuration varies depending on your mail platform:
default._domainkey.yourdomain.co.uk).A DKIM DNS record is lengthy but typically looks like:
default._domainkey.yourdomain.co.uk TXT v=DKIM1; k=rsa; p=MIGfMA0B...
Test your DKIM setup by sending a test email and checking the message headers in the recipient's email client for an "Authentication-Results" field confirming DKIM passed.
Create a DMARC DNS record at _dmarc.yourdomain.co.uk. Start with a monitoring-only policy to observe what happens without enforcing rejection:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.co.uk; ruf=mailto:dmarc-forensics@yourdomain.co.uk
This tells recipients: "I'm not enforcing a policy yet, but send me aggregate reports (rua) daily and forensic reports (ruf) on failures." Monitor these reports for 1–2 weeks. Once you're confident SPF and DKIM are correctly aligned, upgrade to:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.co.uk; ruf=mailto:dmarc-forensics@yourdomain.co.uk
This quarantines (rather than rejects) non-compliant mail, reducing the risk of blocking legitimate messages. After another week or two, if failures are rare and understood, move to p=reject for maximum protection.
Even experienced IT teams stumble during email authentication setup. Watch for these issues:
include: statement counts as a lookup. If you exceed 10, SPF fails. Consolidate services or ask providers for direct IP ranges instead.default but your DNS record uses selector1, DKIM will fail. Check consistency.clients.yourdomain.co.uk), create separate _dmarc records for each, or use the subdomain_policy tag.p=quarantine initially to avoid disruption.Email authentication is not a "set and forget" task. Review
VP Shield runs six passive checks across DNS, TLS, headers, SPF, DKIM, DMARC and subdomain takeover — no login, no install, no port scans. Results in 15 seconds.
Scan your domain now →