Set up SPF, DKIM and DMARC for your email
Three acronyms your IT person keeps mentioning, and half your emails still land in the customer's spam folder. Here's what they actually do, and how to set them up yourself.
The short answer
You need three DNS records at your domain host: one SPF record listing every service allowed to send email as you, DKIM switched on wherever your mail actually lives (Google Workspace or Microsoft 365, plus any tool that sends on your behalf), and a DMARC record that starts in monitoring mode and only gets strict once its reports show your real mail passing. The steps below walk through all three; the order matters.
What the three records actually do
Think of the three as your email's ID papers. SPF lists which servers are allowed to send mail for your domain. DKIM adds a tamper-proof signature so the receiver knows the message wasn't forged or altered. DMARC ties the two together and tells Gmail or Outlook what to do when something doesn't check out, and can email you a report on who's sending as you.
Since 2024 the big providers have stopped being polite about missing records, with Gmail leading the way and Outlook following. If you send any volume and these aren't set up, your mail gets throttled, junked or bounced. Quotes, invoices and enquiry replies quietly stop landing.
1. See what your domain already has
Before adding anything, find out what's there. Run your domain through a free checker like MXToolbox or dmarcian's domain checker, or from a terminal:
You're looking for three things: a TXT record starting v=spf1 (there must be exactly one; two SPF records break both), a record at _dmarc.yourdomain.co.uk, and whether DKIM is already signing. Write down what exists. Half-finished records from an old IT company are more common than none at all.
nslookup -type=txt yourdomain.co.uk
nslookup -type=txt _dmarc.yourdomain.co.uk2. Write one SPF record that lists every sender
First make the list: your mailbox provider, plus everything else that sends email as your domain. Invoicing software, your newsletter tool, the website contact form, a booking system, even the office scanner. Each one you miss will fail later.
Then publish one TXT record at your domain root. For Google Workspace or Microsoft 365 the starting points are:
Add an include for each other tool on your list; every provider publishes theirs (search their help for "SPF include"). Two rules: keep it to a single SPF record, and stay under ten DNS lookups in total, because past ten, SPF silently stops working. The ~all ending is a soft fail, which is the right setting until you've tested.
v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com ~all3. Turn on DKIM where your mail lives
In Google Workspace: Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Generate the record (choose 2048-bit), add the TXT record it gives you at your domain host, wait for DNS to catch up, then come back and press Start authentication.
In Microsoft 365: sign in to the Defender portal at security.microsoft.com, find Email authentication settings, then DKIM. Select your domain and it shows two CNAME records; add both at your domain host, then flip the toggle on.
Then do the same for the other senders on your list. Newsletter and invoicing tools usually call it "domain authentication" or "verify your domain" in their settings, and give you their own records to add. A tool that sends as you without DKIM will start failing the moment DMARC gets strict.
4. Add DMARC in monitoring mode first
Publish a TXT record named _dmarc at your domain with this value:
p=none means observe and report, punish nothing. The rua address is where aggregate reports arrive, usually once a day per provider. They're XML and fairly unreadable raw; a free tool like dmarcian's XML-to-human converter translates them, or you can simply watch for a couple of weeks and see which services show up. The reports are the whole point of this stage: they name every sender you forgot in step 2.
v=DMARC1; p=none; rua=mailto:[email protected]5. Test with real messages
Send a normal email to a Gmail address you control. Open it, choose Show original from the three-dot menu, and check the summary at the top: SPF, DKIM and DMARC should each say PASS. Do the same to an Outlook address if you can.
Then test the senders that aren't your mailbox: trigger a real invoice from your invoicing tool and a message from your website's contact form, and check those pass too. A live tracer like learndmarc.com shows the whole journey if you want the detail.
6. Tighten the policy once the reports are clean
After a few weeks of reports showing only legitimate senders passing, change p=none to p=quarantine (suspect mail goes to spam), and later to p=reject. This is the step that actually stops anyone spoofing your domain, and it's the step most setups never reach; p=none forever is the most common half-finished state on the internet.
Tighten only when the reports say your real mail is clean. Go strict too early and it's your own invoice run that lands in junk.
Where this gets hard
The usual trap isn't the syntax, it's the sender nobody remembered. The website form, the till, the scanner that emails PDFs, the workshop booking tool: each fails quietly once you tighten, and the only warning is a line in an XML report.
The ten-lookup limit bites busy setups. Each include can cost several lookups, popular tools stack up quickly, and past the limit SPF returns a permanent error that looks exactly like it's working until a big provider decides it isn't.
And every third-party tool has its own dance: some want CNAMEs, some want TXT records, some both, and support pages don't always match what their dashboard actually generates. None of it is difficult in isolation; it's the coordination, and knowing when it's safe to tighten, that eats the time.
What you end up with
- One SPF record listing every legitimate sender, and nothing else
- DKIM signing on in Google Workspace or Microsoft 365, and in every tool that sends as your domain
- DMARC watching in monitoring mode, tightened to quarantine or reject only once the reports prove your real mail passes
- Proof in hand: real messages to Gmail and Outlook showing three green passes
Facts on this page last checked 14 July 2026, against support.google.com, learn.microsoft.com, dmarc.org.
Related fixes
If you'd rather not touch DNS at all, or you made it to the reports stage and the XML defeated you, this is exactly the kind of bounded job I take on: I run the checks, publish the records, watch the reports and only tighten when your real mail is provably clean.