Could someone send an email that looks exactly like it came from your business?
Three small settings decide whether someone can pretend to be your business by email, and whether your own genuine email lands in the inbox or the junk folder. They are called SPF, DKIM and DMARC.
They are free, built into Microsoft 365 and Google Workspace, and the basics take about five minutes to switch on. Most setups we look at are missing at least one. No sales pitch and no jargon: this page shows you what they are, the real risk, and exactly what to fix or hand to your IT.
Run my free email security check ↓Right now, someone could probably send an email as you
Here is the uncomfortable bit, stated plainly. If your domain has no SPF record and no DMARC policy set to enforce, anyone can send an email that displays your domain in the visible From address, the address you actually read in your inbox. No hacking. No access to your mailbox. No clever toolkit. The way email works, a sender can simply state any From address they like, and if nothing on your domain says otherwise, the message lands looking genuine.
That means a fraudster could send a message that appears to come from your finance director asking for an urgent payment, or from you asking a supplier to update their bank details. The reader has no easy way to tell it apart from the real thing. This is the engine behind invoice fraud and CEO scams, and an unprotected domain is the easiest possible target. (To be clear, when we run a check for someone, it is read-only: it reads your public records and never sends mail as you.)
One important nuance, because half-measures give a false sense of safety: SPF on its own does not close this gap. SPF only checks a hidden address behind the scenes, not the From line you actually see. So even a domain with SPF set up can still have its exact address forged unless DMARC is published and set to quarantine or reject. The combination that genuinely stops someone forging your exact domain is SPF and DKIM working together with DMARC turned up to enforcement. Set up all three. We will explain each below.
Check your own domain first
Read-only and instant. Enter your work email and we will read your live public records, then explain each result in plain English. Nothing is changed, and nothing is sent as you.
Enter your work email. We'll check your live email security and show you exactly what's exposed, in plain English.
SPF, DKIM and DMARC, demystified
These are the minimum to stop someone spoofing your email. Two of them are free, built in and quick. The third is the one that actually does the blocking, and the one most often left half-done.
A guest list on the door: if a server is not on the list, it does not get to send mail in your name.
SPF (Sender Policy Framework) is a short record in your domain's DNS, the public address book for your website and email. It lists the mail servers that are allowed to send email for your domain. When a message arrives, the receiving server can check it against that list.
A wax seal on a letter: if the seal is intact, the recipient knows it came from you and was not opened or altered on the way.
DKIM (DomainKeys Identified Mail) adds an invisible, tamper-proof signature to every email you send. The receiving server checks that signature against a key published in your DNS, which proves the message genuinely came from your domain and was not altered in transit.
The instruction the bouncer enforces. A smoke alarm set to 'monitor only' is just a smoke alarm with the speaker disconnected: it notices the fire but warns nobody.
DMARC (Domain-based Message Authentication) ties SPF and DKIM together. It tells receiving mail servers what to do with a message that fails the checks, and it sends you back reports showing who is sending mail in your name. It is the piece that requires the visible From address you read to line up with an authenticated sender.
Two extra layers worth knowing about (also free to set up)
MTA-STS is a rule that forces email being sent to your domain to travel encrypted, so it is much harder to quietly intercept or downgrade in transit. It is two pieces: a small DNS record, plus a short policy file served over HTTPS at a web address on your domain. It is meaningfully more work than SPF or DKIM because that policy file has to sit on a web address with a valid security certificate, and your mail platform will not host it for you (Microsoft 365 explicitly does not).
There is no licence fee. The only potential cost is hosting that small policy file, which can be done for free using something like a Cloudflare Worker or an Azure Static Web App. Best practice is to start in testing mode and switch to enforce once it is validated. Fresh Tech sets this up and includes it for clients.
DNSSEC is cryptographic protection for your DNS records themselves, so criminals cannot forge your DNS to hijack your email or your website. It has also gained a sharper edge recently: from 15 March 2026, certificate authorities must validate DNSSEC whenever a domain has it switched on. If your domain has no DNSSEC, nothing changes and your security certificates carry on as normal. But if DNSSEC is switched on and set up wrongly, it can now block your website's security certificate from renewing. The takeaway is not 'rush to turn it on', it is 'if it is on, it must be done properly'.
It is free to switch on at most mainstream DNS providers and registrars. With Cloudflare it is effectively one click on any plan, including the free one, and providers like Namecheap and Porkbun make it straightforward too. The honest caveat: not every budget registrar makes it easy, so on a cheaper provider it can be more fiddly. Fresh Tech sets this up properly and monitors it for clients, rather than leaving it half-done.
This is not just security. It is whether your own email gets delivered
In February 2024, Google (Gmail) and Yahoo rolled out new requirements for the people who send email to their users. They are still in force in 2026, and enforcement has tightened, not relaxed. Microsoft followed with the same baseline for its consumer mailboxes (outlook.com, hotmail.com, live.com), enforced from 5 May 2025.
Here is how the rules actually break down, so you know where you stand. Every sender into Gmail and Yahoo needs at least SPF or DKIM. The full SPF, DKIM and DMARC requirement becomes a hard mandate once you are a bulk sender, defined as sending around 5,000 or more messages a day to those providers' personal mailboxes. Most small businesses are nowhere near that line, so the strict mandate may not apply to you directly.
But, and this is the part that matters for everyone, the same checks now drive how all three providers judge whether your everyday email is trustworthy. Even well below the bulk threshold, weak or missing SPF, DKIM and DMARC make your own genuine email more likely to land in customers' spam folders. So this is not only about stopping impersonators. It is about your quotes, invoices and replies actually reaching the inbox.
The direction of travel is one way. Google moved from temporarily delaying non-compliant bulk mail to rejecting it outright in late 2025. Microsoft routes non-compliant high-volume mail (around 5,000 or more messages a day to its consumer mailboxes) to the Junk folder and has said outright rejection will follow. Across all three providers, authentication is becoming the baseline for getting delivered at all.
How to fix the basics yourself (or hand these steps to your IT)
The basics, SPF and DKIM, really are about a five-minute job for whoever runs your email and DNS. You do not need to be technical to understand what should happen; you just need to know what to ask for. Here is the short version. One honest note up front: getting DMARC all the way to enforcement is the one part that is not five minutes, and that is covered in its own section below.
DMARC: the one that actually blocks impersonation, done properly
Publishing a basic DMARC record is itself quick: one TXT record. The trap is leaving it on p=none, which is monitor only. At p=none, DMARC reports who is sending as your domain but tells receivers to take no action, so it blocks nobody. Google and Yahoo accept p=none as a starting point to clear their check, which is fine, but clearing the mailbox-provider minimum is not the same as being protected. Monitor only is the floor, not the goal.
To actually stop someone forging your exact domain, the policy has to move up to p=quarantine (fakes go to spam) and then p=reject (fakes are refused outright). That is the part that needs care, because rushing it can block your own legitimate email. The safe approach is to publish DMARC, collect reports for a monitoring period, identify and fix every genuine sender (your accounts software, newsletter tool, CRM and the like), then tighten the policy in stages. A sensible monitoring window is usually several weeks to a few months.
The good news is you can monitor DMARC for free. Cloudflare's DMARC Management tool turns the raw report XML into a readable dashboard showing which senders are passing or failing, and it is free with no report or domain limits for anyone using Cloudflare DNS (including the free plan). It is not the only option: Postmark offers a free weekly DMARC digest by email, and Valimail and dmarcian both have free tiers. Free tiers vary, some give a full dashboard, others just a weekly summary, and some cap the number of domains.
This staged rollout to full enforcement is exactly the sort of thing that gets started and then forgotten on a monitor-only setting. Fresh Tech includes DMARC management for every client: we get it to enforcement safely and keep an eye on the reports so it stays there.
Questions worth asking whoever looks after your IT
None of this is an attack on whoever set your domain up, including if that was you. It is genuinely invisible until something goes wrong, and it is easy to overlook. Think of the list below as what good looks like. If any answer is a no or an 'I'm not sure', treat it as an opportunity to sort one quick thing, not a panic. For what it is worth, this is exactly the sort of thing we pick up on day one when we onboard a new client, so finding a gap here is normal, not a disaster.
- 1Do we have an SPF record published, and does it list every service that sends email for us?
- 2Is DKIM switched on for our own domain, not just the default onmicrosoft.com or Google address?
- 3Do we have a DMARC record, and is it set to quarantine or reject rather than left on monitor only (p=none)?
- 4If DMARC is on monitor only, what is the plan and timeline to move it safely to enforcement?
- 5Are we keeping an eye on our DMARC reports, so we know who is sending as us?
- 6Have we set up MTA-STS and DNSSEC, the two extra free layers, or is there a reason we have not yet?
- 7It can be reassuring to see SPF, DKIM and DMARC all passing on our own domain; a free checker will show this, or our IT can confirm it for us.
The next layer up: catching the fakes authentication cannot
The free DNS records (SPF, DKIM and DMARC) stop other people forging your exact domain and help your own mail get delivered. That is the foundation, and it is genuinely the basics. But there is a layer above it that catches the close-but-not-exact fakes, the ones that do not use your exact domain and so slip past authentication entirely.
This is where Microsoft 365 Business Premium earns its place. It includes Microsoft Defender for Office 365 Plan 1 as standard, on top of the basic anti-spam and spoofing protection that comes with every mailbox. That adds impersonation protection: it can spot an attacker pretending to be a specific person (for example a fake message in your finance director's name) or using a lookalike domain (for example fresh-teoh.uk in place of fresh-tech.uk), and act on those messages. It also adds Safe Links, which re-checks a link at the moment you click it and blocks it if it has turned malicious, and Safe Attachments, which opens incoming attachments in a sealed sandbox first to catch brand-new malware.
Business Premium also includes Microsoft Entra ID P1, which brings Conditional Access: sign-in rules such as requiring multi-factor authentication or blocking logins from unrecognised devices, so a stolen password alone is much less likely to get someone in. In short: the free DNS records harden your domain; Business Premium hardens the mailbox and the login. We cover how it compares on our Microsoft 365 Business Premium page. One honest note: impersonation protection is not configured by default, an admin has to set it up, which is, again, exactly the kind of thing we sort on day one.
Want to know where your domain actually stands?
If you would like to check your own setup, our free email security check tests your live domain in about twenty seconds: the three core settings (SPF, DKIM and DMARC) plus the two extra layers (MTA-STS and DNSSEC), with each result explained in plain English. It is read-only, so it changes nothing. If you would rather we confirmed the findings and sorted any gaps for you, book a quick call and we will walk you through it. No hard sell: most people just want to know whether the door is open. You can also read the deeper explainer on how SPF, DKIM and DMARC work, or, if you are worried about invoice and payment fraud specifically, our guide to business email compromise.
Prefer to talk? Call 01584 517 234.