DMARC, SPF and DKIM: stopping people spoofing your business
A supplier calls to check why an invoice “from you” has different bank details to usual. A customer forwards an email that looks exactly like it came from your own address, asking them to pay early. Neither email touched your inbox, your password or your computer. The scammer just wrote your domain into the From field, because for most businesses nothing stops them.
SPF, DKIM and DMARC are the three DNS records that close that gap. None of them are complicated once you see what each one actually checks, and most domains are missing at least one. This is a plain-English run-through of what they do, how to check where your own domain currently stands, and why the businesses that get burned are usually the ones that switched to full blocking too fast rather than the ones who never got round to it.
Why this is possible at all
Email was designed in the early 1980s, long before spam or phishing were a serious problem, and the protocol that moves mail between servers never checked who was allowed to put what in the "From" address. It still doesn't, by default. Writing invoices@yourcompany.co.uk into a From field is no different, technically, to writing any return address on a paper envelope. The receiving server delivers it anyway.
SPF, DKIM and DMARC were bolted on afterwards, standardised years apart, to close that gap. They give the server receiving your mail a way to check whether a message claiming to be from your domain was actually allowed to be sent that way, and a policy to follow when it wasn't.
SPF, DKIM and DMARC, in plain English
SPF (Sender Policy Framework) is a published list. It's a DNS TXT record on your domain naming every mail server allowed to send email for you: your own Microsoft 365 or Google Workspace servers, plus anything else that sends on your behalf, like Mailchimp or an invoicing platform. When a message arrives claiming to be from your domain, the receiving server checks the sending server's IP against that list. Not on it, not authorised.
DKIM (DomainKeys Identified Mail) works differently. Your mail server signs every outgoing message with a private cryptographic key, and the matching public key sits in a DNS TXT record at a selector under your domain (something like selector1._domainkey.yourcompany.co.uk). The receiving server checks the signature against that public key. A valid signature proves two things: the message really was signed by a system holding your private key, and it wasn't altered after signing. SPF checks the sending server. DKIM checks the message itself.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer sitting on top of both. It's a third DNS TXT record, published at _dmarc.yourcompany.co.uk, that does two things: it tells receiving servers what to do with a message that fails both SPF and DKIM alignment (do nothing, quarantine it, or reject it outright), and it asks those servers to email you a report of every message they saw claiming to be from your domain, pass or fail. That reporting is the part most people don't know exists, and it's the part that actually shows you who's sending as you.
One detail worth having right: DMARC only kicks in when a message fails both SPF and DKIM, and fails "alignment". The domain that passed has to match the domain in the visible From address, not just any domain the message touched somewhere along the way.
What no DMARC record actually means
If your domain has no DMARC record at all, which is still most small business domains, there is no policy for a receiving server to follow, so it makes its own decision, and most default to delivering the message. SPF and DKIM alone can catch some forged mail, but without DMARC nothing forces a receiving server to act on a failure, and you never find out it happened. The scam email lands in your customer's inbox looking exactly as legitimate as your real ones. Same name, same signature, same domain.
That's why spoofing hurts the impersonated business more than the victim. Your customer loses money or trust. You lose the relationship, and find out from an angry phone call rather than a report that would have flagged it months earlier.
Checking where your domain actually stands
You don't need to touch DNS to find out. Two free tools do the lookup and explain the result: MXToolbox's SuperTool (mxtoolbox.com) checks SPF, DKIM and DMARC in one search and flags syntax errors as well as missing records, and dmarcian's DMARC Inspector (dmarcian.com/dmarc-inspector) does the same specifically for DMARC and explains what each part of your record means. Type your domain in, not your email address.
Three outcomes, roughly: no DMARC record at all, the most common finding; a record present but sitting at p=none, watching but doing nothing; or one already at p=quarantine or p=reject, meaning someone beat you to it.
none, quarantine, reject: the three settings that matter
DMARC's policy tag has three values, and they're meant to be used in this order, not picked at random.
- p=none. Monitor only. Nothing about mail delivery changes. Every server that sees a message claiming to be from your domain still sends it on as normal, but it also emails an aggregate report back to an address you specify. This is how you find out, often for the first time, everything that currently sends mail as your domain.
- p=quarantine. Messages that fail SPF and DKIM alignment get routed to the recipient's spam or junk folder instead of the inbox. Delivery still happens, but the message is flagged as suspicious rather than trusted.
- p=reject. The receiving server refuses the message outright. It never reaches spam, junk or inbox. This is full protection, and it's also the setting that breaks things if you haven't done the groundwork first.
The UK's National Cyber Security Centre publishes anti-spoofing guidance that recommends exactly this sequence: start at none, move to quarantine once you're confident SPF and DKIM are configured correctly and every legitimate source is accounted for, and finish at reject. That's not caution for its own sake. It's the order that avoids the failure mode below.
Why rushing to p=reject breaks things
Almost no business sends all its email from one place any more. There's the main mailbox system, plus whatever else sends "from" your domain: Mailchimp, an invoicing platform like Xero or QuickBooks, a booking system, a CRM firing automated emails, sometimes a scanner set to email documents from an internal address. Every one of those needs adding to your SPF record or signing with your DKIM key, or DMARC can't tell it apart from a scammer.
Set p=reject before you've done that, and the receiving server can't tell your genuine Mailchimp newsletter from a phishing email pretending to be your Mailchimp newsletter. Both fail alignment. Both get blocked. Your customers stop receiving invoices, your marketing emails silently vanish, and the first sign is usually a client asking why they haven't been billed. Not an error message. There usually isn't one on your end.
The p=none monitoring phase exists specifically to prevent this. Run it long enough to see a full reporting cycle, including anything that only sends monthly or quarterly, before moving to quarantine, and don't move to reject until quarantine has run clean for a while with nothing legitimate landing in spam.
A realistic rollout
| Stage | What happens |
|---|---|
| Check current state | Run your domain through MXToolbox or dmarcian. Note what's missing: SPF, DKIM, DMARC, or all three. |
| Publish SPF and DKIM | List every server that legitimately sends as you. Turn DKIM signing on with your mail provider (Microsoft 365 and Google Workspace both support this natively). |
| Publish DMARC at p=none | Point the reports at an address you'll actually read, or a tool that parses them for you. Aggregate reports arrive as XML, not plain text. |
| Watch for a full cycle | A few weeks minimum, long enough to catch senders that don't run daily. Add each legitimate one to SPF or set it up with DKIM signing as you find it. |
| Move to p=quarantine | Once nothing legitimate is still showing as a failure in the reports. |
| Move to p=reject | Once quarantine has run clean. This is full protection: nothing unauthorised gets through as your domain again. |
Where we come in
Both our Professional (£77/user/month) and Complete (£108/user/month) managed IT plans on the pricing page include email security and anti-phishing as standard, alongside staff phishing-awareness training on Professional and above. Setting up SPF, DKIM and DMARC correctly, and reading the reports so the move to quarantine and reject actually happens instead of sitting at none indefinitely, sits inside that same email security work rather than as a separate line item.
What we won't do is promise a one-day fix. A domain with several sending sources genuinely needs the monitoring phase, and skipping it to look fast is how you end up blocking your own invoices. Our cybersecurity service covers this alongside endpoint protection and phishing training as one package, run by the same team as your day-to-day managed IT.
The short version
SPF lists who's allowed to send as you. DKIM proves a message wasn't altered and really came from your system. DMARC tells receiving servers what to do when both fail, and reports back who's sending as your domain either way. Most small business domains have none of the three, or a DMARC record sitting uselessly at p=none.
Check your own domain on MXToolbox or dmarcian before doing anything else. If there's nothing there, that's normal, and it's also exactly the gap a convincing fake invoice walks through. Fix it in order: none, then quarantine, then reject. It stays fixed rather than breaking your own mail on the way.
One thing this doesn't cover: a supplier or customer whose own domain isn't locked down the same way. Locking down yours stops criminals spoofing you outbound, but it does nothing to protect a payment you send to someone else's compromised mailbox. Our guide to business email compromise and invoice fraud covers that other half, including the one habit that actually stops it.
If you'd rather someone else read the reports and made the call on timing, the free IT health check is a reasonable starting point, or get in touch and we'll look at what your domain is currently sending as.
Frequently asked questions
What does it mean when someone “spoofs” your email address?+
It means an email lands in someone's inbox showing your name and your domain in the From field, when it was never sent by you or your mail server. The scammer doesn't need your password or access to your account. Email was built in the 1980s with no check on who's allowed to claim a From address, so anyone can type yours into an email header the same way anyone can write any return address on a paper envelope. SPF, DKIM and DMARC are the three checks that were bolted on afterwards to close that gap.
Do I need all three, or is one enough?+
You need all three to get real protection, because they check different things. SPF says which mail servers are allowed to send for your domain. DKIM proves a message wasn't altered in transit and really came from a system holding your private key. DMARC is the policy layer that ties the two together and tells the receiving server what to do when a message fails both. SPF or DKIM alone stops some spoofing. Only DMARC, published with a policy of quarantine or reject, actually blocks the rest and tells you it happened.
How do I check what my domain currently has?+
Free lookup tools do this without touching your DNS. MXToolbox's SuperTool and dmarcian's DMARC Inspector both check SPF, DKIM and DMARC for a domain and explain what's missing in plain English. If you don't see a DMARC record at all, or you see one set to p=none, your domain is currently wide open in the eyes of any receiving mail server. Attackers can send as you and nothing stops them or tells you it happened.
What's the difference between p=none, p=quarantine and p=reject?+
They're three settings in the same DMARC record, and they control what happens to a message that fails the checks. p=none does nothing to delivery; it just emails you a daily report of every server sending as your domain, which is how you find the legitimate ones before you block anything. p=quarantine routes failing mail to spam instead of the inbox. p=reject blocks it outright: the receiving server refuses the message. NCSC's own anti-spoofing guidance recommends exactly this order. Start at none, move to quarantine once you trust your setup, finish at reject.
Why shouldn't I just set p=reject straight away?+
Because you probably don't know every system that sends email as your domain until you look. Mailchimp, an invoicing tool, a booking system: if any of them send "from" your address and aren't authorised in SPF or signing with your DKIM key, a p=reject policy blocks your own marketing emails and invoices along with the scammers. Badly sequenced DMARC rollout is a well-documented cause of businesses losing real mail, sometimes for days, which is why the monitoring phase exists first.
How long does it take to get from nothing to p=reject?+
There's no fixed number, because it depends on how many services send mail on your behalf and how fast you can confirm each one. A realistic minimum is a few weeks: enough time at p=none to see a full reporting cycle covering your regular monthly and quarterly senders, not just the daily ones. Rushing it to save a week is how legitimate mail gets blocked; running the monitoring phase for six months because nobody read the reports is the more common failure in practice.
Can I set this up myself, or do I need an IT provider?+
The DNS records themselves are three lines of text. Publishing them isn't hard technically. Reading the DMARC aggregate reports correctly, working out which sending sources are legitimate, and deciding when it's safe to move from none to quarantine to reject is the part that goes wrong doing it alone, because the reports arrive as raw XML rather than anything readable.
Does DMARC stop phishing emails sent to me, or only ones sent as me?+
Only ones sent as you, or as any domain that also runs DMARC properly. It authenticates outbound mail from your domain and protects your name from being used in scams against your customers and suppliers. It does nothing for phishing that lands in your own inbox from a different, unrelated domain. That's a separate problem, handled by inbound email filtering and staff training, not DMARC.