Free email security checker
Enter your domain or any work email address to see whether criminals can send mail in your organization's name. We read the public SPF, DKIM and DMARC records, grade them, and explain how to fix each gap.
How to read the results
The grade answers one question: how hard is it for someone else to send email that appears to come from your domain? Three DNS records decide most of it. SPF lists the servers allowed to send for you. DKIM signs each message so receivers can tell it was not forged or altered. DMARC ties both to the address people see in the From line and tells receiving servers what to do with mail that fails: deliver it anyway (p=none), send it to spam (quarantine) or refuse it (reject).
DMARC enforcement and a single valid SPF record carry the most weight. An A needs DMARC at reject; quarantine tops out at B, and a domain still at p=none, or with a missing or broken SPF record, cannot score above C, because forged mail can still reach inboxes. The most common SPF failure is the 10-lookup limit: every include, a, mx, ptr, exists and redirect costs a DNS lookup, including the ones inside your vendors' records, and past ten the whole record fails.
DKIM is the one record nobody can list from the outside. Each sending service picks its own selector name, so we try the common ones, including selector1 and selector2 for Microsoft 365 and google for Google Workspace. If none turns up, check your mail platform's settings before assuming DKIM is off. MTA-STS, TLS reporting and BIMI are optional extras that add a few points or none.
These records decide delivery as well as security: Google requires SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to Gmail accounts, and Yahoo sets the same baseline for bulk senders. Reaching reject safely means first finding every system that sends as you, from the CRM to ticketing, billing and newsletters. Our email security service does that inventory and moves the domain to enforcement, and Microsoft 365 management keeps DKIM and the tenant configured.
About the Email Security Checker
Is this a scan of our mail system?
No. It only reads public DNS records that anyone can look up: MX, SPF, DMARC, DKIM keys at common selectors, MTA-STS, TLS reporting and BIMI. It never connects to your mail servers, sends a message or logs in, so it is safe to run on any domain, including a vendor's.
Why does it say DKIM was not found when we have it set up?
DKIM keys are published under a selector name chosen by each sending service, and DNS offers no way to list them. We try the selectors common platforms use. If yours uses a different name, the check cannot see it, so confirm in your mail platform's settings before changing anything.
Is p=none good enough?
It is a starting point, not protection. With p=none, receivers send you reports but deliver forged mail as normal. It satisfies the bulk-sender baseline at Google and Yahoo, but stopping spoofing takes quarantine or reject. Move up once your reports show every legitimate sender passing.
Which domains should we check?
Every domain that sends mail, and every one you own that does not. Organizations with several brands, departments or agencies often have older domains nobody watches. A domain that never sends should publish v=spf1 -all and a DMARC record at p=reject, which this check recognizes and rewards.
What do you do with the domain I enter?
We look up its public DNS records from our server and keep nothing unless you ask for the PDF. If you do, we store the report with your contact details so we can build it, and the only email you get is the copy of your report.
Want help stopping
spoofed email?
Tell us what you found and we'll tell you what we'd fix first. No obligation.