Free Email Deliverability Check: Why Your Mail Lands in Spam

Email is the only protocol where the cost of a misconfiguration is invisible until weeks later. You add a marketing tool to your stack, it adds a TXT record, your SPF gets a 12th lookup, and from that day forward 30% of your invoices land in customers' spam folders. Nobody tells you. The first sign is the support ticket from a buyer who thought you'd ghosted them.

We just launched a free Email Deliverability Check — sibling to last week's DNS Health Check — that catches these issues in one pass. It works on any domain, takes a couple of seconds, and runs entirely in your browser.

What it checks

Ten checks across five categories, with the same green/orange/red status model as the DNS tool. Errors break delivery; warnings degrade it; info items are nice-to-haves.

Delivery

• MX records with A-record verification on every MX host. The classic silent failure: a working MX hostname that no longer resolves to anything.
• Reverse DNS (PTR) for every MX IP. Major receivers (Gmail, Microsoft, Apple) downgrade or reject mail from IPs without rDNS.

Authentication

• SPF with a DNS-lookup budget. RFC 7208 caps SPF at 10 DNS lookups; we count the mechanisms in your record and warn before you hit the wall.
• DKIM by selector probe. We try common selectors (default, google, selector1, etc.) automatically; paste your actual selector to skip the probe.
• DMARC with policy strength. p=none is monitor-only and won't actually defend you; we flag it as a warning even though receivers accept it as valid.

Transport security

• MTA-STS — TXT record AND a successful HTTPS fetch of the policy file. A TXT pointing at a missing policy is worse than no MTA-STS at all.
• TLS-RPT — the reporting record that pairs with MTA-STS. Without it you have no visibility when senders fail to negotiate TLS.
• DANE / TLSA per MX host. Belt-and-braces with MTA-STS; used by different sender stacks.

Reputation

• DNSBL lookups against Spamhaus ZEN, SpamCop, Barracuda, and PSBL — every MX IP, every list, in parallel. A listing on a major DNSBL means major receivers reject your mail outright.

Brand

• BIMI — your logo next to your name in supporting inboxes. Only useful once DMARC is at p=quarantine or stricter; we surface the dependency.

The silent killers we see most often

1. Multiple SPF records. Marketing adds Mailchimp; sales adds Postmark; nobody merges into the existing record. Per RFC 7208 this is a permanent error — receivers fail SPF and you wonder why deliverability dropped.
2. SPF lookup count over 10. Same cause as above but more subtle: each include: adds a lookup, plus any nested includes. A clean-looking record can hit the limit without ever having more than one entry. The fix is to flatten common includes into ip4: ranges.
3. Stale DKIM keys. You moved from Mailgun to SendGrid two years ago; the old mte._domainkey selector still publishes a key. Receivers see two valid signatures from different services and treat the message as suspicious.
4. DMARC stuck on p=none. Published months ago to gather reports, never moved to enforcement. Spammers can still spoof your From: address.
5. MTA-STS published without a policy file. The TXT exists; the policy at https://mta-sts.<domain>/.well-known/mta-sts.txt 404s. Senders that look up STS get an error; some treat it as broken-by-default and downgrade to opportunistic TLS.
6. Missing PTR on a new IP. Migrated mail to a new server, forgot to ask the host to set rDNS. Within a week your sender reputation tanks.

What we don't (and can't) check from the browser

Some checks need a server-side mail flow. We're explicit about what we don't cover:

• Live SMTP banner / STARTTLS handshake — needs a TCP connection on port 25 from a known IP. Browsers can't do this.
• Port 25 reachability — same constraint.
• Send-and-grade tests (the mail-tester.com style of giving you an address, you mail it, the tool grades the received message). Needs a receiving MX we run; out of scope for now.

If you need any of those, open a support ticket with the domain and we'll run a deeper audit. For everything else — the DNS-side of email — the tool covers what mail-tester and MXToolbox cover, with a tighter check set focused on issues that actually break delivery.

Privacy

Same posture as the DNS tool: every DNS lookup goes through Cloudflare's public DNS-over-HTTPS resolver from your browser. The MTA-STS policy fetch hits the target domain directly. Maxinames servers see none of it — we don't log, store, or analyse the domains you check. Use it as often as you like.

Try it

Live now at maxinames.com/mail-tools. Try it on your own domain first, then your top customers' domains — agencies have told us this is the fastest sales conversation they've had in months.