Can your domain be spoofed by email? Check it
Review the public configuration of your email, domain and website. Free, no sign-up.
Scope and privacy of the check
Enter your domain and you will see whether someone could send emails pretending to be it, and what to fix first. We do not ask for a contact email and, if you enter an email address, we only use the domain. The result is temporary: it is not recovered or queried again when you reload.
Method, limits and frequently asked questions
What we check
Fourteen checks of your domain's public configuration, grouped into email, domain and website. The «Can your domain be spoofed?» verdict comes from your DMARC and SPF records: the most serious finding decides. Each check ends in Good, Could improve, Risk, No data, Not applicable or Information, with what it means and what your IT team needs to do.
| Check | Group | What it looks at | Source |
|---|---|---|---|
| SPF | Which servers may send email using your domain, and whether the record can be fully evaluated. | RFC 7208 | |
| DKIM | Whether we find signing keys with the common selectors (or yours) and their size. | RFC 6376, RFC 8301, RFC 8463 | |
| DMARC | What you ask mailboxes to do with emails that use your domain without authorisation. | RFC 9989 (and RFC 7489) | |
| MX | Which servers receive your email, or whether you declare that the domain receives none. | RFC 5321, RFC 7505 | |
| MTA-STS | Whether you publish a policy that requires encryption when email is received between servers. | RFC 8461 | |
| TLS-RPT | Whether you ask for reports of encryption failures when receiving email. | RFC 8460 | |
| BIMI | Whether you publish the record to show your logo in some mailboxes (for information). | IETF draft | |
| DNSSEC | Domain | Whether your DNS answers are signed and a validating resolver accepts them. | RFC 4033-4035, RFC 9364 |
| CAA | Domain | Which authorities may issue certificates for your domain. | RFC 8659 |
| Website TLS | Website | TLS version, certificate chain and whether old versions are accepted. | RFC 8446, RFC 8996 |
| Certificate expiry | Website | How many days your website certificate has left. | CA/Browser Forum |
| HTTPS and HSTS | Website | Whether the website redirects to HTTPS and makes the browser use it. | RFC 6797 |
| Security headers | Website | The effective content policy, framing protection and other headers. | W3C CSP Level 3, WHATWG Fetch |
| security.txt | Website | Whether you publish whom to contact about a security issue, and whether it is still current. | RFC 9116 |
What it does not do
- It does not scan ports or look for subdomains.
- It does not connect to your mail servers: it measures the policy you publish, not what each server or mailbox does.
- It does not test for vulnerabilities. It only makes DNS queries to public resolvers and a few requests to your website, like a browser would.
- It does not give a numerical score. What we could not check is shown separately, as «No data», and never counts as good.
Who it is for
For people who run a company and want to know whether someone could send emails using their domain; for the IT team, who need the exact record and the next step; and for IT providers and advisers who review their clients' domains, with their permission.
How to fix it
Start with «Your first 3 changes» in the result. For DMARC, the usual path is to publish «p=none» with reports («rua»), review them for two to four weeks, move to «p=quarantine» and end at «p=reject». For SPF, remove the providers you no longer use; flattening it to IP addresses means maintaining it whenever the provider changes theirs. If a domain neither sends nor receives email, publish a null MX, «v=spf1 -all» and DMARC with «p=reject».
If you would rather have someone review your configuration with you, see our cybersecurity services.
Your data
No sign-up and no email address. The domain travels in the body of the request, not in the page address, and we do not store it or send it to our analytics. If you enter an email address, your browser only sends what comes after the @. More information in our privacy policy.
Frequently asked questions about the checker
It is a record you publish in your DNS to tell mailboxes what to do with emails that use your domain without passing SPF or DKIM: do nothing («p=none»), quarantine them («p=quarantine») or reject them («p=reject»). It also lets you receive reports on who sends email on your behalf.
DKIM keys are published under a name (the selector) that cannot be listed from outside. We try the most common selectors; if your provider uses another one, enter it in the advanced option. Not finding one does not mean you have no DKIM, and finding a key does not prove that all your email is signed.
That your DMARC record is in monitoring mode: it does not ask mailboxes to reject or quarantine emails that pretend to come from your domain. If you also set a valid «rua» address, you can receive reports on who sends email on your behalf. It is a good first step; the goal is to reach «p=quarantine» and then «p=reject».
No. «Difficult» refers to emails using your exact domain and to the policy you publish. It does not cover lookalike domains or a mailbox that has already been compromised.
The checker only queries public information (DNS records, the certificate and the website headers), the same information any mail server or browser queries, with low-intensity requests. Even so, use it with domains of your organisation or of clients who ask you to.
No. We query the domain you enter through public DNS resolvers (Cloudflare and Google), which receive the domain name and the address of our server, not yours. To prevent abuse we use a pseudonymised fingerprint of your IP address and of the domain checked for 48 hours; we do not store the IP address. The domain does not go in the page address or in our analytics.
Yes: it checks your DMARC, SPF and DKIM, which are what allow mailboxes to stop email spoofing with your exact domain. It does not cover domains that look like yours or a mailbox that has already been compromised, and it measures the policy you publish, not what each mailbox does.
Google requires DMARC (even with «p=none») from senders that send more than 5,000 emails a day to Gmail accounts, as well as SPF and DKIM. It explains this in its email sender guidelines.
Official sources
- RFC 7208 · SPF
- RFC 6376 · DKIM
- RFC 8301 · DKIM algorithms and key sizes
- RFC 9989 · DMARC
- RFC 7489 · DMARC (previous version)
- RFC 7505 · Null MX
- RFC 8461 · MTA-STS
- RFC 8460 · TLS-RPT
- RFC 9364 · DNSSEC
- RFC 8659 · CAA
- RFC 8996 · Deprecating TLS 1.0 and 1.1
- RFC 6797 · HSTS
- W3C · Content Security Policy Level 3
- RFC 9116 · security.txt
- Google · Email sender guidelines
Email is one part. If you want to look at the rest of your cybersecurity with someone, tell us about your case.