Email Provider Setup Check
Check whether your domain's MX, SPF include, DKIM selectors and DMARC match what Google Workspace, Microsoft 365, Zoho, Fastmail and others document. Runs in your browser.
Your query is sent only to the resolver shown; this site keeps no logs. Copy link to this result
What this checks
Every email provider documents the same four DNS records, and a domain only works with that provider when all four are right. The MX records say where inbound mail goes (RFC 5321 §5.1). The SPF record lists who may send as your domain, and the provider's include must be reachable from it (RFC 7208 §5.2). The DKIM selectors publish the public key that receivers use to verify the provider's signatures (RFC 6376 §3.6.1). The DMARC record tells receivers what to do when both checks fail (RFC 9989 §4.7). This tool reads those four records over DNS-over-HTTPS and compares them with the values in the provider's own documentation, which is linked as the source next to each expected value.
SPF is evaluated the way a receiver does it. The tool walks the whole include tree, counts every DNS-querying term against the limit of 10 lookups (RFC 7208 §4.6.4) and reports the provider as authorised if its documented include appears anywhere in that tree, for example through a corporate include that itself includes Microsoft. A subdomain of the documented include's registered domain is accepted as an equivalent include, and region variants named in the provider's documentation count too. If the record only lists ip4 and ip6 ranges (a flattened or "smart" SPF record), the provider cannot be recognised by name, so the result is a warning rather than a failure.
MX hosts are matched by registered domain, so aspmx.l.google.com and smtp.google.com both count as Google. A null MX (RFC 7505) means the domain refuses all mail and is reported as a failure for mailbox providers. For DKIM the tool queries each documented selector for a TXT key and for a CNAME, follows the CNAME, and treats an empty p= tag as a revoked key (RFC 6376 §3.6.1). One valid selector is enough to pass, but a failing second selector is flagged as a partial setup. Where a provider creates selectors per account, the tool says so and points you to the email header analyzer. DMARC is read from _dmarc, walking up to parent domains until a record is found (DNS tree walk, RFC 9989 §4.10), and p=none is a warning because it only monitors.
Related checks: the full SPF checker shows the include tree in detail, the DMARC checker explains every tag, and the MX lookup lists the mail servers. Nothing is sent to our servers; only the DNS resolver named in the result sees your query.
If it fails
- MX fails: add the provider's MX records and remove the old ones; a null MX (0 .) must be replaced, not kept next to real records.
- SPF include missing: add the provider's include to your existing SPF record before the all term. Never publish a second SPF record (RFC 7208 §3.2).
- More than 10 DNS lookups: remove unused includes or services you no longer send from; see the guide on too many SPF lookups.
- DKIM not found or revoked: enable DKIM signing in the provider's console and publish the record it shows, then wait for DNS caches to expire.
- DMARC missing or p=none: publish a DMARC record with an rua= address, watch the reports, then move to quarantine and reject.
FAQ
How does the tool know which provider I use?
If you leave the provider on auto-detect, it compares your MX hosts and the SPF include tree with the providers in its list and preselects the best match. You can always choose another provider and run the check again.
Why does it say my provider is authorised through another include?
SPF includes can be nested. If your record includes a corporate or relay include that in turn includes the provider's include, receivers still evaluate it, so the provider is authorised. The tool shows the path, and it still counts every lookup toward the limit of 10.
What does "can't confirm: SPF appears flattened" mean?
A flattened SPF record replaces include: mechanisms with fixed ip4 and ip6 ranges. Then the provider's name no longer appears, so the tool cannot confirm it. That is not necessarily wrong, but flattened ranges become outdated when the provider changes its IPs.
Why is DKIM shown as unknown for some providers?
Some providers create a different DKIM selector for each customer, so there is no public name to look up. Send a test message, paste its headers into the email header analyzer and read the s= tag of the DKIM-Signature header.