How to Set Up DKIM, SPF and DMARC Together: The Complete Guide

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.

Understanding the Three Pillars of Email Authentication

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: Sender Policy Framework

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: DomainKeys Identified Mail

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: Domain-based Message Authentication, Reporting and Conformance

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.

Step-by-Step Implementation: From SPF Through DMARC

Step 1: Generate SPF Record and Identify All Mail Sources

Before writing your SPF record, list every service that sends email on behalf of your domain. This includes:

• Your internal mail server (on-premises or hosted)
• Cloud email providers (Microsoft 365, Google Workspace, Proton Mail)
• Marketing automation platforms (HubSpot, Mailchimp)
• CRM or case management systems
• Transactional email services (SendGrid, AWS SES)
• Third-party integrations (document signing, client portals)

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).

Step 2: Configure DKIM Signing on Your Mail Server

DKIM configuration varies depending on your mail platform:

• Microsoft 365: DKIM is typically enabled by default for your primary domain; you must manually enable it for custom domains via the Microsoft 365 admin centre. Microsoft provides two public keys to add to your DNS records.
• Google Workspace: Generate a DKIM key pair in the Google admin console, then publish the public key as a CNAME or TXT record in your DNS.
• On-premises Exchange or Postfix: Generate a key pair using your mail server software, then publish the public key in DNS under the selector you choose (commonly default._domainkey.yourdomain.co.uk).
• Third-party services (SendGrid, Amazon SES, etc.): These usually generate DKIM keys for you; you simply add the provided DNS records.

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.

Step 3: Publish Your DMARC Policy

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.

Common Pitfalls and How to Avoid Them

Even experienced IT teams stumble during email authentication setup. Watch for these issues:

• SPF record exceeds 10 DNS lookups: Each include: statement counts as a lookup. If you exceed 10, SPF fails. Consolidate services or ask providers for direct IP ranges instead.
• Misaligned DKIM selectors: If your mail server signs with selector default but your DNS record uses selector1, DKIM will fail. Check consistency.
• DMARC subdomain policy confusion: By default, DMARC applies only to your primary domain. If your organisation sends from subdomains (e.g., clients.yourdomain.co.uk), create separate _dmarc records for each, or use the subdomain_policy tag.
• Ignoring third-party forwarding: If clients forward your emails or a third-party integrates your email address, they may fail DMARC alignment. Plan for these scenarios in your policy—use p=quarantine initially to avoid disruption.

Monitoring and Ongoing Maintenance

Email authentication is not a "set and forget" task. Review