I built a free email security check

A lot of my IT work is with small businesses, and one of the first things I look at for a new client is their email setup. Not the mailboxes, the DNS records behind them. More often than not there’s a gap: no DMARC record, an SPF record that doesn’t really protect anything, or DKIM that was never turned on.

Those gaps make it easy for someone to send an email that looks like it came from you. That’s how a lot of invoice fraud starts: a “new bank details” email from what looks like a supplier’s real address.

Checking takes a few DNS lookups, but most of the tools that do it are built to sell you a monitoring plan, and they explain the results in jargon. So I built a free one that explains things plainly and tells you exactly what to add.

The three records that matter

Email was designed in a time when nobody checked who a message was from. Three DNS records were added later to fix that:

• SPF is a list of the servers allowed to send email for your domain. If you use Microsoft 365, that’s Microsoft’s servers, plus anything else that sends as you, like a newsletter tool.
• DKIM puts a signature on every email. The receiving server checks it against a public key in your DNS, which proves the message came from you and wasn’t changed on the way.
• DMARC ties the two together. It tells receivers what to do with mail that fails, from doing nothing (p=none) to sending it to spam (p=quarantine) or refusing it (p=reject), and it sends you daily reports about who is sending email in your name.

DMARC is the one that actually stops fakes, and it’s also the one most often missing. Since 2024, Gmail and Yahoo require it from anyone sending more than about 5,000 emails a day, and Outlook.com followed in 2025.

What the tool checks

Type in a domain and it looks at:

• Mail servers, to work out who handles the domain’s email. It recognises Microsoft 365, Google Workspace and more than a dozen others, so the fixes it suggests match your setup.
• SPF. Whether there’s exactly one record, how it ends (-all and ~all are fine, ?all and +all aren’t), and how many DNS lookups it needs. Receivers stop at 10, and an SPF record that lists too many services quietly stops working. The tool follows every include: to count them.
• DKIM. Keys live under a name your provider picks (the “selector”), so the tool tries about thirty common ones, such as selector1 for Microsoft 365 and google for Google Workspace. It also estimates the key size, since older 1024-bit keys should be replaced. If yours uses another name, you can type it in.
• DMARC. The policy, whether it applies to all mail, whether someone gets the reports, and whether subdomains are covered.
• Extras: MTA-STS and TLS-RPT (making sure mail sent to you is encrypted), DNSSEC (signed DNS answers) and BIMI (your logo in the inbox). These are nice to have, so they’re marked as optional rather than as problems.

Every problem comes with the record to add: the type, the name, and a value you can copy straight into your DNS dashboard.

The first domain I checked was mine

It wasn’t perfect. When I first ran it, this site’s SPF record was v=spf1 +a +mx ?all, left over from my web host’s default settings. Two things are wrong with that:

• ?all at the end means “neutral”: mail from a server that isn’t on the list isn’t treated as suspicious at all, so the record doesn’t protect anything.
• +a allows the servers the website points to. Since the site moved behind Cloudflare, those are Cloudflare’s servers, which have nothing to do with my email.

It’s exactly the kind of leftover setting nobody notices until something goes wrong, which is the point of checking.

How it works

The whole check runs in your browser. The page asks Cloudflare’s public DNS for the records over HTTPS, with Google’s as a backup if Cloudflare doesn’t answer. There’s no server of mine in the middle, so there’s nothing to run, nothing to pay for, and nothing about the domains you check is stored.

A full check takes about 40 lookups and a couple of seconds. The lookups run in parallel and each answer is reused, so following a chain of SPF includes doesn’t ask for the same record twice.

All the logic that reads and judges records is in one file, separate from the page that draws the results. That made it easy to test: the tests feed it fake DNS answers for different kinds of domains (a well set up Microsoft 365 tenant, a Google Workspace domain on p=none, a parked domain that sends no mail, an SPF record with too many lookups) and check that it reaches the right verdict and suggests the right fix.

What it can’t see

• DKIM selectors it doesn’t know. There’s no way to list every DKIM key on a domain, so if yours uses an unusual name, the tool can say “not found” when DKIM is in fact set up. That’s why it’s marked “Improve”, not “Problem”, and why you can type in your own selector.
• The MTA-STS policy file. MTA-STS needs a DNS record and a small file on a web address. Browsers won’t let a page read files from other sites, so the tool checks the record but not the file.
• What happens to real mail. DNS shows the rules, not whether your mail passes them. For that you need the DMARC reports, which is why the tool nags you to set an address for them.

Try it

Run it on your own domain: furkanbayar.com/tools/email-check. If you’d like a hand with what it finds, email me.