Checks DNS via Cloudflare DoH (Google DoH fallback). No email is sent. No data stored.
Enter a domain above and click Run Test to check SMTP deliverability
What this tool does
Free SMTP delivery tester -- check MX records, SPF, DMARC, port reachability, and email authentication for any domain
How this SMTP diagnostics tool works, what each check detects, and why each signal matters for email deliverability
This free SMTP delivery tester performs five diagnostic checks against any email domain to assess its email deliverability configuration and estimate the likelihood of messages reaching the inbox versus being filtered as spam. All DNS checks run directly from your browser using Cloudflare DNS over HTTPS (DoH) at cloudflare-dns.com/dns-query with automatic fallback to Google DNS over HTTPS at dns.google/resolve -- both are globally distributed, privacy-respecting resolvers that return live DNS data without caching delays. The SMTP port probe uses HTTPS fetch requests to test whether the primary MX host responds on port 25 and port 587 -- the two most common SMTP delivery and submission ports. The disposable domain check queries the Kickbox open API to determine whether the domain is a known throwaway mail provider. The entire test completes in under 15 seconds and produces a scored 0-95 deliverability estimate with a four-tier verdict: Likely Inbox, Probably Inbox, At Risk, or Likely Spam.
Each of the five checks targets a distinct layer of email deliverability infrastructure. The MX record check (worth 20 points) verifies that the domain has mail servers configured to receive email -- without MX records, there is no delivery target and all incoming mail bounces. The SPF check (up to 20 points) reads the domain's TXT record starting with v=spf1 to determine whether an authorised sender list is published and how strictly it is enforced: -all (hard fail, recommended) scores full points, ~all (soft fail) scores 18 points, and +all or ?all (permissive) scores only 8 points. The DMARC check (up to 25 points) reads the TXT record at _dmarc.domain to find the enforcement policy: p=reject scores 25 points, p=quarantine scores 22, and p=none scores 10. The port check (20 points) probes the primary MX host for SMTP reachability. The disposable check (10 points) penalises known throwaway domains that major ESPs block by default. Each failing or warning check includes specific remediation instructions explaining exactly what DNS record to add or modify to fix the issue.
Understanding why each check matters requires understanding how receiving mail servers like Gmail and Outlook make filtering decisions. When an email arrives, the receiving server first checks MX records (does this domain even have mail infrastructure?), then validates SPF (is this sending IP authorised by the domain?), then checks DKIM signatures (is this message cryptographically signed by the claimed sender?), then applies the DMARC policy (what should be done if SPF or DKIM fails?). A domain missing any of these records gives the receiving server less information to trust the message, increasing the probability of spam classification. This tool covers MX, SPF, and DMARC directly through DNS checks and uses DMARC presence as a proxy for overall authentication maturity. While DKIM cannot be checked without knowing the selector, SPF and DMARC together account for the majority of authentication signals used in spam scoring by major providers -- making this tool a fast, reliable first-pass diagnostic for any sending domain.
Checks and scoring details
MX Record Check
Verifies the domain has mail server records configured -- required for any email delivery to function at all (20 points).
SPF Policy Scoring
Reads the v=spf1 TXT record and scores: -all=20pts, ~all=18pts, +all or ?all=8pts, missing=0pts.
DMARC Enforcement
Checks _dmarc.domain for policy level: p=reject=25pts, p=quarantine=22pts, p=none=10pts, missing=0pts.
SMTP Port Probe
Probes port 25 (MTA-to-MTA) and port 587 (submission) on the primary MX host for SMTP reachability (20 points).
Disposable Detection
Queries the Kickbox open API to check whether the domain is a known disposable or throwaway mail provider (10 points).
Cloudflare DoH
All DNS lookups use Cloudflare DNS over HTTPS for low-latency, privacy-preserving, live DNS resolution.
Google DoH Fallback
If Cloudflare DoH is unreachable, all queries automatically retry via Google Public DNS over HTTPS.
Four-Tier Verdict
Likely Inbox (80-95), Probably Inbox (65-79), At Risk (40-64), Likely Spam (below 40) based on total weighted score.
Fix Instructions
Every failed or warned check displays the exact DNS record you need to add or modify to resolve the issue.
Response Time Display
Each check shows its resolution time in milliseconds so you can identify slow DNS lookups and TTL issues.
No Signup Required
Run unlimited SMTP delivery tests with no account, no API key, no rate limiting, and zero data collection.
Under 15 Seconds
All five checks run with concurrent DNS calls where possible, with full results typically available in 5-15 seconds.
Examples
SMTP delivery test examples -- from full enforcement to missing authentication and disposable domains
Five real-world domain configurations with their test results, scores, and what each outcome means for email deliverability
Passgoogle.com -- full enforcement, 95/95 score, Likely Inbox
Domain: google.com
MX: pass aspmx.l.google.com (priority 1)
SPF: pass v=spf1 include:_spf.google.com ~all
DMARC: pass v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com
Port 25: pass Reachable (42ms)
Disposable: pass Not disposable
Score: 95/95 -- Likely Inbox
Google's sending domain passes all five checks with maximum scores. The p=reject DMARC policy means any email failing SPF or DKIM is refused outright, providing complete spoofing protection. This is the gold standard configuration every sending domain should aim for -- strict SPF, DMARC at p=reject, and fully reachable MX servers.
PassTypical SaaS domain -- quarantine policy, 90/95 score, Likely Inbox
Domain: example-saas.com
MX: pass mail.example-saas.com (priority 10)
SPF: pass v=spf1 include:sendgrid.net -all
DMARC: pass v=DMARC1; p=quarantine; rua=mailto:dmarc@example-saas.com
Port 587: pass Reachable (87ms)
Disposable: pass Not disposable
Score: 90/95 -- Likely Inbox
A well-configured SaaS transactional email domain using SendGrid achieves 90/95 -- just below maximum because p=quarantine rather than p=reject is used. Quarantine still enforces authentication by sending failing mail to spam rather than rejecting it, which is appropriate for domains still validating all their sending sources before moving to full rejection.
WarningMissing DMARC -- 70/95 score, Probably Inbox with risk
Domain: partial-domain.com
MX: pass mail.partial-domain.com (priority 10)
SPF: pass v=spf1 include:mailgun.org ~all
DMARC: fail No DMARC record at _dmarc.partial-domain.com
Port 25: pass Reachable (120ms)
Disposable: pass Not disposable
Score: 70/95 -- Probably Inbox
A domain with MX and SPF but no DMARC record loses 25 points, dropping into the Probably Inbox tier. Without DMARC, the domain has no enforcement policy against spoofing and misses a signal that major inbox providers use for trust scoring. The fix is a single DNS TXT record at _dmarc.partial-domain.com -- typically a five-minute change.
FailMissing SPF + DMARC -- 32/95 score, Likely Spam
Domain: unprotected-domain.com
MX: pass mail.unprotected-domain.com (priority 10)
SPF: fail No SPF record found
DMARC: fail No DMARC record found
Port 25: pass Reachable (210ms)
Disposable: pass Not disposable
Score: 32/95 -- Likely Spam
A domain with MX records and reachable mail servers but no SPF or DMARC scores only 32/95 and falls into Likely Spam. Gmail and Outlook both use SPF and DMARC presence as strong signals -- missing both means that any email from this domain is almost certainly landing in spam folders or being rejected outright by major providers. Adding SPF and DMARC records would immediately lift the score to 75+.
FailDisposable domain -- auto-flagged regardless of DNS config
Domain: mailinator.com
MX: pass Present
SPF: pass Present
DMARC: pass Present
Port 25: pass Reachable
Disposable: fail FLAGGED as disposable/throwaway domain
Score: Penalised -- Likely Spam
Known disposable email domains like Mailinator are automatically flagged by major ESPs regardless of their DNS configuration. The disposable check queries the Kickbox API which maintains a database of thousands of throwaway mail providers. Any application accepting user email addresses from disposable domains exposes itself to abuse, fake signups, and bulk registration fraud.
FAQ
Frequently asked questions about SMTP delivery testing, email authentication, MX records, and inbox placement
Common questions about how to fix failing SMTP checks, what SPF and DMARC records do, and why email goes to spam
What does this SMTP delivery tester actually check?
This SMTP delivery tester performs five DNS-level diagnostic checks against any email domain: MX record lookup (whether the domain has mail servers configured), SPF record check (whether the domain publishes a Sender Policy Framework policy), DMARC record check (whether the domain enforces an email authentication policy at _dmarc.domain), SMTP port reachability probe (whether the primary MX host responds on port 25 and port 587), and disposable domain detection (whether the domain is a known throwaway mail provider). All checks run directly from your browser using Cloudflare DNS over HTTPS with Google DoH as fallback. The results include a per-check status, a scored deliverability estimate, and specific fix instructions for each failed check.
Why can't this tool open a full SMTP connection and check TLS or authentication?
Browsers cannot open raw TCP connections to arbitrary ports -- this is a fundamental browser security restriction called the Same-Origin Policy and port blocking. SMTP operates over TCP on ports 25, 587, and 465, none of which are accessible from browser JavaScript. This tool works around this limitation by using DNS over HTTPS to perform all DNS-level checks (MX, SPF, DMARC) which capture the majority of deliverability issues, and uses HTTPS fetch probes to test port reachability indirectly. For a full SMTP handshake test including EHLO, STARTTLS negotiation, and authentication, you need a server-side tool like Telnet, OpenSSL, or a dedicated SMTP testing API.
What is an MX record and why is it required for email delivery?
An MX (Mail Exchanger) record is a DNS record that specifies which mail servers are responsible for accepting incoming email for a domain. When someone sends an email to user@yourdomain.com, the sending mail server performs a DNS MX lookup to find where to deliver the message. Without an MX record, the sending server has no delivery target and the message will bounce with a 'no route to host' or similar error. MX records include a priority value -- lower numbers are higher priority -- allowing domains to specify primary and backup mail servers. A domain must have at least one valid MX record pointing to a reachable mail server for email delivery to function at all.
What is an SPF record and how does it affect email deliverability?
An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which IP addresses and mail servers are authorised to send email on behalf of your domain. It takes the form v=spf1 include:mailprovider.com -all where -all means 'reject mail from any server not listed'. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to verify that the sending server is authorised. A missing SPF record, a permissive +all qualifier, or an SPF record that does not include your actual sending servers significantly increases the chance of your email being flagged as spam or rejected entirely.
What is a DMARC record and what policy should I use?
DMARC (Domain-based Message Authentication Reporting and Conformance) is a DNS TXT record published at _dmarc.yourdomain.com that tells receiving mail servers what to do with emails that fail SPF or DKIM authentication. The three policy levels are p=none (monitoring only -- collect reports but do not reject or quarantine), p=quarantine (send failing emails to the spam folder), and p=reject (reject failing emails outright). For production sending domains, p=reject is the gold standard -- it fully enforces authentication and prevents domain spoofing. Start with p=none to collect reports, move to p=quarantine after validating your sending sources, then graduate to p=reject for maximum protection.
What is the difference between SMTP port 25, 587, and 465?
Port 25 is the original SMTP port used for server-to-server mail transfer (MTA to MTA delivery). Most consumer ISPs block outbound port 25 connections to prevent spam from compromised home computers. Port 587 is the modern submission port, intended for email clients and applications to submit messages to a mail server using STARTTLS encryption and authenticated credentials -- this is what you should use in application SMTP configuration. Port 465 is the legacy SMTPS port using implicit SSL/TLS from the start of the connection. The current standard is port 587 with STARTTLS. This tool probes both port 25 and port 587 on the primary MX host to assess reachability.
How is the SMTP deliverability score calculated?
The deliverability score is calculated from the five checks, each contributing a weighted point value: MX records present (20 points), SPF record present and strict (20 points for -all or ~all, 8 points for +all or ?all), DMARC record with enforcement (25 points for p=reject, 22 for p=quarantine, 10 for p=none), SMTP port reachability (20 points for port 25 or 587 responding), and not a disposable domain (10 points). The maximum score is 95 points. The four-tier verdict is: Likely Inbox (80-95%), Probably Inbox (65-79%), At Risk (40-64%), and Likely Spam (below 40%). This scoring mirrors the checks performed by major email service providers when deciding whether to inbox or filter incoming messages.
Why would my email go to spam even if all checks pass?
DNS authentication checks (MX, SPF, DMARC) are necessary but not sufficient for inbox placement. Additional factors that influence spam classification include IP reputation (whether your sending IP is on any RBL blacklists), domain reputation (how long your domain has been sending and its historical complaint rate), content analysis (spam trigger words, excessive links, HTML to text ratio, missing unsubscribe links), sending volume and velocity (sudden high volume from a new IP triggers spam filters), engagement metrics (in Gmail and Outlook, historical open and click rates affect future placement), and email infrastructure details (reverse DNS PTR records, DKIM key strength, BIMI records). A clean DNS setup is the foundation; building sender reputation through consistent low-volume sending is the next step.
What is email warm-up and why is it needed before bulk sending?
Email warm-up is the process of gradually increasing sending volume from a new IP address or domain over several weeks to build a positive sender reputation with major inbox providers (Gmail, Outlook, Yahoo). When a new IP sends thousands of emails immediately, spam filters treat this as suspicious behaviour and filter the messages aggressively. The recommended warm-up schedule starts at 50-100 emails per day in week one, doubling every week while maintaining high engagement rates (open rates above 20%, complaint rates below 0.1%). Only send to your most engaged recipients during warm-up. Running this SMTP tester before starting warm-up ensures your DNS authentication is correctly configured.
How do I fix a failing SMTP delivery test?
Each failed check in this tool shows a specific fix instruction. For a missing MX record: add an MX record in your DNS control panel pointing to your mail server hostname with priority 10. For a missing SPF record: add a TXT record at your domain root with value v=spf1 include:yourmailprovider.com -all, replacing the include with your actual mail provider's SPF include string. For a missing DMARC record: add a TXT record at _dmarc.yourdomain.com with value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and upgrade to p=reject after reviewing reports. DNS changes typically propagate within minutes for TTL-aware resolvers but can take up to 48 hours globally. Re-run this tester after making changes to verify each fix.
Related Email Tools
Need a disposable email address?Stop exposing your real address to sites you don't trust -- get a free instant throwaway with no signup and no trace.
Get Free Temp Mail ->