Free email deliverability test and spam checker. Check MX, SPF, DKIM, DMARC, BIMI and reverse DNS for your domain in one pass, with a fix for each failure.
Enter the domain you send email from (or any email address on it) and this tool runs an email deliverability test against its public DNS. In one report it checks everything a receiving mail server looks up before it decides whether your message goes to the inbox, the spam folder, or back to you as a bounce:
v=spf1 record exists, whether every term in it is valid syntax, how many DNS lookups it needs against the RFC 7208 limit of ten (counted through nested includes), and whether it ends in -all, ~all, ?all or the dangerous +all.google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp, s1 and s2 for SendGrid, mandrill, default, pm, mg, amazonses and more), plus the selectors for any sending service detected from your SPF and TXT records, plus a selector you supply. Each key found is checked for revocation (an empty p=), testing mode (t=y) and an estimated key length.none, quarantine or reject), the pct percentage, whether aggregate reports (rua) are configured, and the alignment modes (adkim, aspf).Every failure and warning comes with a specific fix and a link to the page that explains it in full.
The score out of 100 weights the records that decide deliverability: SPF, DKIM and DMARC carry 25 points each, MX records 10 and reverse DNS 5. A section that passes earns its full weight, a section with a warning earns half, and a failed section earns nothing. MTA-STS, TLS-RPT and BIMI are reported but not scored, because they protect mail coming in to you or add branding rather than deciding whether your outgoing mail is accepted.
+all, or no DKIM key at the selector you sign with.p=none, no rua address, ~all without an enforced DMARC policy, nine or ten SPF lookups, a 1024-bit DKIM key, or no DKIM key found at the common selectors.A DNS check answers one question: is the domain set up so that receivers can authenticate its mail? That is necessary, and since 2024 it is mandatory at Gmail and Yahoo, but it is not the whole picture. Once a message is authenticated, the receiving provider decides inbox or spam based on things DNS cannot show:
To measure inbox placement directly, you need a seed test that sends real mail to test mailboxes at different providers and reports where each one landed.
Gmail requires every sender to authenticate with SPF or DKIM, to have valid forward and reverse DNS on sending IPs, to use TLS, and to sign with a DKIM key of at least 1024 bits. Senders of more than 5,000 messages a day to Gmail accounts must also set up SPF, DKIM and DMARC (a policy of p=none is enough), align the From: domain with the SPF or DKIM domain, support one-click unsubscribe on marketing mail, and keep spam complaints below 0.30%. Unauthenticated mail is rejected with 550 5.7.26; mail rejected on reputation gets 550-5.7.1.
No SPF record. Publish a single TXT record at the root of the domain that lists every service sending as you, for example v=spf1 include:_spf.google.com ~all. The SPF Record Generator builds one.
Two SPF records. A domain may have only one. Two is a permanent error and SPF fails for every message. Merge the mechanisms into one record.
Too many DNS lookups. Each include, a, mx and exists costs a lookup, and includes can contain more includes. Past ten, SPF returns PermError. Remove services you no longer use, replace a and mx with ip4: ranges, or move a sender to a subdomain.
No DKIM key found. DKIM selectors cannot be listed from DNS, so a checker can only try likely names. If your provider uses a custom selector, open a message you sent, find the DKIM-Signature header and enter its s= value. If there is no DKIM-Signature at all, DKIM signing is not turned on in your mail platform.
DMARC at p=none. It satisfies the bulk-sender rule but asks receivers to do nothing with failing mail. Read the aggregate reports until every legitimate sender passes, then move to p=quarantine and finally p=reject.
Missing reverse DNS. If your MX hosts also send your outgoing mail, their IPs need a PTR record whose hostname resolves back to the same IP. Only the owner of the IP block (your host or ISP) can set it.
Blocklists are not included. The major DNS blocklists, Spamhaus included, refuse queries that arrive through public resolvers, so a browser-based tool cannot give a reliable answer. Look up your sending IP on each blocklist operator's own site. The tool also checks reverse DNS for MX hosts only; if you send from different servers, check those IPs separately.
Every check is a public DNS query, plus a fetch of the domain's own published MTA-STS policy file. The tool never connects to the domain's mail servers and never sends a test message, so you can run it against any domain: your own, a client's, or a vendor's.
It checks the DNS records that receivers use to decide whether your mail is authenticated: MX, SPF, DKIM, DMARC and reverse DNS. Failing any of them is the most common reason mail goes to spam or bounces. It does not send a test message, so it cannot measure inbox placement or score message content.
Authentication is necessary but not sufficient. Once mail is authenticated, providers decide inbox or spam on sending reputation, complaint rate, alignment on real messages and content. Check Google Postmaster Tools for reputation and complaint rate, and run a seed test to see real placement.
DKIM selectors cannot be listed from DNS, so the tool tries more than 25 common ones. If your provider uses a custom selector, open a message you sent, find the DKIM-Signature header and enter its s= value in the selector field.
SPF allows at most 10 DNS-querying mechanisms (include, a, mx, exists, ptr, redirect), counted through nested includes. Over 10, SPF returns PermError and fails for every message even though the record looks correct.
With DMARC at quarantine or reject, ~all is a sound choice because DMARC decides what happens to failing mail and softfail avoids rejecting forwarded mail on SPF alone. Without an enforced DMARC policy, ~all only flags unlisted senders, so -all or an enforced DMARC policy is stronger.
It meets the Gmail and Yahoo bulk-sender requirement, but it asks receivers to do nothing with mail that fails, so spoofed mail still gets delivered. Move to quarantine and then reject once your aggregate reports show every legitimate sender passing.
No. The major DNS blocklists, Spamhaus included, refuse queries made through public resolvers, so a browser-based check cannot give a reliable answer. Look up your sending IP on each blocklist operators own site.
Yes. Every check is a public DNS query plus a fetch of the domains own published MTA-STS policy. The tool never connects to the mail servers and never sends email.