Enter a domain and see whether its email authentication is actually configured — and what each result means. Runs in your browser; we never see which domains you check.
Mail exchanger records tell the internet which servers accept mail for your domain. No MX records means mail to that domain bounces, full stop. It is the first thing to check when someone reports that messages to you are failing.
A list of servers permitted to send mail using your domain, published as a TXT record. Two mistakes are common and both are worse than they look. Publishing two SPF records is a permanent error under RFC 7208 — receivers may fail every message rather than pick one. And ending a record with +all authorises the entire internet to send as you, which is genuinely worse than publishing nothing.
A cryptographic signature added by your sending server and verified against a public key in DNS. The awkward part is that the key lives at a selector chosen by whoever configured it, and there is no way to enumerate selectors. This tool probes the common ones, so a miss means "not found at a usual name" rather than "not configured".
DMARC ties the other two together and states a policy. Most domains that have it sit at p=none, which collects reports and enforces nothing — worth knowing, because it is easy to see a DMARC record and assume you are protected when you are only observing.
The other trap is a rua= address that bounces. Aggregate reports are the only feedback showing which of your legitimate senders would break under enforcement. If they are being sent to a mailbox that rejects them, you are flying blind while believing you are instrumented.
No. The lookups run in your browser against Cloudflare’s public DNS-over-HTTPS resolver and never touch our servers, so there is no list of checked domains for us to keep. A free checker that quietly harvests the domains people look up is not a tool worth trusting.
DKIM keys live at a selector chosen by whoever configured your mail, and there is no way to list the selectors a domain uses. We probe the common ones — google, default, selector1, selector2 and others — so a miss means we could not find a key at a usual name, not that you have none. Your provider’s documentation will name your selector.
Almost always because the policy is p=none, which collects reports but enforces nothing — it is easy to see a DMARC record and assume you are protected when you are only observing. The other common cause is a missing rua= address, which means no aggregate reports and therefore no visibility into what enforcement would break.
Yes. RFC 7208 permits exactly one SPF record per domain, and receivers are entitled to treat more than one as a permanent error rather than choosing between them. It is a common outcome of adding a second provider without merging the record, and it can fail authentication for every message you send.
Connect a domain and SPF, DKIM and DMARC are configured as part of onboarding — on every plan, including free.
Create your free accountNo credit card. No trial clock.