For businesses
SPF and DMARC for a small business: stop fake invoices in your name
SPF and DMARC for a small business are two DNS records that tell receiving mail servers which servers may send email from your domain and what to do with mail that fails the test. Without them anyone can send “our bank details have changed” to your customers from an address that looks exactly like yours. Setting both up takes about 30 minutes, costs nothing, and is visible to anyone who checks your domain — including a SafeToPay report.
Key facts
- SPF lists the servers allowed to send mail for a domain (RFC 7208); DKIM signs each message so tampering is detectable (RFC 6376); DMARC tells receivers what to do when both fail and where to send reports (RFC 7489).
- Since February 2024 Google and Yahoo reject or junk mail from domains with no SPF or DKIM, and require DMARC from bulk senders (Google and Yahoo sender requirements).
- The National Cyber Security Centre recommends every UK organisation publish SPF, DKIM and DMARC, and mandates DMARC with a reject policy for government domains (NCSC email security guidance).
- “Changed bank details” invoice fraud is an authorised push payment scam: the customer sends money to the wrong account willingly. Reimbursement rules cap the victim’s claim at £85,000 and depend on the bank, not on you (Payment Systems Regulator APP reimbursement requirement, October 2024).
- SafeToPay reads MX, SPF and DMARC for every checked domain and shows them under Email security; a business using only a free mailbox (Gmail, Outlook.com) is flagged as “free mailbox only” (methodology v1.2).
Why a deposit depends on your DNS
The most common way a genuine job loses a deposit is an email from “you” telling the customer to pay a different account. The customer has your quote, trusts your name, and transfers to the fraudster; by the time the real invoice arrives the money is gone, and the customer — not the fraudster — has to argue with their bank. The email that did it was sent from a domain that looked like yours, or, if your domain has no SPF and DMARC, from your actual domain name.
Customers are now told to phone the number on the original quote before paying any “new” account, and banks check payee names against account names before a transfer. Neither depends on you. What does depend on you is whether a message forged in your name reaches the customer’s inbox at all: with SPF and DMARC set to reject, most receiving servers drop it before anyone sees it. The consumer’s side of this is in the changed bank details guide.
SPF, DKIM, DMARC: what each one does
The three records answer three separate questions — who may send, was it altered, and what to do if either check fails — and a domain needs all three for the last one to mean anything.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Question it answers | Is this server allowed to send mail for this domain? | Was this message signed by the domain and unaltered since? | If SPF or DKIM fails, what should the receiver do — and who gets told? |
| Record type | TXT at the domain root | TXT at selector._domainkey; the mail provider generates the key | TXT at _dmarc |
| Example | v=spf1 include:spf.protection.outlook.com -all | Provided by Microsoft 365 or Google Workspace when DKIM is enabled | v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.co.uk |
| Without it | Any server can claim to send from your domain | Messages can be modified in transit without detection | Failures are ignored; forged mail is delivered as normal |
| Checked by | Every major receiving server; any DNS lookup | Receiving servers | Receiving servers; any DNS lookup — including a SafeToPay check |
SPF: the list of who may send
One TXT record listing the sending services you use, ending in -all (fail everything else) or ~all (soft-fail). Every service that sends as your domain has to be in it — your mail provider, your invoicing software, your website contact form — or its mail will start failing. Ten DNS lookups is the limit, which is why the record uses include: for each provider rather than listing servers.
DKIM: the signature
Your provider signs outgoing mail with a private key and publishes the public key in DNS. Receivers verify the signature; a message altered after sending fails. Microsoft 365 and Google Workspace both generate the records for you — enabling DKIM is a switch in the admin console and two DNS entries.
DMARC: the instruction and the reports
DMARC ties the other two to the visible From address and tells receivers whether to deliver, quarantine or reject mail that fails. It also sends daily aggregate reports to the address you nominate, which is how you find out that a service you forgot about is sending as your domain — or that someone else is trying to.
Look-alike domains are a different problem. SPF and DMARC protect your domain. A fraudster who registers smithkitchens-ltd.co.uk is not stopped by your DNS; what stops that is the customer phoning the number on the quote. Do both: protect your domain, and put “we will never change our bank details by email — always call the number on your quote” on every invoice.
DMARC policy stages
DMARC is rolled out in three stages so that a mistake in SPF does not block your own invoices; most small businesses can go from none to reject inside a month.
| Policy | Record | Effect on forged mail | Stay here for |
|---|---|---|---|
| Monitor | p=none | Delivered; you receive reports | 1–2 weeks: read the reports, fix any legitimate sender missing from SPF |
| Quarantine | p=quarantine | Sent to spam | 2 weeks: confirm no legitimate mail is quarantined |
| Reject | p=reject | Refused by the receiving server | Permanently — this is the state a check reads as protected |
A record at p=none is better than nothing because it exists and it reports, but it does not stop anything; a check shows it as “DMARC: monitoring only”. The protection starts at quarantine and is complete at reject.
Setup for Microsoft 365 and Google Workspace
The whole job is four DNS records at your domain registrar or DNS host and one switch in the mail admin console; the values below are the standard ones and only the reporting address changes.
- List every service that sends as your domain: mail provider, invoicing or accounting software, website forms, any newsletter tool. Each needs an
include:in SPF or its own DKIM. - Publish SPF as a TXT record at the root of the domain. Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all. Google Workspace:v=spf1 include:_spf.google.com -all. Add the other services’ includes before-all. Only one SPF record per domain. - Enable DKIM in the admin console (Microsoft 365 Defender → Email authentication; Google Admin → Apps → Gmail → Authenticate email) and add the two CNAME or TXT records it gives you. Wait for it to show as active.
- Publish DMARC at monitor: TXT at
_dmarc.yourdomain.co.ukwithv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.uk. Create the mailbox or forward it. - Read the reports for two weeks, add any missing legitimate sender to SPF, then change to
p=quarantine, then after two more weeks top=reject. - Stop using free mailboxes for the business. A Gmail address on the quote cannot be protected by any of this, and a check flags it. Mail on your own domain, with these records, is the fix.
- Re-run the free check. Email security shows the provider, SPF, DMARC and its policy as read from DNS at that moment.
Two real domains
Both from live checks; names withheld.
Manufacturer on Microsoft 365, SPF present, no DMARC
Own domain, business mail through Microsoft 365, a correct SPF record — and no _dmarc record at all, which meant SPF failures were being ignored by receivers. The report showed the gap under Email security without affecting the verdict; the business added DMARC at monitor the same week and moved to reject a month later. Total cost: one DNS record and a mailbox for the reports.
Home improvement trader, Gmail only
No company matched, no address, a mobile number and a free Gmail address as the only contact. There is no domain to protect, so nothing in this guide applies — and that is the point. A customer receiving a “new bank details” email from a Gmail address has no way to tell it from the original, and a check has no DNS to read. Flagged as “free mailbox only” alongside the other gaps.
Enter a website address, e.g. smithkitchens.co.uk
Show that your invoices can be trusted
Email security is one of the few trust signals a customer cannot see on your website but a check reads directly from DNS, so it belongs in the record you show them. The free verified business badge links from your website to your full public report, where SPF, DMARC and the mail provider appear as verified lines under Email security, next to the registered company and the address checks described in how to prove your business is legitimate. And put the sentence on every invoice: we never change bank details by email.
Enter a website address, e.g. smithkitchens.co.uk
Frequently asked questions
Is SPF alone enough?
No. SPF only lists permitted servers; without DMARC a receiver is free to ignore an SPF failure, and most do. SPF plus DMARC at reject is the minimum that actually blocks forged mail; DKIM is needed alongside so that forwarded mail from your own domain still passes.
Will DMARC block my own emails?
Only if a service you use is missing from SPF and unsigned by DKIM — which is exactly what the monitor stage exists to catch. Start at p=none, read the reports for two weeks, add anything missing, then tighten. Done in that order, legitimate mail is unaffected.
Does this stop look-alike domains?
No. SPF and DMARC protect your own domain name; a fraudster registering a similar domain is stopped only by the customer checking — by phoning the number on the original quote. Tell customers on every invoice that you never change bank details by email.
What is the £85,000 reimbursement rule?
Since October 2024 UK banks must reimburse most victims of authorised push payment fraud up to £85,000 per claim, subject to conditions and a possible excess. It protects the customer, not you, and it does not restore a job that fell through because the deposit went to a fraudster.
How do I check my own records?
Any DNS lookup tool shows TXT records for your domain and for _dmarc.yourdomain. The free SafeToPay check reads them the same way and shows the mail provider, SPF, DMARC and its policy under Email security.
Does a Gmail or Outlook.com address for the business affect a check?
Yes. A free mailbox as the only business email is flagged as “free mailbox only” and counts against the record, because it cannot be tied to the company or protected by DNS. Mail on your own domain with SPF and DMARC is what a check reads as protected.
Sources
- NCSC — Email security and anti-spoofing guidance (SPF, DKIM, DMARC)
- RFC 7208 — Sender Policy Framework · RFC 6376 — DKIM · RFC 7489 — DMARC
- Google — Email sender guidelines
- Microsoft — Email authentication in Microsoft 365
- Payment Systems Regulator — APP scams reimbursement requirement
- SafeToPay methodology v1.2 — Email security