Free Email Deliverability Test: Step-by-Step Guide

Do not index

A product launch can look perfect in the campaign dashboard while the pipeline disappears. The sequence was delivered, SPF, DKIM, and DMARC showed green, and the copy was approved. Yet Gmail routed the follow-ups to spam, replies fell away, onboarding messages went unseen, and the team started changing subject lines instead of diagnosing the sending system.

That's the problem with many free email deliverability tests. They confirm that DNS records exist, but they don't always show whether a real message reaches the inbox, which mailbox provider rejected it, or what should be fixed first. A useful test connects authentication, infrastructure, reputation, list quality, content, and mailbox behavior to the business outcome, inbox placement.

Table of Contents

Why Emails Land in Spam Even When Everything Looks Set What You Need Before Running a Free Email Deliverability Test The Diagnostic Workflow That Finds the Problem Start with the active sending identity Check reputation before rewriting the campaign Inspect the path that carries the message Test the production message and inbox placement results How to Read the Scores and Signals the Test Returns Three Real Failure Scenarios and How to Fix Each One A new subdomain breaks DMARC alignment A shared IP appears on low-impact blacklists A launch creates complaints despite healthy authentication Common Deliverability Mistakes That Quietly Break Inbox Placement Running the Same Checks From API and MCP for AI Agents A 15-minute prioritization checklist

Why Emails Land in Spam Even When Everything Looks Set

Authentication is necessary, but it isn't the whole deliverability decision. Independent benchmarking published in 2026 found that only 65% of tested emails reached the inbox globally, while 32% went directly to spam, with the remaining messages ending in other delivery outcomes. The benchmark also reported a global deliverability health score of 89 out of 100, a useful reminder that legitimate senders can still lose visibility despite apparently healthy infrastructure. Read the 2026 deliverability benchmark for the underlying context.

A green SPF, DKIM, or DMARC result answers a narrow question: does the domain publish a technically recognizable authentication signal? It doesn't prove that the active sending service is aligned with the visible From domain, that the sending IP has a clean history, or that recipients engage with the messages.

Four layers usually determine whether that green panel translates into inbox visibility:

Authentication: SPF authorizes sending infrastructure, DKIM signs the message, and DMARC evaluates alignment and policy. A missing or misaligned signal can cause receiving servers to distrust the message.

Infrastructure reputation: Reverse DNS, SMTP behavior, TLS, MX configuration, IP history, and blacklist status affect how mailbox providers evaluate the sending path.

List hygiene: Unknown-user bounces, spam complaints, inactive recipients, and sudden volume changes provide behavioral signals that can weaken domain reputation.

Content and engagement: URL mismatches, deceptive links, unfamiliar sender names, heavy image use, and weak recipient interaction can push an authenticated message toward spam.

The message itself also matters. A test that uses different tracking links, headers, personalization, or subject text than the production campaign can produce a misleading result. Teams evaluating copy can review test email subject line variations, but the final deliverability test should use the exact message that real recipients will receive.

What You Need Before Running a Free Email Deliverability Test

A reliable test starts with the identity and message path used in production. Testing only the company's root domain can hide an error on a marketing subdomain, regional domain, or separate acquisition domain.

Prepare these inputs before opening a diagnostic tool:

Sending domain: Record the exact domain used by the visible From address. If campaigns come from news.example.com, test that active identity as well as the parent domain where relevant.

Campaign From address: Use the address shown to recipients. This lets the diagnostic compare the visible From domain with SPF and DKIM alignment.

Envelope sender or Return-Path: Capture the bounce address. A different Return-Path can reveal an alignment failure that a root-domain DNS check misses.

Recent message or raw headers: Use a live message from the campaign, including its Message-ID, Authentication-Results, Received, DKIM-Signature, and tracking headers. Headers show what the receiving server evaluated.

DNS access: Keep access to the domain's DNS provider available so the team can correct an invalid record without guesswork.

Optional context improves prioritization. Note the ESP or SMTP service, dedicated sending subdomain, sending IP pool, and recent bounce and complaint history. Those details help distinguish a DNS problem from a provider reputation problem.

Public DNS resolvers can cache changes, so a newly edited record might not appear everywhere immediately. DNS propagation can take minutes to 48 hours, depending on caching and TTL settings. Confirm the record through a public lookup before treating a stale result as a live failure.

A combined email authentication checker can reduce the initial manual work, but the report is only as accurate as the identity and message supplied. The test should reflect the actual campaign, not a simplified sample that omits headers or links.

The Diagnostic Workflow That Finds the Problem

A flat list of ten checks creates noise. Run the checks in order, starting with the production identity, then reputation and infrastructure, and finish by measuring where mailbox providers place the message.

Start with the active sending identity

Step 1, validate the exact sending path. Compare the From domain, envelope sender, and DKIM selector in a production header. Confirm that the ESP is authorized, the signature verifies, and the identifiers align under the domain's DMARC policy.

Look for a second SPF record, an include left by an old provider, a missing DKIM selector, or an authenticated identifier that does not match the visible From domain. Correct the DNS record or provider configuration before changing copy or buying a dedicated IP. A pass result from a simplified domain check is not enough if the campaign uses another subdomain, selector, or sending service.

DMARC enforcement data monitored across 1,346,814 domains worldwide as of August 2026 found that only 11.4% had full protection with p=reject at 100% enforcement, while 68.8% had no effective protection. The dataset also found that 39.5% had no DMARC record at all. Review the DMARC adoption data to keep record presence separate from enforcement status.

Check reputation before rewriting the campaign

Step 2, scan the production sending IPs and domain against major blacklists. Check Spamhaus, SpamCop, SURBL, Barracuda, and SORBS where relevant. A clean result means the infrastructure used by the campaign has no active listing affecting delivery.

A listing does not explain every spam placement. Check the severity, recurrence, listed asset, and mailbox providers that use the list. Confirm every outbound IP, inspect the listing reason, stop abusive or contaminated traffic, and follow the list's delisting process. Rotating infrastructure before addressing the source usually transfers the issue to the replacement path.

Inspect the path that carries the message

Step 3, verify MX, reverse DNS, SMTP, IMAP, and TLS behavior. MX records should point to the intended receiving service. Reverse DNS should identify the sending host coherently, while SMTP connections should authenticate and negotiate TLS without repeated failures.

Errors such as 550 5.7.1 rejected, authentication timeouts, or TLS negotiation failures point to infrastructure rather than copy. Live protocol checks show whether servers can send, receive, and authenticate. DNS alone cannot prove that the path works. See the infrastructure troubleshooting guidance.

For header-level investigation, use this guide to reading email headers to identify the evaluated sending path, authentication results, and receiving-server responses.

Test the production message and inbox placement results

Step 4, evaluate the production subject, body, headers, attachments, tracking links, and personalization. A synthetic message can pass while the campaign fails because of a mismatched tracking domain, shortened URL, suspicious redirect, or unfamiliar From name.

Step 5, send the exact production message to a controlled seed list across Gmail, Outlook, Yahoo, and a corporate Microsoft 365 tenant. Record whether each message reaches the inbox, spam folder, Promotions, another tab, or disappears. Test by provider and folder, repeat across several days and send windows, and retain the same domain, IP pool, headers, and links as the live campaign. Follow the inbox placement testing methodology.

How to Read the Scores and Signals the Test Returns

A deliverability score is a summary, not a mailbox prediction. The report should be read in sequence, starting with whether the message authenticated, then whether the sending path has reputation or infrastructure problems, and finally whether mailbox providers placed the message where recipients can see it.

SPF and DKIM should authorize the service that sent the message and align with the visible From domain. DMARC then evaluates that relationship and applies the published policy. Gmail's sender guidance states that a message passes DMARC when SPF or DKIM, or both, authenticate the message. Gmail's BIMI support also requires quarantine or reject with pct=100; p=none doesn't qualify. Review Gmail's BIMI requirements.

The difference between publishing a DMARC record and enforcing it matters operationally. A p=none policy provides reporting and visibility, while p=quarantine asks receivers to treat failing mail more cautiously, and p=reject requests rejection of failing messages. Enforcement should follow an inventory of legitimate sending streams, because an aggressive policy can affect valid mail that hasn't been aligned.

Signal or Score	What It Means	Priority
SPF failure or multiple SPF records	The receiving server can't reliably determine which services may send	Immediate
DKIM failure or selector mismatch	The message signature is invalid, missing, or tied to the wrong provider	Immediate
DMARC failure or alignment error	Authenticated identifiers don't match the visible From domain	Immediate
Blacklist listing	An IP or domain has a reputation signal that may affect filtering	High, based on list severity and recurrence
Missing or unstable DNS	Mailbox providers may not trust the sending or receiving path	High
SMTP, IMAP, or TLS error	The mail infrastructure may not send, receive, or authenticate reliably	High
Content warning	Links, formatting, attachments, or sender identity deserve review	Medium, unless deceptive or mismatched
Seed inbox placement	Shows actual provider and folder behavior for the tested message	High
Strong authentication with spam placement	Reputation, complaints, engagement, or content may be the dominant issue	High

A test can show 80 out of 100 and still produce spam placement if recipients rarely engage or complaints are high. Investigate DMARC failures, alignment errors, blacklist presence, and unstable DNS immediately. Monitor repeated soft bounces, complaint changes, engagement, and volume behavior over multiple sends rather than trusting one blended score.

Independent 2026 benchmarking reported 99.3% delivery for domains with SPF, DKIM, and DMARC properly configured, compared with 84.6% for unauthenticated domains, a 14.7-point gap. The same benchmark reported that roughly 30% of senders remained partially non-compliant with Gmail and Yahoo bulk-sender requirements. Read the 2026 deliverability guide. Authentication is a powerful baseline, but it still isn't proof of inbox placement.

Three Real Failure Scenarios and How to Fix Each One

A new subdomain breaks DMARC alignment

A sales platform moves outbound traffic to sales.example.com, but the campaign still uses alex@example.com in the visible From field. SPF exists for the platform subdomain and DKIM verifies, yet DMARC fails because the authenticated identifiers don't align with the parent brand shown to recipients.

The fix starts with identity design. Either use a From address on the aligned sending subdomain, or configure a DKIM selector and envelope sender that align correctly with the parent domain. The team shouldn't jump directly to p=reject; it should inventory legitimate streams, publish reporting, and increase enforcement after alignment is stable.

A shared IP appears on low-impact blacklists

Authentication passes, but the sending IP appears on two low-impact lists. The diagnostic process confirms that the production IP, rather than only an unused domain, is listed. Forward-confirmed reverse DNS is checked, the listing causes are reviewed, and delisting requests are submitted.

A dedicated IP might help a sender that has sufficient, consistent volume and can manage its reputation. It doesn't erase an existing problem, and moving to one before correcting poor list quality or abusive traffic can just create a new reputation issue on different infrastructure.

A launch creates complaints despite healthy authentication

The launch-day campaign authenticates correctly, but recipients complain and engagement drops. The test identifies mismatched tracking URLs, image-heavy formatting, and an unfamiliar From name as risk factors. The team simplifies the message, uses a recognizable sender, removes suspicious URL mismatches, suppresses inactive recipients, and throttles the first sends.

Warmup for a new source can take 2 to 6 weeks depending on volume and reputation, and sudden sending spikes can damage sender reputation. These are operating conditions, not DNS defects. Bounce rate is ideally kept below 2%, while spam complaints are usually kept below 0.1%, but context and mailbox-provider behavior still matter.

Each scenario needs a controlled repair. Preserve the original report, change one layer at a time, wait for DNS propagation where applicable, and rerun after a meaningful sending window. A green rerun confirms configuration repair. It doesn't automatically restore reputation.

Common Deliverability Mistakes That Quietly Break Inbox Placement

A green authentication panel can create dangerous confidence. The most common mistake is testing the corporate root domain while the campaign sends through a platform subdomain, regional identity, or separate acquisition domain. Every active sending identity needs its own SPF, DKIM, DMARC, reputation, and inbox-placement review.

Other failures are operational:

Duplicate SPF records: Multiple TXT records can make SPF invalid. Consolidate authorized services and stay within SPF's 10 DNS lookup limit.

Stale provider entries: Leaving obsolete ESP includes in SPF expands the sending surface and makes future changes harder to audit.

Premature DMARC rejection: Moving to p=reject before legitimate streams are aligned can block valid mail. Start with reporting and progress deliberately.

Unverified real messages: DNS can look correct while live headers show a broken DKIM signature, wrong selector, or From-domain mismatch.

Blacklist score worship: A listing's source, severity, affected IP or domain, and recurrence matter more than a simple count.

Ignoring operating signals: Complaints, unknown-user bounces, low engagement, poor recipient quality, and volume spikes can outweigh a clean DNS report.

The same checks should run on every production sending domain and be compared over time. Authentication is the entry requirement. Reputation, relevance, recipient quality, and consistent sending behavior determine what happens after that requirement is met.

Running the Same Checks From API and MCP for AI Agents

A browser audit works well for a founder troubleshooting one domain. Developers, agencies, and operations teams need repeatability, especially when several sending identities or automated workflows are involved. API checks can feed a dashboard, scheduled job, deployment gate, or incident alert without requiring someone to open a DNS tool after every change.

A practical request should include the sending domain and the From address or header context. The response should return structured states for SPF, DKIM, DMARC, blacklist findings, DNS health, SMTP and IMAP connectivity, and content or deliverability warnings. An implementation can follow this pattern:

Send the domain and From identity to the deliverability test endpoint.

Authenticate the request with a bearer token.

Parse JSON fields for authentication pass states, blacklist hits, infrastructure failures, and content warnings.

Store the result as the baseline for that domain.

Alert when a later run detects a removed DMARC record, failed DKIM selector, SPF change, or new blacklist listing.

The exact endpoint and response schema should come from the mailX API documentation, rather than from assumptions in an agent prompt. The same diagnostic action can then be exposed through MCP, allowing Claude or another compatible agent to invoke a structured tool such as check_domain_deliverability, interpret the findings, and recommend the next remediation step. mailX also provides an MCP endpoint and an Agent Skill for deliverability workflows.

A daily monitoring agent shouldn't send blindly. It should check the domain before a campaign, compare the result with the previous run, and pause or escalate when a high-priority signal regresses. That approach supports a broader revenue-focused email strategy without treating deliverability as an afterthought.

A 15-minute prioritization checklist

Verify SPF syntax: Confirm one valid SPF record and review authorized services against the current ESP.

Confirm DKIM signing: Inspect a real header and verify the active selector signs production mail.

Review DMARC alignment: Begin with reporting when streams aren't fully inventoried, then move toward enforcement as confidence grows.

Scan reputation: Check the sending IP and domain against relevant blacklists.

Validate infrastructure: Test reverse DNS, MX, SMTP, IMAP, TLS, and server authentication.

Review message signals: Check tracking links, URL consistency, attachments, sender identity, and list-unsubscribe headers.

Test inbox placement: Send the exact production message to the mailbox providers used by the audience.

Monitor warmup volume: Re-test sending sources as volume increases instead of treating one audit as permanent.

The diagnostic mindset is simple: authenticate first, inspect reputation and infrastructure next, test the actual message after that, then monitor continuously. A free email deliverability test only creates value when its result changes what the sender does.

mailX runs live checks across SPF, DKIM, DMARC, BIMI, DNS, MX, blacklist status, SMTP, IMAP, and related infrastructure, then explains what each finding means and what to fix next. Visit mailX to run a free deliverability audit on the sending domain behind your next campaign, and use the result to address the highest-priority inbox placement risk before sending.