SPF, DKIM and DMARC for Business Email

Why authentication matters

Email was designed without any check that the sender is who they say they are. Anyone can put your domain in the From line of a message. SPF, DKIM and DMARC are three DNS-based standards that let receiving mail services check whether a message really comes from you. Mailbox providers use the results to decide what reaches the inbox, and since February 2024 Gmail and Yahoo have required them from senders.

All three are TXT records in your domain's DNS, so whoever manages your DNS (your registrar, your host or a DNS provider) is where the changes are made. The values themselves come from the services that send email for you.

SPF: which servers may send for you

Sender Policy Framework, defined in RFC 7208, lets you publish a list of the servers allowed to send mail for your domain. A receiving server looks up the record for the domain in the envelope sender address (the hidden "MAIL FROM", which is not always the address people see) and checks the sending server against it. A record looks like this:

example.com.  TXT  "v=spf1 include:_spf.your-mail-provider.example -all"

The ending says what to do with servers that are not listed. Under the RFC, -all means "fail", ~all means "softfail", a weak statement that the server is probably not authorised, and ?all means "neutral", no statement at all.

Two rules in the RFC catch many businesses out:

• Only one SPF record per domain. If a domain has more than one, the check returns a permanent error (section 4.5). When you add a new sending service, edit the existing record rather than adding a second one.
• A limit of 10 DNS lookups. Each include, a, mx and similar term counts, including the lookups inside included records. Going over 10 also gives a permanent error (section 4.6.4).

DKIM: a signature on every message

DomainKeys Identified Mail, defined in RFC 6376, adds a digital signature to each message in a DKIM-Signature header. The sending service signs with a private key, and you publish the matching public key in DNS at selector._domainkey.yourdomain. The selector lets you hold several keys at once, for example one per sending service.

A valid signature shows that the domain in the signature's d= tag takes responsibility for the message and that the signed parts have not changed since signing. The RFC requires signers to use RSA keys of at least 1024 bits for long-lived keys (section 3.3.3). Your email platform generates the keys; your job is to publish the record it gives you and turn signing on.

DMARC: tying it to the From address

SPF and DKIM each check a domain, but not necessarily the one your recipients see in the From line. DMARC closes that gap. It passes only when SPF or DKIM passes and the domain they checked is aligned with the From address. In the default "relaxed" mode, a subdomain such as mail.example.com counts as aligned with example.com.

DMARC was first published as RFC 7489 in 2015, an informational document. In May 2026 it was replaced by RFC 9989, which makes DMARC a proposed standard, with reporting moved to RFC 9990 and RFC 9991. The record lives at _dmarc.yourdomain:

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

• p is your policy for mail that fails: none (take no action, just report), quarantine (treat as suspicious, usually spam folder) or reject.
• rua is where receivers send aggregate reports: daily summaries of who sent mail using your domain and whether it passed.
• sp sets a separate policy for subdomains. RFC 9989 also adds np for subdomains that do not exist and a t test flag, and removes the old pct percentage tag.

What Gmail and Yahoo require

Google's email sender guidelines apply from 1 February 2024. Everyone sending to Gmail accounts must:

• set up SPF or DKIM for the sending domain;
• have valid forward and reverse DNS for sending servers;
• use a TLS connection to transmit email;
• keep spam rates reported in Postmaster Tools below 0.3%.

Senders of more than 5,000 messages a day to Gmail accounts must also set up both SPF and DKIM, publish a DMARC record (a policy of none is enough), align the From domain with the SPF or DKIM domain, and support one-click unsubscribe in marketing messages (our email marketing rules guide covers unsubscribes and consent). Google asks them to keep spam rates below 0.10% and never reach 0.30%.

Yahoo's Sender Best Practices set the same shape of rules: SPF or DKIM for all senders, and for bulk senders both, a valid DMARC policy of at least p=none that passes, a working one-click list-unsubscribe header, unsubscribes honoured within 2 days and a spam rate below 0.3%.

Even if you send far fewer than 5,000 messages a day, set up all three. It costs little, protects your name and avoids trouble when a newsletter grows.

How to check your domain

1. Read a real message. Send an email from your domain to a Gmail address, open it and choose More, then Show original. The top of the page shows the SPF, DKIM and DMARC results. Do the same for mail sent by your website, shop and newsletter tool, since each one sends separately.
2. Analyse the header. Google's Admin Toolbox Messageheader tool, linked from the same help page, reads a pasted header and shows each step.
3. Read your DMARC reports. Once rua is set, the reports show every service sending as your domain, including ones you forgot about and ones that are not you.

Common mistakes

• Two SPF records after adding a newsletter or CRM tool, which breaks SPF for all mail.
• Too many includes, pushing SPF past the 10-lookup limit.
• The website sends unauthenticated mail. Contact forms and order emails sent straight from the web server often pass neither check. Send them through an authenticated email service instead.
• DKIM never switched on in a third-party tool, so its mail is signed only with the tool's own domain and does not align.
• Jumping straight to p=reject before every legitimate sender passes, which blocks your own invoices.
• Leaving p=none forever, which reports spoofing but never stops it.
• Forgetting email when moving host or DNS. Copy all TXT records across before switching nameservers.

A safe order of work

1. List every service that sends email as your domain: mailbox provider, website, shop, CRM, newsletter, invoicing and support tools.
2. Publish one SPF record that covers them, within the lookup limit.
3. Turn on DKIM in each service and publish its key.
4. Publish DMARC with p=none and a rua address, and read the reports.
5. Fix anything that fails, then move to quarantine and later reject.
6. Check again whenever you add a sending tool or change host. Our guides to web hosting and website security cover the rest of that checklist.

Frequently asked questions

Do I need SPF, DKIM and DMARC if I only send a few emails a day?

Gmail and Yahoo require at least SPF or DKIM from every sender, and both plus DMARC from bulk senders. Setting up all three is still worth it for a small business, because DMARC lets you see and later block emails that fake your domain.

What DMARC policy should I start with?

Start with p=none and a rua address for reports. Once the reports show that all your legitimate sending services pass, move to quarantine and then reject.

Why do my website's contact form emails go to spam?

Often because the web server sends them directly, without SPF or DKIM for your domain. Sending them through an authenticated email service, with the right DNS records, usually fixes it.

Can I have two SPF records, one for my mailbox and one for my newsletter tool?

No. RFC 7208 says more than one SPF record on a domain gives a permanent error. Combine both services into a single record.

Where do I add these records?

In the DNS for your domain, wherever its nameservers point: your registrar, your web host or a separate DNS provider. Each sending service gives you the exact values to add.

Need your website's forms and order emails to reach the inbox? Setting up and checking email authentication is part of our website maintenance and website development work. See all our services, or email info@creahive.com.