SPF, DKIM & DMARC Explained | Business Email Guide

The Short Answer

SPF, DKIM and DMARC are DNS records that help receiving mail servers decide whether email claiming to come from your domain is genuine. SPF lists which servers may send for you, DKIM adds a cryptographic signature, and DMARC checks that these results match your visible domain and tells receivers how to handle failures.

Together they make it harder for criminals to impersonate your business and give mailbox providers clearer signals about your legitimate mail. They do not guarantee inbox placement. Content, sending reputation and recipient behaviour still matter. Setup also depends on who actually sends your email, so the exact values always come from your mail provider and any other services that send on your behalf.

SPF, DKIM and DMARC Explained for Small Business Email — Three DNS records work together to prove your business email is genuine.

Why This Matters for a Small Business

Email spoofing is cheap and easy. Without authentication, anyone can send a message that displays your domain in the “From” line, such as a fake invoice to your customers or a payment-change request to your supplier. Small firms are attractive targets because their domains are often left unprotected.

Major mailbox providers have also tightened their expectations, particularly for organisations that send large volumes. Even if you only send a few dozen emails a day, missing or broken authentication can make your legitimate messages look suspicious. Getting these three records right is basic housekeeping, much like locking the office at night.

SPF: Authorising Who Can Send

Sender Policy Framework (SPF) is a single TXT record published at the root of your domain. It lists the servers and services permitted to send email using your domain. When a message arrives, the receiving server checks the sending server’s address against that list.

An illustrative example only, not ready to copy:

example.co.uk.  TXT  "v=spf1 include:mail.yourprovider.example include:newsletters.example ~all"

Here, include: authorises a provider’s sending servers, and ~all (soft fail) asks receivers to treat everything else with suspicion. -all (hard fail) is stricter. Your provider will tell you exactly which include values to use.

💡 Only one SPF record per domain: Publishing two records beginning v=spf1 causes SPF to fail outright. If you add a new sending service, merge its include into your existing record rather than creating another one. SPF also has a limit of ten DNS lookups, so long chains of includes can break it silently.

SPF has a weakness: it checks the hidden “envelope” sender (the Return-Path), not the From address your customers see. It also tends to break when email is forwarded. That is why DKIM and DMARC are needed alongside it.

DKIM: Cryptographic Signing

DomainKeys Identified Mail (DKIM) adds a digital signature to each outgoing message. Your mail provider signs the email with a private key it keeps secret, and you publish the matching public key in DNS. The receiving server uses that public key to confirm the message was signed by an authorised system and was not altered on the way.

DKIM records live under a “selector”, so one domain can hold several keys for different services. An illustrative example, shortened and not usable:

selector1._domainkey.example.co.uk.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...AB"

You never create the key yourself in a typical small-business setup. Your provider generates it, gives you the exact host name and value (sometimes as a CNAME rather than a TXT record), and you then switch signing on in their control panel. Because the signature travels with the message, DKIM usually survives forwarding better than SPF does.

DMARC: Alignment, Policy and Reporting

Domain-based Message Authentication, Reporting and Conformance (DMARC) ties everything together. It does three jobs:

Alignment: it checks that the domain which passed SPF or DKIM matches the domain in the visible From address. A message passes DMARC if at least one of SPF or DKIM passes and aligns.
Policy: it tells receivers what to do with mail that fails.
Reporting: it asks receivers to send you aggregate reports showing who is sending email using your domain.

DMARC is a TXT record at _dmarc. An illustrative starting record:

_dmarc.example.co.uk.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk"

Policy	What receivers are asked to do	When to use it
`p=none`	Deliver as normal, but send reports	Monitoring phase while you find all legitimate senders
`p=quarantine`	Treat failures as suspicious, often sending them to spam	Once reports show legitimate mail is passing
`p=reject`	Refuse failing messages entirely	Only after quarantine has run cleanly

💡 Do not jump straight to reject: If your invoicing software, booking system or website contact form sends as your domain but is not set up properly, p=reject will stop those emails reaching customers. Review your reports first and tighten gradually.

Before You Start: Three Things Not to Break

📬

Leave MX records alone

MX records control where incoming mail is delivered. SPF, DKIM and DMARC are separate TXT or CNAME records. Replacing or deleting MX entries can stop email arriving.

🔑

Edit, don’t duplicate

Check for an existing SPF or DMARC record before adding one. Two of either will cause failures.

📋

Use your provider’s values

Every mail service publishes its own SPF include and DKIM keys. Copying values from a blog post, including this one, will not work.

Step-by-Step Setup Checklist

Find where your DNS is managed. This might be your domain registrar, your hosting control panel or a separate DNS service. Changes only take effect where your domain’s nameservers point.
List every service that sends as your domain. Include your mailbox provider, newsletter tools, CRM, accounting or invoicing software, online shop, booking system and website contact forms.
Build or update one SPF record containing each service’s include, ending in ~all to begin with.
Enable DKIM for each service that supports it, publishing the records they provide and switching signing on.
Publish a DMARC record with p=none and a reporting address you actually monitor, or a mailbox fed into a report-reading tool.
Send test emails to an external mailbox and check the message headers for spf=pass, dkim=pass and dmarc=pass.
Review reports for a few weeks. Look for legitimate services failing alignment and fix them.
Move to p=quarantine, then p=reject once you are confident genuine mail passes consistently.

If you are still choosing or configuring your hosting and mailboxes, our guide on how to set up hosting and email covers the groundwork before you add authentication records.

Common Edge Cases

Website forms sending via your web server: mail sent directly from a hosting server may not be covered by your SPF or signed with DKIM. Sending through an authenticated SMTP account is usually more reliable.
Third parties using their own bounce domain: SPF may pass for their domain but not align with yours. Custom DKIM on your domain typically solves this.
Forwarding and mailing lists: forwarding often breaks SPF, and lists that alter subject lines can break DKIM. This is why monitoring comes before enforcement.
Domains that never send email: protect parked domains with an SPF record of v=spf1 -all and a DMARC policy of reject, so they cannot be spoofed.
Subdomains: DMARC can apply a separate subdomain policy, useful if marketing mail is sent from a subdomain such as news.example.co.uk.

Frequently Asked Questions

Do I need all three records?

Yes, in practice. SPF and DKIM provide the evidence, while DMARC enforces alignment and gives you visibility. Each covers gaps in the others.

How long do DNS changes take?

Often minutes, but it can take longer depending on the record’s TTL and caching. Allow time before assuming something is broken.

Will these records stop my email going to spam?

They remove one common cause of filtering, but no setup can guarantee inbox placement. Reputation, content and recipient engagement still count.

What should I do with DMARC reports?

Aggregate reports arrive as XML files that are hard to read raw. A DMARC report analyser can summarise them so you can see which sources pass or fail.

For more general questions, see our FAQ page.

Summary and Next Step

SPF says who may send, DKIM proves messages are signed and unaltered, and DMARC checks both against your visible domain while reporting back to you. Start by listing every service that sends as your business, publish one SPF record, enable DKIM everywhere you can and begin DMARC at p=none. Tighten the policy only when reports confirm your legitimate mail is passing. Today, check your domain for duplicate SPF records and confirm your MX records are untouched.

Get Your Hosting and Email Foundations Right

Read the Setup Guide

When authentication fails, our guide to email bounce-back codes can help interpret the response.