Free tool
Could someone send email as your company?
Check your domain's SPF, DKIM and DMARC in seconds, plus MX, DNSSEC, MTA-STS and TLS reporting. Live DNS answers, plain-English verdicts, and no sign-up.
Email & DNS health checker
Enter your domain (for example yourcompany.co.uk) and we'll check MX, SPF, DKIM, DMARC, DNSSEC, MTA-STS and TLS-RPT, live, in plain English.
Lookups run live from your browser against public DNS resolvers (Cloudflare, with Google as fallback) over encrypted DNS. Nothing you type here is sent to our servers, and we don't record the domains you check. DKIM detection probes common selector names, so a custom selector may need testing by hand above.
Why these records matter
- Spoofing is the front door. Without SPF and DMARC, anyone can send email that says it's from your domain. Fake invoices to your customers, fake instructions to your finance team.
- Deliverability is the flip side. The same missing records get your genuine mail junked. Google and Microsoft now require SPF or DKIM from every sender, and DMARC for bulk senders.
- Broken counts the same as missing. Two SPF records, or one that's over the 10-lookup limit, fails validation permanently. Plenty of domains are 'protected' by a record that doesn't work.
- Insurers and auditors ask. Email authentication questions are now standard on cyber insurance forms, and spoofing resistance supports your Cyber Essentials story.
From none to reject
Fixing it is easy. Fixing it safely is the job.
Every red mark above is a small DNS change. The craft is making those changes without junking a single legitimate email on the way.
The trap of doing it quickly
Most businesses send email from more places than they think: the accounts package, the CRM, the helpdesk, a mail-merge tool, a photocopier. Publish a strict SPF record or jump straight to DMARC p=reject without finding them all, and those systems silently stop delivering. That's why so many domains sit at p=none forever; someone got burned once. The fix is sequencing, not bravery.
How we do it properly
We inventory every legitimate sender first, publish SPF and DKIM to cover them, then turn on DMARC in monitoring mode and actually read the reports. When they run clean, we ratchet the policy to quarantine and then reject, and your domain becomes very hard to impersonate. It's part of how we run modern workplace environments, and it supports Cyber Essentials and insurance renewals too.
Questions
About this tool
In one line each: SPF is the guest list, a DNS record naming the servers allowed to send email for your domain. DKIM is the signature, a cryptographic stamp proving a message really came from you and wasn't altered. DMARC is the bouncer, telling receivers what to do when a message fails those checks (deliver it anyway, junk it, or reject it) and sending you reports about who is sending as your domain.
Straight from your live DNS, the same records every mail server in the world sees. The lookups run from your own browser over encrypted DNS to Cloudflare's public resolver, with Google's as a fallback. Nothing you type reaches our servers and we don't record the domains you check.
p=none is monitoring mode: you get reports about who is sending as your domain, but spoofed mail is still delivered as normal. It's exactly the right place to start, because the reports tell you whether any legitimate sender would break under a stricter policy. But parked there permanently, it protects nobody. Once your reports look clean for a few weeks, move to p=quarantine, then p=reject.
Not necessarily. DKIM keys live at a named 'selector', and a selector can be called anything, so no tool can find every one. We probe the common names used by Microsoft 365, Google Workspace, SendGrid, Mailchimp and others, which covers most businesses. If yours is custom, your mail provider can tell you the selector name and you can test it directly in the tool.
It removes the most common cause. SPF, DKIM and DMARC are now baseline requirements at Gmail and Microsoft, so getting them right is necessary, though not always sufficient: content, sending volume and list quality matter too. What we can say is that a domain failing these checks will have deliverability problems; it's just a question of when.
Yes. Getting these records right is routine work for us, and the tricky part is doing it without disrupting legitimate mail: finding every system that genuinely sends as your domain (the payroll platform, the CRM, the scanner in the corner) before tightening the policy. We audit what's sending, publish the records in the right order, watch the DMARC reports, then ratchet up to p=reject safely.
Red marks on your domain?
We'll find everything that legitimately sends as you, fix the records in the right order, and get you to DMARC reject without losing a single real email.