Email Security: SPF, DKIM, and DMARC Explained

Why Email Security Matters

Email was designed in the 1970s with no built-in way to verify who sent a message. Anyone can forge an email that appears to come from your domain — spammers do it constantly. SPF, DKIM, and DMARC are three DNS records that work together to prove your emails are genuinely from you, preventing spoofing and improving deliverability.

If you self-host email, all three are mandatory — without them, major providers (Gmail, Outlook) will likely reject or spam-folder your messages. Even if you use Google Workspace or Microsoft 365, understanding these helps you troubleshoot delivery problems.

Step 1. SPF — Who Can Send Email From Your Domain

SPF (Sender Policy Framework) is a list of servers authorised to send email on behalf of your domain. When an email arrives, the receiving server checks: "Did this come from a server on the authorised list?" If not, it's likely spam.

An SPF record looks like this:

What each part means:

• •v=spf1 — SPF version 1 (always the same)
• •mx — allow your mail server (defined by your MX record)
• •include:_spf.google.com — also allow Google's mail servers (if you use Google Workspace)
• •~all — soft-fail: treat anything else as suspicious but not rejected outright

Add this as a TXT record in your DNS settings. If you use Cloudflare, this takes effect within minutes. See our Domains & DNS guide for how to add DNS records.

Step 2. DKIM — Proving the Email Wasn't Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server uses your public key (published in DNS) to verify the email hasn't been altered in transit. Think of it as a tamper-evident seal.

A DKIM record looks like this:

The google._domainkey prefix is called the "selector" — your email provider gives you this. The long string after p= is your public key. Your email provider holds the private key and signs each message with it.

Most email providers generate DKIM for you automatically. Self-hosted mail servers (like Stalwart) require you to generate keys and publish the public half in DNS.

Step 3. DMARC — What to Do With Emails That Fail

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receiving servers: "If an email fails SPF or DKIM, here's what to do with it." It also sends you reports so you can see who's trying to spoof your domain.

A DMARC record looks like this:

The policy (p=) is the key decision:

Step 4. Setting These Up

All three records go in your DNS settings as TXT records. If you use Cloudflare (recommended), this is done in the DNS dashboard. If your domain's DNS is managed by your registrar, look for "DNS Management" or "Advanced DNS" in their control panel.

• •SPF: TXT record on your root domain (@ or yourdomain.uk)
• •DKIM: TXT record on selector._domainkey.yourdomain.uk (your email provider gives you the selector and value)
• •DMARC: TXT record on _dmarc.yourdomain.uk

See our Cloudflare guide for step-by-step DNS management instructions.

Step 5. Testing Your Setup

Free tools to verify your configuration:

• •MXToolbox (mxtoolbox.com) — enter your domain, run SPF/DKIM/DMARC checks individually
• •Mail Tester (mail-tester.com) — send a test email to their address and get a full spam score breakdown
• •Google Admin Toolbox (Google's Check MX tool) — comprehensive check from Google's perspective

Step 6. Reading DMARC Reports

Once DMARC is set up with a rua=mailto:... address, you'll start receiving daily aggregate reports (XML files) from major email providers. These tell you:

• •How many emails were sent from your domain
• •How many passed/failed SPF and DKIM
• •Which IP addresses are sending email claiming to be you (spot unauthorised senders)

The raw XML is hard to read — use free services like Postmark DMARC or dmarcian to parse them into readable reports. After a few weeks of monitoring with p=none, tighten to p=quarantine and eventually p=reject for full protection.