Email security checker
Find out whether somebody could send an email pretending to be your business — and whether your own mail is quietly failing authentication and landing in junk folders.
We read public DNS records only. Nothing is scanned, logged or sent anywhere — the check runs inside your own browser.
What the checker looks at
Three DNS records decide whether a receiving mail server trusts a message that claims to come from your domain. Most businesses have one or two of them, set up years ago by whoever moved them onto Microsoft 365, and never looked at since. They do not fail loudly. They just quietly stop working.
SPF
SPF is a public list of the servers allowed to send email using your domain name. When a message arrives, the receiving server checks whether it came from one of them. The catch is that SPF is evaluated by following a chain of DNS lookups, and it is allowed a maximum of ten. Records drift past that limit as a business adds a CRM, a payroll system, a marketing tool — and once past it, the whole check is abandoned and treated as a failure.
DKIM
DKIM adds a cryptographic signature to every message you send, which the receiving server verifies against a key published in your DNS. Because the signature travels with the message, DKIM survives forwarding in a way SPF does not. It is usually switched on by your mail provider, and just as often left switched off because nobody was asked.
DMARC
DMARC is the instruction that makes the other two mean something. It tells receiving servers what to do when a message fails SPF and DKIM: monitor it, send it to junk, or refuse it outright. Without a DMARC record, a message that fails every check will usually still be delivered. This is the single most common gap we find, and the one that makes impersonation possible.
Why this matters more than it sounds
The obvious risk is impersonation. If your domain publishes no enforcing DMARC policy, anyone can send an email that appears — to the recipient and to their mail software — to have come from your business. The usual version is an invoice with changed bank details sent to one of your customers, or a request to a colleague from someone who appears to be a director. Nothing about the message looks wrong, because technically nothing is wrong.
The less obvious risk runs the other way. When your own SPF record is broken, legitimate mail from your business starts failing authentication — quotes, invoices, replies to customers — and lands in junk folders without anyone being told. Businesses often spend months assuming customers are ignoring them.
The ten lookup limit that quietly breaks SPF
This is worth singling out, because it is the fault we find most often and almost nobody knows to look for it. Every include in an SPF record counts towards a limit of ten DNS lookups, and so does everything nested inside those includes. A single entry for a large provider can pull in five or six on its own.
Nothing warns you when you cross the line. The record stays in your DNS, looks perfectly reasonable, and is silently discarded by every mail server that reads it — so a domain that appears to be protected has none at all. The checker above counts the full chain and tells you the number.
Common questions
Is it safe to run this check on my own domain?
Yes. The checker only reads public DNS records — the same ones any mail server in the world reads every time you send a message. Nothing is scanned, no connection is made to your systems, and no port is touched. The whole check runs inside your browser.
Do you store the domain or the results?
No. There is no account, no email address and no database. The results exist in the page you are looking at and disappear when you close it.
I use Microsoft 365. Is this not already handled?
Partly. Microsoft 365 will usually set up SPF and can sign with DKIM, but it does not publish a DMARC record for you, and it has no way of knowing about the other systems that send mail as your domain. The gaps we find are almost always in businesses that assumed their mail provider had taken care of it.
What DMARC policy should we aim for?
Reject, eventually. The sensible path is to publish p=none first and read the reports, confirm every legitimate sender is passing, then move to quarantine and finally to reject. Jumping straight to reject on a domain whose SPF is wrong will stop your own mail.
How long does it take to fix?
For most small businesses the DNS changes themselves take minutes. The work is in the checking beforehand — finding every system that legitimately sends as your domain, so that enforcing a policy does not block something you depend on. A fortnight of monitoring is typical before moving to enforcement.
Can I check a domain that is not mine?
You can, and so can anyone, because these records are public by design. It is worth checking the domains of suppliers who send you invoices — if theirs is unprotected, an email appearing to come from them is trivial to forge.
Worth a look next: the Microsoft 365 security check looks inside your own tenant at multifactor coverage, legacy authentication and admin accounts, our Cyber Essentials readiness checker covers the twenty controls behind certification, and the learning centre has practical guides on phishing, backups and Microsoft 365.