If someone wanted to send an email that looked like it came from your business — to your customers, suppliers, or employees — nothing would technically stop them. Email was designed without built-in authentication. SPF, DKIM, and DMARC are the three standards that add authentication after the fact. Together, they stop your domain being used to send fraudulent emails, and they improve deliverability of your legitimate emails.

Most small businesses have incomplete or misconfigured email authentication. This guide walks through what each standard does and how to set them up correctly.

Why This Matters

Brand impersonation and phishing

Without email authentication, anyone can send an email with your domain in the “From” address. Criminals use this to:

  • Impersonate your business to scam your customers (“Invoice from accounts@yourbusiness.com”)
  • Target your employees with fake supplier emails
  • Use your domain’s reputation for wider phishing campaigns

Email deliverability

Gmail, Microsoft 365, and other major providers use authentication signals to decide whether email goes to inbox or spam. Domains without proper SPF/DKIM/DMARC are increasingly likely to have legitimate emails filtered as spam or rejected entirely. Google and Yahoo made DMARC a requirement for bulk senders in 2024; the threshold has since expanded.

The Three Standards

SPF (Sender Policy Framework)

SPF answers the question: which mail servers are authorised to send email on behalf of your domain?

You publish an SPF record as a DNS TXT record on your domain. When a receiving mail server gets an email claiming to be from yourcompany.com, it checks the SPF record to see if the sending server is on the approved list.

Example SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Breaking this down:

  • v=spf1 — SPF version
  • include:_spf.google.com — authorise Google Workspace to send on your behalf
  • include:sendgrid.net — authorise SendGrid (your marketing email provider)
  • ip4:203.0.113.10 — authorise a specific IP address (e.g., your office mail server)
  • -all — reject email from any server not listed above (hard fail)

How to find your current SPF record:

dig TXT yourdomain.com | grep spf
# or online: mxtoolbox.com/spf.aspx

Common SPF mistakes:

  • Using ~all (soft fail) instead of -all — soft fail just marks email as suspicious rather than rejecting it
  • Missing sending services — if you use a CRM, newsletter platform, or helpdesk that sends email on your behalf, each needs to be in your SPF record
  • Exceeding 10 DNS lookups — each include: counts toward a 10-lookup limit; going over causes SPF to fail silently

DKIM (DomainKeys Identified Mail)

DKIM answers the question: was this email actually sent by an authorised server and has it been tampered with in transit?

DKIM works through public-key cryptography. Your mail server signs outgoing emails with a private key. The corresponding public key is published as a DNS TXT record. Receiving servers verify the signature to confirm the email came from an authorised sender and wasn’t modified in transit.

Where the DKIM record lives: DKIM records use a selector prefix: selector._domainkey.yourdomain.com

For Google Workspace, it looks like:

google._domainkey.yourdomain.com  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Setting up DKIM: For Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record → add to DNS For Microsoft 365: Security portal → Email authentication settings → DKIM → enable

Most modern email providers generate DKIM keys automatically and tell you which DNS record to add. You typically don’t need to manage the keys yourself.

Verifying DKIM: Send a test email to a Gmail address, then open the email → More options (⋮) → Show original → look for DKIM=pass in the Authentication-Results header.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC answers the question: what should receiving servers do with email that fails SPF or DKIM checks?

DMARC has three policy options:

  • p=none — monitor only, take no action (use for initial rollout)
  • p=quarantine — send failing emails to spam
  • p=reject — block failing emails entirely

DMARC also enables reporting: receiving servers send aggregate reports to an address you specify, showing you which emails passed or failed authentication and from which servers. This is invaluable for finding services you’ve missed in your SPF record.

Example DMARC record (published at _dmarc.yourdomain.com):

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100
  • p=reject — reject emails that fail authentication
  • rua=mailto: — send aggregate reports here
  • pct=100 — apply to 100% of email (start with pct=10 during rollout)

Rollout Sequence

Don’t jump straight to p=reject. Start permissive and tighten as you gain confidence:

Week 1–2: Audit

  1. Check your current SPF/DKIM/DMARC with MX Toolbox or DMARC Analyser
  2. Identify all services that send email on your behalf (Google Workspace, CRM, newsletter tool, helpdesk, etc.)

Week 2–3: Fix SPF and DKIM

  1. Add all sending services to your SPF record
  2. Enable DKIM signing in each sending service and add the DNS records they specify

Week 3–4: Deploy DMARC in monitor mode

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

This generates reports without affecting email delivery. Analyse reports for 2–4 weeks to confirm all legitimate mail is passing.

Week 5+: Escalate DMARC policy Once reports show only legitimate email, move to p=quarantine, then p=reject.

Quick-Check: Is Your Domain Configured Correctly?

Run this check with your domain name at these free tools:

  • MX Toolbox: mxtoolbox.com/emailhealth — checks SPF, DKIM, DMARC, and blacklists in one pass
  • Google Admin Toolbox: toolbox.googleapps.com/apps/checkmx — for Google Workspace users
  • DMARC Analyser: dmarcanalyzer.com — focuses specifically on DMARC policy analysis

A correctly configured domain should show:

  • ✓ SPF record exists with -all or ~all
  • ✓ DKIM key published and valid
  • ✓ DMARC record exists with p=quarantine or p=reject

What Email Authentication Doesn’t Cover

SPF/DKIM/DMARC protect your domain from being spoofed by external senders. They don’t:

  • Prevent phishing emails from lookalike domains (yourc0mpany.com, yourcompany-invoices.com)
  • Protect against a compromised mailbox within your domain sending malicious email
  • Filter the content of emails — you still need spam filtering and malware scanning

For lookalike domain protection, consider registering common variants of your domain and monitoring for new registrations that could be used to impersonate you. Services like Namecheap Domain Monitor or brand protection platforms handle this automatically.

BEC and Why This Is Urgent

Business Email Compromise (BEC) — where attackers impersonate executives or suppliers to fraudulently redirect payments — is the highest-value cybercrime category for small and medium businesses. The median BEC loss exceeds £30,000, and most involve spoofed email domains.

Implementing DMARC at p=reject eliminates the domain spoofing vector entirely. It’s one of the highest-impact, lowest-cost security controls available to small businesses: a few DNS records, an afternoon of setup, and free tooling for the first year of monitoring.