Email Deliverability Test: The Complete 2026 Guide

If you're sending cold email and don't run a deliverability test on a brand-new domain before you light up the campaign, you're flying blind. Half of cold email's deliverability failures show up in the first 100 sends — the test catches them in the first 1.

This guide is the canonical 2026 reference for what an email deliverability test actually measures, how to interpret each check, which free and paid tools compare on what, and how to chain testing into a real diagnostic flow when something goes wrong.

TLDR — what a deliverability test reveals in 30 seconds:

Check	What it confirms
SPF record present + valid	Receiving servers can verify your sending IPs are authorized
DKIM record published + signing	Messages are cryptographically signed; signature verifies in DNS
DMARC record published	You have a policy for what to do when auth fails
MX record resolves	Your domain can receive replies (cold email is two-way)
BIMI record	Optional brand trust signal — logo display in Gmail and Apple Mail
MTA-STS / TLS-RPT	Forces TLS on inbound mail; reports failures
PTR (reverse DNS) configured	Sending IP resolves back to your hostname
No major blocklist hits	Spamhaus, Barracuda, SORBS, SpamCop all rate you clean
TLS supported	Mail in transit is encrypted (table stakes in 2026)

ColdRelay's free deliverability test runs all of these in 30 seconds. No signup.

Table of Contents

• What a deliverability test actually does
• Every check explained
• How to validate at the receiving server (not just DNS)
• Comparison: ColdRelay's free test vs. mail-tester vs. GlockApps vs. MXToolBox
• What a "good" score actually predicts
• The full diagnostic flow when tests fail
• Pre-launch test checklist
• FAQ

What a Deliverability Test Actually Does

The phrase "deliverability test" covers two different categories of test:

1. DNS / configuration tests — these check your domain's setup: SPF, DKIM, DMARC, MX, BIMI, MTA-STS, PTR, TLS support. They tell you whether your authentication and routing are correct. They don't tell you whether mail actually lands in the inbox — they tell you whether the infrastructure supports it landing.

2. Seed-list inbox placement tests — these send a test email to a dozen+ pre-configured seed inboxes at major providers (Gmail, Outlook, Yahoo, Apple Mail, etc.) and report where the message landed: primary inbox, promotions, spam, or somewhere weirder. These tell you the actual outcome but cost money to run repeatedly and only sample a small panel.

For cold email specifically, you want both — but they answer different questions.

DNS/config tests answer "is anything obviously broken?" Run on every new domain before the first send. ColdRelay's free deliverability test covers this category. If it returns anything red, fix that before anything else.

Seed-list tests answer "is the inbox classifier actually ranking us as legitimate?" Run periodically (weekly) on production campaigns. ColdRelay's dashboard includes daily seed-list placement tests for connected sending tools at no extra cost.

The honest framing: DNS tests are necessary but not sufficient. They tell you what's broken; seed-list tests tell you whether the outcome is good. Skip either at your peril.

Every Check Explained

This is the canonical 2026 reference for what each check in a deliverability test actually verifies, what failure modes look like, and how to read the result.

SPF (Sender Policy Framework)

What it does: SPF tells receiving servers which IP addresses are authorized to send mail on behalf of your domain. Published as a TXT record at your apex domain.

Healthy SPF record:

v=spf1 ip4:20.x.x.x include:_spf.coldrelay-infra.com -all

What a passing result tells you: Receivers can verify your sending IPs against the published list. Mail from any IP listed in your SPF record is "SPF-aligned."

What a failing result tells you:

• PermError — your record is syntactically broken OR exceeds 10 DNS lookups. The most common cause: stacking multiple include: statements for Workspace, Microsoft, a cold email tool, and a transactional provider until you blow the budget. Fix with SPF flattening or by consolidating senders. Use the free SPF generator to count lookups.
• SoftFail (~all) — your record uses ~all instead of -all. Gmail interprets ~all as a weak signal and weights reputation accordingly. For cold email at scale, only -all is acceptable — soft-fail is the loophole spoofers exploit.
• None — no SPF record exists at all. Default landing at major receivers: spam folder.

Fix priority: Critical. Cold email at any volume needs a valid SPF record with -all (hard fail). If you're a ColdRelay customer, this is provisioned automatically — see how ColdRelay auto-configures SPF/DKIM/DMARC.

DKIM (DomainKeys Identified Mail)

What it does: DKIM adds a cryptographic signature to every outbound message proving (a) it came from your domain and (b) it wasn't tampered with in transit. The signing key sits on your sending server; the matching public key is published at <selector>._domainkey.<your-domain> in DNS.

Healthy DKIM record:

default._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0G..."

What a passing result tells you: Your sending tool is signing every outbound message with a key that matches the published public key. Receivers can cryptographically verify the message hasn't been altered.

What a failing result tells you:

• dkim=fail — the signature on the message doesn't verify against the published public key. Usually means a key mismatch (your sending tool is signing with one key while DNS publishes a different one), or the message body was modified in transit by a relay.
• dkim=none — no DKIM signature on the message at all. Your sending tool isn't signing, or DKIM was never configured. More damaging than SPF=none at major receivers in 2026.
• dkim=temperror — a transient DNS lookup failure. Retry; if persistent, your DKIM DNS record has propagation issues.
• dkim=permerror — your DKIM record exists but is syntactically broken. Common cause: line-wrapping in the published key, or copy-paste from a doc that added smart quotes.

Key size matters in 2026:

• 1024-bit RSA — historically standard; Google has been deprioritizing 1024-bit signatures since 2024.
• 2048-bit RSA — the 2026 default. ColdRelay signs every message with 2048-bit.
• Ed25519 — the future; not yet broadly supported by receivers, so still niche.

Fix priority: Critical. ColdRelay signs every outbound message with 2048-bit RSA at the SMTP layer. If you're configuring DKIM manually, use the DKIM generator tool and verify with the email header analyzer.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

What it does: DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also delivers aggregate reports so you can monitor authentication results.

Healthy DMARC record:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; aspf=r; adkim=r"

What each part means:

• p=quarantine — failing mail goes to spam. The recommended steady state for cold email.
• p=none — checkbox compliance only; doesn't actually do anything. Treated as suspicious-by-omission by Gmail.
• p=reject — failing mail is blocked entirely. Reserve for senders with airtight authentication for 30+ days.
• pct=100 — apply the policy to 100% of failing messages. Gradual rollouts use pct=25 or pct=50.
• rua=mailto:... — where aggregate reports go.
• adkim=r / aspf=r — relaxed alignment (subdomains count); s = strict (must match exactly).

Fix priority: High. Move to p=quarantine at minimum — failing messages go to spam rather than landing as if nothing happened. p=reject is even stricter but can cause edge-case legitimate mail to drop, so most cold email setups stay at quarantine. Use the DMARC generator tool for the syntax.

MX (Mail Exchange) Record

What it does: Tells the world where to deliver mail addressed to your domain. Required to receive replies — which cold email absolutely must do.

Healthy MX:

yourdomain.com.   IN   MX   10 mail.yourdomain.com.

What a failing result tells you:

• No MX record at all — you can't receive replies. Worse, receiving servers often check MX as a "is this a real domain?" sanity check. A domain without MX gets flagged as suspicious-by-omission.
• MX points to a nonexistent host — equally bad. Reply path is broken.

Fix priority: Critical. Cold email is conversational; if a prospect replies, you need to receive it. ColdRelay provisions MX automatically; manual setups commonly forget this when they're focused on outbound. Verify with the MX lookup tool.

BIMI (Brand Indicators for Message Identification)

What it does: Allows your logo to display next to your sender name in supported inboxes (Gmail, Apple Mail, Yahoo). Requires DMARC at p=quarantine or stricter plus a Verified Mark Certificate (VMC) from a certificate authority.

Healthy BIMI record:

default._bimi.yourdomain.com   TXT   "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"

Fix priority: Optional. BIMI is a brand-trust signal — measurable open-rate lift of 2–5% in some verticals — but it's not required for deliverability. The VMC costs around $1,500/year, which is overkill for most cold email response-rate math. ColdRelay supports BIMI for customers who want it but doesn't push customers into it by default.

MTA-STS (SMTP MTA Strict Transport Security)

What it does: Tells receiving servers to enforce TLS encryption when sending mail to your domain. Prevents downgrade attacks where an attacker forces a plaintext connection.

Healthy MTA-STS setup:

• A TXT record at _mta-sts.yourdomain.com declaring policy presence
• A policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing allowed MX hosts and TLS requirements

Fix priority: Medium. MTA-STS is increasingly important post-2025 as receivers like Google and Microsoft prefer senders that publish it. Not strictly required for cold email outbound (it protects inbound), but a positive signal in aggregate.

TLS-RPT (TLS Reporting)

What it does: Companion to MTA-STS — receivers can send your domain reports about TLS-handshake failures and downgrade attempts.

Healthy TLS-RPT record:

_smtp._tls.yourdomain.com   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Fix priority: Low-medium. Same audience as MTA-STS.

PTR (Reverse DNS) Record

What it does: Maps your sending IP back to a hostname. Anti-spoofing systems check that your sending IP's PTR record matches your sending domain — missing or generic PTR signals "transient cloud instance, probably not a legitimate mail sender."

Healthy PTR: Reverse lookup on 20.1.2.3 should return mail.yourdomain.com (or similar branded hostname).

Unhealthy PTR:

• Missing PTR — no reverse DNS configured. Treated as suspicious.
• Generic cloud-provider PTR — looks like ip-20-1-2-3.eastus.compute.example.com. Triggers "ephemeral cloud instance" classifier.

Fix priority: Medium-high. Major providers don't all enforce this strictly, but it's a noticeable signal — Microsoft especially weights PTR validation. ColdRelay configures PTR records pointing at your dedicated mail server (mail.<your-domain>) automatically.

Blocklist Status

What it checks: Whether your sending IP appears on any public DNS blocklist (DNSBL). Major lists scanned:

• Spamhaus (SBL, XBL, DBL, PBL, ZEN) — most influential.
• Barracuda BRBL — widely consumed.
• SORBS — older, still consulted.
• SpamCop — user-driven complaints feed this.
• UCEPROTECT — aggressive, often listed for adjacent IPs.
• Mailspike — used by some enterprise filters.
• CBL Abuseat — botnet-detection-driven.

What a failing result tells you: Your IP is on a list. Receivers using that list will reject your mail outright.

Fix priority: Critical. Pause all sending immediately. The fix depends on which list — see the blocklist removal hub for per-list delisting guides. For the major lists:

• Spamhaus SBL/XBL — submit removal via the Spamhaus delisting form. Typical resolution: 1–7 days.
• Barracuda — automatic delisting form, usually 24–48 hours.
• SpamCop — listings expire automatically after 24 hours of clean sending.
• SORBS — slowest to delist (sometimes weeks); usually means a serious incident. SORBS delisting guide.

If you're on a shared IP (cheap cold email infrastructure providers), a single bad neighbor can land you on a list with no warning. ColdRelay uses dedicated IPs per customer specifically to prevent this — your reputation is yours alone.

For ongoing monitoring, run the free blacklist checker or read the IP blacklist check guide and domain blacklist check guide.

TLS Support

What it checks: Whether your sending server supports TLS encryption on the SMTP port.

Fix priority: Low for cold email — if you're seeing this fail, something is dramatically misconfigured upstream. ColdRelay's SMTP layer enforces TLS on every connection. In 2026, plaintext SMTP from a cold-email-grade infrastructure provider is essentially unheard of.

How to Validate at the Receiving Server (Not Just DNS)

DNS-level checks confirm your setup. They don't confirm what the receiver actually sees on a real send. To validate at the receiving server, you need to inspect the headers of a real message that landed in a real inbox.

Step 1: Send a real test email

From the cold email mailbox you want to validate, send a test message to:

• A personal Gmail address you own
• A personal Outlook.com or Hotmail address
• A personal Yahoo address
• An iCloud address (for Apple Mail testing)
• A custom-domain test inbox (your alternate business email)

Step 2: Open the message and view the original/source

• Gmail: Three-dot menu → "Show original"
• Outlook: File → Properties → Internet headers
• Yahoo: Three-dot menu → "View Raw Message"
• Apple Mail: View → Message → All Headers

Step 3: Read the Authentication-Results header

You'll see something like:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=default;
  spf=pass smtp.mailfrom=user@example.com;
  dmarc=pass header.from=example.com

All three should say pass. Any of them saying fail / softfail / none is a problem.

Step 4: Read the Received headers

The Received: headers (read bottom-to-top) show every server the message touched between you and the recipient. Look for:

• A clean path through your dedicated infrastructure
• TLS-encrypted hops (look for "TLS" or "STARTTLS" annotations)
• No unexpected relays

Step 5: Note inbox placement

For cold email, you want Primary at every major receiver. The send-test-email guide walks through this end-to-end.

Comparison: The Major Deliverability Tests

The 2026 landscape of email deliverability tests, head-to-head:

When to use what

• First setup / new domain: ColdRelay's free test. Catches 90% of setup issues in 30 seconds.
• Per-campaign spot-check: mail-tester or send a manual test email to your own multi-provider inboxes (see send-test-email guide).
• Ongoing seed-list monitoring: GlockApps if you're standalone, ColdRelay dashboard if you're on the infrastructure.
• Blocklist deep-dive: MXToolBox for exhaustive list coverage, ColdRelay or MXToolBox for routine scans.
• DMARC report analysis: dmarcian or Postmark DMARC Monitor.

For a deeper read on mail-tester specifically, see mail-tester for cold email. For blocklist-specific tools, the MXToolBox blacklist check guide walks through their interface.

What a "Good" Score Actually Predicts

A clean DNS-level deliverability test (everything green) is necessary but not sufficient for inbox placement. The test predicts:

The honest correlation: in ColdRelay's onboarding data, domains that pass every DNS check on the free deliverability test achieve median 85%+ primary-inbox placement at Gmail when paired with proper warm-up, canonical send caps, and clean lists. Domains that fail any single check rarely exceed 50% inbox placement regardless of how good the rest of the stack is.

The DNS test is the floor. The other layers (warm-up, content, list quality, sending cadence, reputation maintenance) determine the ceiling. See the cold email deliverability complete guide for the full 7-layer model.

What "good" actually means by check

The Full Diagnostic Flow When Tests Fail

When your deliverability test fails, follow this diagnostic chain:

1. Identify the failing check(s)

Run the free deliverability test and note every red item. The order to fix them: authentication first (SPF → DKIM → DMARC), then routing (MX → PTR), then blocklist status, then optional layers (BIMI / MTA-STS).

2. Cross-reference with bounce / error codes

If your campaigns are bouncing, check the SMTP error codes hub — the specific 4xx or 5xx code from your sending tool tells you exactly which receiver-side check rejected the message. Common ones for cold email:

• 550 5.7.1 Message rejected — authentication required → SPF/DKIM/DMARC failure
• 550 5.7.0 Mail policy rejected by receiver → blocklist hit or content classifier
• 421 4.7.0 Try again later → rate limiting (volume pattern issue)
• 550 5.7.23 SPF check failed → SPF record missing or misconfigured
• 550 5.7.26 DKIM signature failed → DKIM key mismatch

3. If blocklisted, check which list

Use the free blacklist checker or MXToolBox to identify which DNSBL caught you. Then follow the per-list delisting guide on the blocklist removal hub.

4. Validate the fix

After applying any DNS-level fix:

1. Wait 5–60 minutes for DNS propagation.
2. Re-run the deliverability test.
3. Send a real test email to your multi-provider seed inboxes (send-test-email guide).
4. Confirm Authentication-Results header shows pass for all three (SPF, DKIM, DMARC).
5. Confirm Primary-inbox placement at Gmail and Outlook.

5. Monitor for regression

After the fix lands, set continuous monitoring:

• Run weekly DNS checks (manual or automated)
• Run daily seed-list tests if traffic justifies (ColdRelay dashboard does this automatically)
• Check Google Postmaster Tools weekly — see the Postmaster Tools for cold email guide
• Set blocklist alerts (ColdRelay's hourly DNSBL monitoring fires webhooks on listings)

Pre-Launch Test Checklist

Before turning on a new cold email campaign on a new domain:

1. Run the free deliverability test on the sending domain. All DNS checks must pass.
2. Send a test email to your own Gmail and Outlook inboxes. Verify it lands in Primary (not Promotions, not Spam).
3. Check the headers of the test email. Look for Authentication-Results: ... spf=pass dkim=pass dmarc=pass.
4. Confirm your reply path works. Reply to the test email — does it route back to a mailbox you actually monitor?
5. Check Google Postmaster Tools after 48 hours of sending. Domain Reputation should land at Medium or higher.
6. Run a blocklist scan — use the free blacklist checker — to confirm clean status.
7. Verify warm-up is running — see the cold email warm-up complete guide.
8. Confirm send caps are set to 2 outbound + 2 warmup per mailbox per day (the canonical 2026 cap).

This takes 10 minutes and catches 90% of deliverability disasters before they ruin a campaign.

FAQ

How often should I run a deliverability test?

Once per new domain pre-launch. Then weekly on active production domains. ColdRelay's dashboard runs continuous monitoring (hourly blocklist checks, daily seed-list placement tests) so you don't need to remember to re-test manually.

Is a free deliverability test as good as a paid one?

For DNS/configuration checks (SPF/DKIM/DMARC/MX/BIMI/MTA-STS/PTR/blocklist/TLS), free tests are equivalent to paid ones — the underlying DNS queries are the same regardless of which tool runs them. Paid tools differentiate on seed-list inbox testing (sending real test emails to a panel of inboxes), which costs money to maintain. ColdRelay's free tool covers the DNS layer; for seed-list testing, customers get it free as part of the platform.

What's the difference between an email deliverability test and an inbox placement test?

Deliverability test = checks the setup (DNS records, blocklists, encryption). Inbox placement test = checks the outcome (where does mail actually land at major inbox providers). Both matter; they answer different questions. See the send-test-email guide for the inbox-placement workflow.

My deliverability test passes but my emails still go to spam — what gives?

Three common causes after a clean test:

1. Content classification — subject lines or body text triggering content-based filters. Run an A/B test with two variants of copy using the A/B test planner.
2. Low domain reputation despite clean setup — typically a brand-new domain that hasn't warmed up yet. Pause for 7 more days at lower volume. See the cold email warm-up complete guide.
3. Engagement signals — if you have a high bounce rate or low reply rate, Gmail's engagement-based classifier downgrades you regardless of authentication. Tighten list quality with a verification service.

Do I need to test deliverability per mailbox, or just per domain?

Per domain for the DNS checks (SPF/DKIM/DMARC/MX/PTR/BIMI are domain-level). Blocklists are IP-level (but ColdRelay's dedicated IPs are 1:1 with customers, so testing once per domain captures it). Per-mailbox testing only matters if you're using radically different sending tools per mailbox, which is unusual.

Can I test a domain I don't own?

Yes — for the DNS-level checks, the data is public. You can test a competitor's domain to see how their authentication is configured. You can't run seed-list tests on someone else's domain (that requires sending mail).

What's the difference between checking with mail-tester vs ColdRelay's free test?

mail-tester sends one email to a generated address and returns a 0–10 score based on content + setup. ColdRelay's free test runs DNS checks directly without sending mail. mail-tester is useful for spot-checking a specific message's content classification; ColdRelay's test is the right tool for verifying your domain's authentication and routing infrastructure. They complement each other.

How accurate is the blocklist portion of the test?

ColdRelay's free test queries 6 major blocklists (Spamhaus ZEN, Barracuda BRBL, SORBS, SpamCop, UCEPROTECT, Mailspike). For a wider sweep (100+ lists), use the dedicated free blacklist checker or MXToolBox. For most cold email senders, 6-list coverage catches all consequential listings.

Does ColdRelay's test work on Workspace / Microsoft 365 domains?

Yes — the DNS checks are infrastructure-agnostic. The test will tell you whether your Workspace-routed domain has correct SPF/DKIM/DMARC, which is the same question regardless of who's actually sending the mail. If you're considering moving from Workspace to dedicated infrastructure, see Google Workspace vs dedicated cold email infrastructure.

What if I have legitimate forwarded mail that's failing DMARC?

DMARC's relaxed alignment (adkim=r; aspf=r) handles most forwarding cases. If you're seeing forwarding-specific failures, the receiver may be re-writing the From address (ARC chains) — this is normal and not actionable from your side. Make sure your DMARC pct is at 100 only after you've confirmed legitimate forwarding paths are passing.

Test your domain free → Run the deliverability test · Run cold email on infrastructure built to pass every test → Try ColdRelay free · Compare ColdRelay vs Workspace TCO → Pricing