SPF, DKIM and DMARC for a UK domain

On a small UK domain the hard part is not the syntax. It is the inventory: the inbox you read, the form that sends you a copy, the account that invoices, the newsletter tool, the accountant’s system. Miss one sender, move DMARC to reject too early, and you strand real mail. The method below is a rollout, not a protocol lecture. I use the SPF, DKIM & DMARC Builder and the SPF, DKIM & DMARC Checker on this site when I am adding or reviewing a domain.

Three records, one purpose: prove who sent the mail

It helps to keep the three jobs separate:

• SPF (the Sender Policy Framework) lists the servers that are allowed to send mail for the domain, as they appear in the envelope (the SMTP MAIL FROM). The receiving server looks up a TXT record on the domain and checks the sending IP against that list.
• DKIM (DomainKeys Identified Mail) is a cryptographic signature on the message, added by the sending platform. The public key lives in DNS. If the signature verifies, the receiving server knows those headers and that body were signed by someone who controls the domain (or a provider you authorised).
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the domain in the visible From header, and tells the receiver what to do when a message fails: monitor it, quarantine it, or reject it. It also asks for aggregate reports, so you can see who is sending as you.

A message can pass SPF and still fail DMARC, if the envelope domain and the From domain do not align. A message can pass DKIM and pass DMARC even when SPF does not, which is why a forwarding setup often depends on DKIM. You want both, and then a DMARC policy that you have earned the right to tighten.

The NCSC’s guidance on email security is a good UK-oriented companion to the RFCs when you are explaining this to a client or a registrar. The records themselves are ordinary DNS TXT records. Nothing about a .uk or .co.uk domain changes the syntax; what changes is the usual set of senders (Google Workspace or Microsoft 365, a registrar mailbox, a transactional provider, a shop).

SPF: one record, every legitimate sender

A domain should have one SPF record. Two TXT records that both start v=spf1 is a common, well-defined failure: receivers are entitled to treat that as a permanent error, and your carefully written includes will not be used. If you need to add a sender, edit the existing record.

A record is a single string, built from mechanisms. A small domain might look like this:

v=spf1 include:_spf.google.com include:spf.messaging.example ~all

That says: accept IPs that Google publishes, accept IPs that the transactional provider publishes, and soft-fail everything else (~all). -all is a hard fail. +all is “allow the world,” which makes SPF useless. ?all is a neutral result. For a rollout, ~all is the usual first step; -all is what you move to once DMARC reports, and your own tests, show that every legitimate sender is listed.

Rules that save a lot of pain:

• Include every platform that sends with your domain, not only the inbox. A contact form, a billing tool, a booking system and a newsletter each count.
• Use the provider’s current include mechanism, taken from their own documentation, not from a blog post. Those hostnames change.
• Stay within the ten-DNS-lookup limit. SPF caps the number of DNS lookups a receiver must perform (includes, a, mx and redirect all count; ip4 and ip6 do not). Nested includes can push you over the cap without it looking like it. If you are close, flatten with care, or stop adding providers.
• Don’t add mx as a reflex. It is only correct if your mail-exchange hosts actually send. Many domains send from a provider whose IPs are not the MX.
• Subdomains do not inherit the parent SPF record. If mail.example.co.uk or a provider’s bounce domain needs to send, it needs its own record, or you need to understand how that provider signs and which domain it uses.

If a provider asks you to “add an SPF record” and you already have one, they mean “add our include to the record you have.” The SPF, DKIM & DMARC Builder will lint a draft for a second v=spf1, a missing all, and some lookup-count problems; it cannot list senders you have forgotten.

DKIM: signing from each platform you use

SPF is about IPs. DKIM is about a key. Each sending platform should sign with a selector you publish:

selector._domainkey.example.co.uk.  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

The selector is a short name the provider chooses or lets you choose (google, s1, k1). The p= value is the public key. An empty p= is how you revoke a selector you have finished rotating away from.

What to do in practice:

• Turn on DKIM in every platform, and add the exact TXT record the platform shows you. Don’t invent a selector, and don’t trim the key.
• Prefer that the signature be aligned with the From domain. That is what DMARC needs. If a provider signs as mail.provider.example and never as example.co.uk, that mail will not pass DMARC on your domain unless you change the setup. This is the usual reason a “professional-looking” From address still fails.
• Keep the private key private. You never paste the private key into DNS. If a provider lets you upload your own key, store it like any other secret.
• Plan for rotation. When a provider offers a second selector, publish the new key first, switch signing, then retire the old p= value. Don’t delete a live selector the same day you switch.

If a platform cannot DKIM-sign as your domain, you have a decision: send as the provider’s domain (and be honest about it in the From header), or move that mail to a platform that can. Don’t paper over it by weakening DMARC.

DMARC: none, quarantine, reject — in that order

A DMARC record lives at _dmarc.your-domain:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk; fo=1

The important tags:

• p= is the policy for the domain: none (monitor), quarantine (treat as suspicious, often the junk folder), or reject (don’t accept the message).
• rua= is where aggregate XML reports should be sent. Use a mailbox you will actually look at, or a reporting service you trust. The mailbox’s domain must be willing to receive those reports; if it is on a different domain, you may need an authorizing record there.
• ruf= asks for forensic, per-message reports. Many receivers no longer send them, and they can contain snippets of mail. I usually start without ruf.
• adkim and aspf control how strict alignment is (r relaxed, s strict). Relaxed is the default and is enough for most small domains: a DKIM signature from mail.example.co.uk can still align with a From address on example.co.uk.
• sp= is the policy for subdomains, if you want it to differ from p=. If you do not send from subdomains, a tighter sp= can reduce spoofing on invented hosts.
• pct= applies the policy to a percentage of failing mail. It is a way to ease into quarantine or reject. Don’t use it as a permanent half-setting you forget about.

The safe order is always none, then quarantine, then reject. Stay on none until the reports show only senders you recognise, or spoofing you are content to block. Move to quarantine for a period, watch support mail and the reports, then move to reject. Skipping to reject on a domain that has a forgotten invoice system is how you spend a week chasing “your email bounced.”

DMARC is not a spam filter you apply to mail you receive. It is a policy you publish about mail that claims to be from you.

Several senders on a small UK domain

A typical small UK setup is messier than a lab example. It might include:

• Google Workspace or Microsoft 365 for the inbox and calendar
• A transactional provider for “someone used the contact form” and password-reset mail
• A billing or accountancy tool that sends invoices as you@your-domain
• A registrar or hosting mailbox you no longer use but that can still send
• A shop, mailing list or booking tool from a previous project

Write the list down before you edit DNS. For each sender, record: the From addresses it uses, whether it can DKIM-sign as your domain, and the SPF include it documents. Then:

1. Add every SPF include to the single record, and check the lookup count.
2. Enable DKIM on each platform that can sign as you.
3. Publish DMARC at p=none with an rua address.
4. Stop using, or reconfigure, anything that cannot authenticate and is not worth keeping.

Shared mailboxes and “send as” arrangements are a frequent hole. If a colleague sends as hello@your-domain from a personal Gmail account, that mail will not pass SPF or DKIM for your domain, and under a reject policy it will not arrive. The fix is to send through the domain’s actual provider, not to loosen the policy.

UK-specific logistics are ordinary ones: the DNS host is often a registrar with a slow TTL, so leave time between changes; someone else may already have added a partial SPF record years ago; and .co.uk is still just a domain in DNS, not a special mail regime. If you use a .gov.uk or similar public-sector domain, there may be additional expectations — follow the guidance that applies to that estate rather than this article.

Reports, alignment and the usual errors

Aggregate DMARC reports are XML summaries, usually daily, from receivers that choose to send them. They tell you, for a period: which source IPs sent mail claiming your domain, how much passed SPF, how much passed DKIM, whether those results were aligned, and what the receiver did. They do not include the full body of each message.

Read them for surprises, not for a perfect percentage. A burst of failing mail from random IPs is often spoofing, and is evidence that a reject policy would help. Failing mail from an IP you recognise is a sender you missed. A source that passes SPF but fails alignment is often a forwarder or a provider sending as you with the wrong envelope domain.

The Email Header Analyser is the right tool for a single message: paste the headers of a received mail (the ones your client can show as “raw” or “original”) and look at Authentication-Results, Received-SPF, DKIM-Signature and From. One authentic-looking newsletter is worth more than a guess about a record.

Usual errors:

• Two SPF records, or one SPF record plus a leftover “SPF” TXT that also starts v=spf1.
• A shadowed or stale record at the wrong name: spf.example.co.uk instead of example.co.uk, or a CNAME that hides the TXT you just added. The SPF, DKIM & DMARC Checker should be pointed at the exact domain in the From address.
• A DKIM record with a line break in the wrong place, or a Unicode lookalike in the key, so the signature never verifies.
• DMARC published, but rua mail going to a black hole, so you have no reports to justify a tighter policy.
• Forwarding that breaks SPF. This is expected. DKIM, if the forwarder does not alter the signed headers or body, is what still passes. If a mailing list rewrites the message, it may need to re-sign; that is the list operator’s problem as much as yours.

A rollout plan that does not strand mail

A sequence I am comfortable recommending to a small domain:

1. Inventory senders, including tools that only send once a month.
2. Publish or tidy SPF with ~all, one record, every include you need. Wait for DNS to propagate; check with a lookup from somewhere other than the registrar’s own DNS.
3. Enable DKIM on each platform, and send a test message from each one to an inbox you control. Read the headers.
4. Publish DMARC at p=none with an rua mailbox you monitor. Leave it there long enough to cover a billing cycle, not just a quiet weekend.
5. Fix or retire anything the reports show that you still want to arrive.
6. Move to p=quarantine, tell anyone who might receive your mail to look in junk folders for a week or two, and keep reading reports.
7. Move to p=reject, then change ~all to -all in SPF if you have not already and the reports still look clean.
8. Put a reminder in the same place you keep domain renewals, so a new tool cannot be added silently. New senders should be added the way a release is added after launch or a step is added to a launch process: as a deliberate change, not an afterthought. The habit is the same one I want in a privacy manifest: do not declare a sender, or a library, you do not actually use, and do not forget one you do.

Do not buy a “DMARC certificate” or a BIMI logo as a first step. BIMI is a later, optional overlay that depends on a sound DMARC reject policy and on the current logo and certificate requirements, which are a separate job.

How to check the live records

Before you declare the job done, and again after any DNS change:

• Look up the live TXT records for the domain, for selector._domainkey.the-domain, and for _dmarc.the-domain, from a public resolver, not only the DNS host’s control panel. The SPF, DKIM & DMARC Checker will do the obvious consistency checks.
• Confirm there is exactly one v=spf1 record, it ends with ~all or -all, and every current sender’s include is present.
• Send a test message from each legitimate platform to a Google mailbox, a Microsoft mailbox if you can, and one other. Inspect the headers with the Email Header Analyser.
• Confirm each test passes aligned DKIM, and that DMARC’s result is pass once you expect it to be.
• Confirm aggregate reports are arriving, and that you can name every source they show.
• If the domain has www or a common misspelling that people might type as a From address, decide whether those names need their own records or a policy that covers subdomains.

If a test fails, fix that sender before you tighten p=. A green dashboard on a DNS host is not the same as a message that authenticates.

Key takeaways

• SPF, DKIM and DMARC work together: SPF lists sending IPs, DKIM signs the message, DMARC applies a policy to the visible From domain and asks for reports.
• Publish one SPF record that includes every legitimate sender, and stay within the lookup limit.
• Turn on DKIM for each platform, aligned with the From domain you actually use.
• Roll DMARC from none to quarantine to reject only after the reports and your own test messages look clean.
• Recheck the live DNS and a sample of real headers whenever you add a sender.

If you want a second pair of eyes on a domain’s mail records, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.