Email deliverability tools: which layer each tool can actually test

There is no single email deliverability tool.

There are DNS checkers, provider telemetry, message scorers, seed-list placement tests, blocklist monitors, mailbox simulators, and campaign dashboards. They answer different questions.

Pick the suspected failure layer first. Then use the smallest tool that can return evidence about that layer.

Map the layers before buying a dashboard

“Deliverability” compresses several systems into one word.

No tool owns all eight. A DNS checker can find a missing record and still know nothing about the list. A placement test can show a seed result and still know nothing about a real recipient's interest. A campaign dashboard can count bounces and still hide the exact provider response.

Write the symptom and suspected layer before starting a trial. If the team cannot name the layer, begin with the cold email deliverability diagnostic instead of another subscription.

Start with the symptom

Do not begin with a random score and work backward. Begin with the failure you can describe.

What the common tools actually test

The useful tools expose the evidence under the score. If all you can export is “82/100,” the next operator still does not know what failed.

Google Postmaster Tools

Google Postmaster Tools exposes Google-observed dashboards for eligible traffic to personal Gmail accounts. Depending on available data, those dashboards include user-reported spam rate, domain and IP reputation, authentication, encryption, delivery errors, and feedback-loop information.

It is provider telemetry, not a universal placement tester. Low-volume traffic may produce no data under Google's privacy thresholds. The dashboard does not describe Microsoft recipients or every Google Workspace mailbox.

Use it when the symptom is Gmail-specific and the domain is eligible for data. Preserve the exact property, metric, date range, missing days, and next evidence. Do not use one reputation category to grade an inbox reseller.

Microsoft SNDS

Microsoft Smart Network Data Services provides data for IP ranges the authorized user can register and prove control over. Its scope is tied to the visible sending IP evidence available to that owner.

It is not a general Microsoft 365 domain dashboard and may not be available to someone sending through shared provider infrastructure they do not control. Before treating SNDS as a required tool, identify the IP from a real message, determine ownership, and confirm whether the organization can legitimately register it.

Use Microsoft SMTP responses and account/provider evidence when SNDS does not cover the path. Do not fill the gap with a guessed IP reputation.

MXToolbox

MXToolbox combines DNS and authentication lookups, blocklist checks, diagnostics, and monitoring products. It is useful when the question is whether a record resolves, whether a checked list contains the queried domain or IP, or whether a monitored condition changed.

The lookup is not the real message. An SPF record can exist while the message authenticates a different MAIL FROM domain. A DKIM key can resolve while the message was not signed or was modified later. Pair the tool result with final-recipient headers.

For monitoring, record exactly which hostname, record, or list is checked, how frequently, what creates an alert, and who owns the response. “Blacklist monitoring enabled” is too vague to operate.

GlockApps

GlockApps offers seed-list placement testing and related authentication, content, monitoring, and deliverability features depending on the selected plan. The core placement workflow sends a controlled message to test accounts and reports where those messages landed.

That makes it useful for repeatable comparisons when the sender, content, authentication, timing, tool version, and seed set are preserved. It does not make the seed accounts representative of every real recipient.

Use it to test one narrow change. If the test and real campaign disagree, keep both results. Investigate audience, provider mix, account state, and measurement instead of declaring one source wrong.

Mail-Tester

Mail-Tester provides a single-message technical check and combined score. It can surface authentication, content, and listed-infrastructure observations for the submitted test message.

Open the evidence under the score. Record which checks failed, which identities were used, and whether the test message followed the real campaign path. A perfect score does not prove future inbox placement or recipient interest.

This kind of tool is most useful before launch or after a technical change. It is less useful as the only explanation for a campaign-level reply decline.

Mailtrap

Mailtrap is broader email development and sending infrastructure. Its products include sandbox, template, and sending workflows rather than one cold-email reputation verdict.

It belongs in the toolkit when developers need to inspect templates, headers, code paths, and test sends without delivering to production recipients. It should not be placed in the same column as a seed-list placement subscription without naming the different job.

If the problem is a generated template, malformed header, or application send path, a development sandbox may be the right first tool. If the problem is Gmail complaints on a live outbound domain, it is not.

Compare evidence products on operating fields

Price matters after the evidence type is matched.

Do not buy three tools that all show DNS existence while none preserves provider errors or campaign identifiers. Build the toolkit from non-overlapping questions.

A failure-layer decision tree

Authentication failed

Use the final recipient's headers first.

Compare the visible From domain, the SPF-authenticated MAIL FROM domain, the DKIM d= domain, and the DMARC result. Then check the authoritative DNS records.

If the DNS checker is green but the message is red, the message path wins. The SPF, DKIM, and DMARC guide explains the alignment check.

A provider returned an error

Keep the full SMTP response, timestamp, sending account, recipient provider, and retry history. Search the provider's current documentation for that exact error. Do not replace the evidence with a generic “spam block” label.

Use Google Postmaster Tools for Google-specific observations and Microsoft SNDS where it applies. Neither one describes the entire internet.

Placement looks different

Run a controlled placement test if it will answer a narrow question. Keep the message, sender, time, seed set, authentication state, and tool version.

Then repeat after changing one variable.

A seed test can show that those messages landed in specific test accounts. It cannot prove the next 5,000 real recipients will behave identically.

Bounces increased

Start with the bounce classes and list source.

Separate invalid addresses, mailbox-full responses, policy rejections, provider throttling, DNS failures, and connection errors. If one data source is responsible for most hard bounces, a placement tool is not the first fix.

Replies fell

Low replies can come from placement, list quality, targeting, offer, copy, timing, or measurement. Check whether bounces, complaints, provider errors, recipient mix, data source, or campaign behavior changed at the same time.

Open rate alone is a weak diagnostic. Image blocking, privacy features, and scanners can move it without a matching change in human attention.

Run the symptom playbooks without changing every layer

The DNS checker is green but DMARC fails

Open a message received through the real campaign route. Compare the visible From domain, SPF-authenticated MAIL FROM domain, DKIM d= domain, and DMARC result.

Then use an authoritative DNS lookup to inspect the exact hostnames and selectors from that message. If the checker inspected the root domain while the message used another Return-Path or selector, both results can be technically correct. Fix the actual identity path, send a new message, and preserve before-and-after headers.

A placement test changed after a content edit

Keep the sender, mailbox, domain, recipient seed set, schedule, authentication, and tool version stable. Compare the exact messages and links.

Repeat the test with one controlled edit. If several changes shipped together, restore the prior version or build a smaller comparison. Do not use a single seed result to announce that one phrase controls placement. The evidence supports only the tested sample and conditions.

A blocklist monitor alerts

Open the authoritative source for the listed domain or IP. Confirm the exact identifier, list, timestamp, current state, and available removal or remediation instructions.

Then establish whether the affected campaign actually used that identifier. A shared provider IP may be visible without being customer-controlled. A domain listing may not explain an account-level restriction. Preserve the provider path and recipient responses before choosing the owner.

Hard bounces cluster after a new list

Group the exact responses by list source, verification date/status, domain, campaign, and recipient provider. Separate invalid-address responses from mailbox-full, policy, throttling, DNS, and connection failures.

If the cluster follows the new data source, pause that source and review identity, verification, suppression, and age. A seed placement product is not the first tool for a known invalid-address problem.

One mailbox fails while the domain looks normal

Check the mailbox connection, provider status, restriction notice, credentials or OAuth state, and exact provider response. Compare another mailbox on the same domain and campaign.

If the failure stays with one account, keep the domain and list stable while the account owner investigates. Rewriting DNS for every mailbox can turn a contained account problem into a domain problem.

Replies decline while technical checks stay stable

Verify that replies are still routed, classified, and measured. Then compare recipient mix, list source, targeting, offer, copy version, schedule, links, and negative responses.

Technical stability does not prove inbox placement, but it does narrow the first move. Do not replace infrastructure because the easiest dashboard stayed green and the hardest business signal moved.

Build one evidence record

Do not leave the diagnosis trapped across six dashboards.

symptom:
first_observed_at:
affected_domain:
affected_mailboxes:
recipient_provider:
campaign_and_step:
list_source:
copy_version:
authentication_results:
provider_errors:
postmaster_or_snds_signal:
placement_test_and_seed_set:
blocklist_checks:
change_made:
retest_result:
owner:

This makes tools replaceable. The evidence stays useful even if the team stops paying for the product that displayed it.

Build a minimum toolkit by responsibility

Most teams need fewer products than comparison pages suggest.

At minimum, preserve access to:

1. Authoritative DNS and a way to resolve records externally.
2. Original received-message headers.
3. Full provider or SMTP responses from the sending path.
4. Campaign records with list source, copy version, domain, mailbox, and timestamps.
5. Provider telemetry such as Postmaster Tools or SNDS when the path and volume qualify.
6. A controlled placement test only when it answers a defined question.
7. A monitor only when an owner and response playbook exist.

Add a paid tool when it closes a known evidence gap or reduces repeated manual work. Remove it when the same evidence is already available elsewhere and nobody uses its history or alerts.

Review the toolkit quarterly or after a provider, sequencer, DNS, or campaign-measurement change. Update property access, monitored identifiers, alert owners, and export paths. A tool configured for last year's domains is not current coverage.

Decide what needs monitoring and what needs an investigation

Monitoring and diagnosis are different jobs.

A monitor checks a known condition repeatedly and alerts an owner. An investigation starts with a symptom, collects several sources, and tests a hypothesis. Buying a monitor does not create the response process.

Use a monitor when all of these are true:

• the exact domain, IP, record, certificate, provider property, or campaign event is known;
• the check can observe a meaningful change;
• the alert has a severity and owner;
• the owner has a current response playbook;
• the system preserves enough history to compare the change;
• the subscription cost is justified by manual effort or response time.

Do not monitor every possible list or score because a tool offers it. An alert nobody understands trains the team to ignore the dashboard.

Build the alert record

monitored_identifier:
source_or_tool:
condition:
check_frequency:
normal_or_baseline_state:
alert_threshold_or_change:
severity:
owner:
first_response:
corroborating_source:
escalation:
last_tested_at:

Test the alert safely before trusting it. Confirm the notification reaches the correct person, contains the affected identifier, and links to the underlying evidence. Then run the response playbook far enough to prove the owner can choose the next check.

Keep provider and campaign alerts separate

A DNS-record change, mailbox restriction, provider rejection, spam-rate movement, placement-test change, bounce cluster, and reply-routing failure have different owners. Route them accordingly.

Do not send every alert to the person managing DNS. Do not ask the copywriter to interpret an SMTP response. The shared evidence record can connect the incident while each layer stays with the person who can change it.

Use free checks before buying overlapping subscriptions

Several high-value sources already exist in the infrastructure:

• authoritative DNS;
• final-recipient message headers;
• Google Postmaster Tools when eligible;
• Microsoft SNDS when the organization controls the relevant IP range;
• provider notices and full SMTP responses;
• sequencer sends, skips, bounces, replies, and connection events;
• verification and suppression history;
• a controlled internal test message.

Start there. A paid product earns its place when it adds a needed seed set, history, alerts, multi-domain operations, report workflow, or evidence the team cannot collect efficiently another way.

Avoid paying twice for the same surface. A broad monitoring platform and a mailbox provider may both display DNS state. A sequencer and a placement tool may both show a score. Compare the raw inputs and history before assuming two dashboards equal two independent sources.

The commercial unit also needs to match the job. Record whether the provider charges by test, domain, monitor, user, inbox, credit, monthly plan, or annual commitment. Do not calculate a fake per-mailbox cost for a domain monitor or seed test.

Run a 30-day tool trial with defined cases

Use several known cases instead of waiting for a real crisis:

1. Inspect a healthy received message and confirm the tool preserves the same authentication identities.
2. Use a controlled DNS or test-domain condition to verify the diagnostic and alert path where safe.
3. Run a seed test twice without changes to observe normal variation.
4. Run it again after one documented message or infrastructure change.
5. Import or record a known provider response and test classification.
6. Review a hard-bounce cluster by source.
7. Confirm a missing-data state remains “inconclusive,” not “healthy.”
8. Export the evidence and hand it to another operator.

Score the trial:

Reject a tool that creates a confident score and hides the evidence required to challenge it.

Close the investigation with a decision

Every tool result should end in one of these actions:

• Fix: the evidence identifies a broken configuration or connection owned by the team.
• Pause: the campaign, source, account, or tracking path meets a written stop condition.
• Corroborate: the signal is scoped but another source must confirm the layer.
• Retest: one controlled change has been made and the same evidence path will run again.
• Monitor: no immediate change is justified, but the condition and owner remain active.
• Reject the hypothesis: the evidence does not support the suspected cause.

Record the action, owner, timestamp, and result. “Checked deliverability” is not an outcome.

Keep a short final report:

symptom and affected slice:
first evidence source:
tools used and represented scope:
raw results retained at:
corroborating evidence:
hypothesis:
change made:
retest conditions and result:
decision:
remaining uncertainty:
owner and next review:

That report prevents the next incident from starting with screenshots and conflicting memories. It also exposes whether the paid tool shortened the investigation or only added another score.

Build a small evidence schedule

Not every check belongs on the same schedule. Keep routine monitoring narrow enough that someone will review it, and reserve deeper tests for a trigger.

Do not turn this into a wall of automated screenshots. Each scheduled check needs a threshold, a named reviewer, and a recorded decision. Remove a monitor when nobody can explain what action its alert should cause.

Keep the baseline scoped. “Replies were 3% last month” hides the list source, offer, provider, domain, mailbox, and campaign mix. Store enough dimensions to compare like with like, while respecting the privacy and retention rules for the underlying data.

Review the schedule quarterly. A check that never changes a decision is noise, not coverage. Record why each monitor stays.

What no deliverability tool can prove

No score proves that:

• a real recipient wants the email;
• a technically valid address is the right person;
• a Google result applies to Microsoft;
• a seed-list result applies to every campaign;
• a blocklist check clears every reputation system;
• changing mailbox resellers changes Google's or Microsoft's underlying transport;
• one clean test makes the next campaign safe.

Cheap Inboxes supplies the domain and mailbox operations around Google and Microsoft accounts. It does not turn a score into a placement promise. Use the cold email deliverability diagnostic to scope the failure before buying another dashboard.

The right deliverability tool is the one that returns the next piece of evidence with enough scope and history to act on it. Start with the broken layer. Keep the raw result. Change one thing. Retest.

Sources

• Google Postmaster Tools
• Microsoft Smart Network Data Services
• MXToolbox deliverability tools
• GlockApps pricing
• Mail-Tester
• Mailtrap pricing