Deliverability tools
we use ourselves.
These are the diagnostics we run on every customer at provisioning, before first send, and during incidents. Free for anyone to use. No accounts, no tracking pixels, no email capture, no sales follow-up unless you start one.
Blacklist Checker
Check any IP or domain against 84 DNS-based blocklists including Spamhaus, Barracuda, SORBS, UCEPROTECT and SURBL.
SPF / DKIM / DMARC Validator
Validate authentication records on any sending domain. Identifies misconfigurations, alignment issues, and DMARC enforcement gaps.
MTA-STS Validator
Verify MTA-STS policy file, DNS record, MX coverage, and TLS-RPT companion. Tells you whether you can safely promote from testing to enforce mode.
TLS-RPT Parser
Paste a TLS-RPT JSON aggregate report and get a human-readable breakdown: connection outcomes, failure types per category, action items.
BIMI Eligibility Checker
Check whether a domain meets all four BIMI prerequisites: DMARC enforcement, BIMI DNS record, conformant SVG profile, valid VMC certificate.
rDNS / FCrDNS Tester
Verify reverse DNS, forward A record alignment, and FCrDNS (Forward-Confirmed reverse DNS) for any sending IP. The most common deliverability misconfiguration.
DKIM Key Audit
Audit DKIM key strength on any sending domain. Identifies 1024-bit keys (deprecated), sha1 algorithm (downgraded), test mode flags, revoked selectors.
Operational order during an incident.
The seven tools above are listed by feature rather than by when you would reach for each one. In a real incident the operational order matters because some diagnostics produce information that constrains where to look next. The order below reflects how we work through an unfamiliar sender situation during an audit, and it produces the most signal per minute of investigation time.
First: check the blacklist status. The 84-RBL blacklist checker takes one IP or one domain and returns the listing status across the consequential blocklists. If the result shows Spamhaus SBL, CSS, or DBL listing, the diagnostic path narrows dramatically: stop sending immediately, identify the listing reason from the Spamhaus interface, prepare an evidence-backed delisting submission, and address the root cause before resuming. If the result is clean, blocklist status is eliminated as the immediate cause and the investigation moves to authentication.
Second: verify authentication alignment with the SPF/DKIM/DMARC validator. Authentication failures are the largest single category of deliverability problems in 2026 because Gmail and Microsoft both moved to SMTP-level rejection for senders failing authentication. The validator identifies misalignment between the From header domain and the DKIM signing domain, SPF authorisation gaps for sending IPs, and DMARC policy enforcement levels. Any failures here need to be fixed before the rest of the diagnostic chain provides useful signal.
Third: verify reverse DNS alignment with the rDNS/FCrDNS tester. Forward-confirmed reverse DNS (the property that an IP's PTR record points to a hostname whose A record points back to the same IP) is the most common silently-broken element in production sending infrastructure. Receivers including Gmail, Microsoft, and enterprise gateways check this and downgrade unverified senders. The tester identifies missing PTR records, mismatched forward records, and HELO greeting misalignment that would also affect placement.
Fourth: verify DKIM key strength with the DKIM key audit. Most senders set up DKIM keys once and never rotate them. Keys deployed before 2018 are commonly 1024-bit, which receivers including Gmail and Microsoft now treat as weaker than 2048-bit and increasingly ignore for reputation purposes. The audit identifies undersized keys, weak algorithms (SHA-1), test-mode flags that should have been removed in production, and revoked selectors that are still configured.
Fifth, for senders running modern infrastructure: verify MTA-STS and BIMI compliance. MTA-STS validation confirms that the policy file, DNS record, and MX coverage are aligned and that the sender can safely promote from testing to enforce mode. BIMI eligibility checks the four prerequisites that determine whether the sender qualifies for logo display: DMARC enforcement at p=quarantine or p=reject, BIMI DNS record, conformant SVG profile, and valid VMC certificate. These tools surface configuration gaps that prevent inbox-display features even when basic deliverability is fine.
For senders with aggregate reporting: the TLS-RPT parser converts the JSON aggregate reports that modern MTA implementations publish into a human-readable breakdown of connection outcomes, failure types per category, and action items. The reports are most useful for senders running MTA-STS at policy=enforce mode where TLS connection failures cause actual mail loss rather than just observation events.
What we did and did not build into these tools.
The tools run client-side or server-side depending on what the diagnostic requires. Blacklist checks run server-side because DNS queries from a stable IP produce more reliable results than queries from the user's browser. SPF, DKIM, DMARC, MTA-STS, and BIMI validations run server-side because DNS lookups during the validation chain require a consistent execution environment. The rDNS tester and DKIM key audit also run server-side for the same reason. No tool requires JavaScript on the client beyond form submission and result rendering.
We do not retain query data. Every diagnostic runs in memory for the duration of the request and the inputs and outputs are discarded when the request completes. We do not log which domains or IPs were checked, when, or from which client. This is structural rather than aspirational: the tools live on infrastructure configured without query logging at the application layer, and we do not have access to the data even if we wanted it. The privacy posture is the same as for our paid services.
We do not capture email addresses or require account creation for any tool. The structural value of the tools depends on being usable at the moment of the operational problem without an additional barrier to access. Tools that require signup are designed for lead generation, not for diagnostic value. We have a lead-generation funnel for customers who want to engage us; it lives behind Telegram and ticket-based contact, not behind a free tool. The tools are free because they are operationally inexpensive to run and they help operators (including operators who never become customers) make better deliverability decisions.
Questions we get about the tools.
Are the results from these tools authoritative for delisting submissions?
The blacklist checker reports the same listing status that Spamhaus and the other RBLs publish through their own interfaces. For delisting submissions you should always reference the authoritative source (the blocklist operator's own lookup page) because that is what they will check. The tool here is faster for screening across many blocklists at once and identifying which ones to investigate further; the authoritative source is what matters for the submission itself.
Why do the SPF and DKIM results sometimes differ from other tools?
DNS-based diagnostics depend on which resolver answers the query and what the resolver's cache state is at the moment. We use authoritative-server queries where possible to eliminate cache effects, but some receivers use different resolution paths that produce different intermediate results. The validator output is consistent with what major receivers actually evaluate, but specific corner cases (CNAME flattening differences, EDNS handling, response truncation) can produce minor result differences across tools. If results disagree between two tools, the test that matches actual receiver behaviour (visible in DMARC aggregate reports or rejection messages) is the one to trust.
Can I use the tools for domains I do not own?
Yes. All the tools query publicly-available DNS records and public blocklist status. None of them require ownership or authentication. The intended use cases include competitive analysis, pre-engagement due diligence on prospects, and auditing partners or vendors before sending them traffic. We do not rate-limit individual operators heavily, but automated scraping that produces sustained high query volume is detected and throttled to protect the underlying infrastructure.
Is there an API for these tools?
Not currently. The tools are designed for interactive operator use rather than automated integration. Customers who need programmatic access to similar diagnostics as part of an automated monitoring stack can ask on Telegram; we have built custom monitoring integrations for several managed-service customers, and most of those projects start from a conversation about the specific operational requirements rather than a generic API contract.
Do the tools work for IPv6 addresses and hostnames?
The blacklist checker, rDNS tester, and DKIM audit all handle IPv6 correctly. The MTA-STS, BIMI, and TLS-RPT validators are domain-only and do not require IP input. The SPF/DKIM/DMARC validator handles domains regardless of whether the sending infrastructure resolves to IPv4 or IPv6. Operators running dual-stack sending should verify both stacks separately; receivers can apply different reputation rules to the two stacks even when the configuration appears identical.
Tool design philosophy and what each tool aims to deliver
Our tools follow specific design philosophy that distinguishes them from the broader landscape of free email infrastructure tools. The philosophy reflects operational priorities that operators using the tools for real work benefit from.
Principle 1: actionable output over comprehensive reporting. The tools produce focused output that supports specific operational decisions rather than comprehensive reports that operators must interpret. The SPF validator surfaces the specific issues affecting authentication; the rDNS tester surfaces the specific configuration problems; the blacklist checker surfaces the specific listings with their context.
Principle 2: honest reporting of limitations. Each tool clearly indicates what it can and cannot detect. Authentication validators that pass do not mean the broader sending operation will succeed; they mean the specific authentication mechanisms are configured correctly. The honest framing prevents the common pattern of operators interpreting passing validators as broader operational health.
Principle 3: no data collection beyond operational requirements. The tools do not log queries beyond what is operationally required for the tool functionality. Operators using the tools do not appear in analytics, do not receive follow-up marketing, do not have their queries retained beyond brief operational windows. The privacy posture matters because tools collecting query data create incentives for tool operators to monetize that data in ways that compromise the tool utility.
Principle 4: real receiver and protocol behaviors rather than simulated checks. The tools query real DNS, real receivers, real protocol implementations. Some tools in the broader ecosystem use simulated checks that produce different results from real-world conditions; our tools query the actual systems that affect the customers operations.
How operators integrate tools into their workflows
Operator usage patterns across the tools collection, captured through analytics and customer conversations about how the tools fit into broader operational workflows.
Pattern 1: deployment validation. Operators deploying new infrastructure run validation tools to confirm configuration is correct before sending traffic. The SPF validator, DKIM checker, rDNS tester, and DMARC analyzer get heavy use in this pattern. Validation typically happens during the final phase of deployment work; tools surface issues that operators address before cutover.
Pattern 2: troubleshooting reference. Operators investigating specific deliverability issues use tools to diagnose root causes. The blacklist checker, SPF/DKIM/DMARC validators, and TLS-RPT parser get heavy use in this pattern. Troubleshooting sessions typically use 2-4 tools in combination to isolate specific issues.
Pattern 3: ongoing operational verification. Operators verify ongoing operational health through periodic tool usage. Weekly or monthly tool runs confirm that infrastructure remains correctly configured as the broader operational environment evolves. The verification pattern catches configuration drift that operators might not notice through other monitoring.
Pattern 4: customer-facing documentation. Operators serving downstream customers use the tools to produce documentation for their own customers. The tool outputs support customer-facing diagnostic conversations and provide evidence for service quality claims that customer-facing teams need to support.
Tools roadmap and how new tools get added
The tools collection evolves based on operational priorities rather than feature completeness ambitions. The structural reasoning is that tool proliferation produces operational overhead without proportional value; selective addition of tools that address specific operational gaps produces better outcomes than broad coverage of marginally-useful capabilities.
New tool additions follow customer demand patterns. When customer support requests cluster around specific diagnostic needs that existing tools do not address, new tools enter consideration. Tools that would receive substantial customer use typically reach development; tools that would receive marginal use typically do not.
Tool removal happens when tools become obsolete. Industry conditions evolve in ways that make specific tools less relevant over time. Tools that no longer address current operational needs are eventually removed rather than maintained indefinitely. The removal is gradual; deprecated tools continue operating for extended periods before final removal to avoid disrupting operators relying on them.
Tool updates happen when receiver behaviors or protocol details change. Authentication validator updates following the 2025-2026 Gmail and Microsoft enforcement changes captured the new SMTP-level rejection behaviors. Future updates will follow similar industry condition changes; the update cadence is event-driven rather than scheduled.
Common patterns we observe across tool usage
Beyond the individual tool patterns documented above, several aggregate patterns emerge across the tool collection that operators benefit from understanding.
Pattern A: tool combinations rather than single-tool usage. Operators typically use 2-4 tools in combination for any given diagnostic situation. The authentication validators combine with the rDNS tester to confirm broad infrastructure configuration; the blacklist checker combines with the SNDS analyzer to investigate reputation issues. Single-tool usage is rare; the tools work better in combination than independently.
Pattern B: periodic verification cycles. Operators establish periodic verification cycles using tools to confirm ongoing operational health. Weekly cycles work for stable operations; daily cycles work for operations going through active changes; monthly cycles work for operations with infrequent operational changes. The pattern catches configuration drift and infrastructure changes that operators might not notice through monitoring alone.
Pattern C: customer-facing usage. Operators serving downstream customers use tools to support customer-facing conversations. Tool outputs that demonstrate specific configuration outcomes support customer trust building and provide evidence for service quality claims. Customer-facing tool usage is common among ESP operations and agency operations rather than direct sending operations.
Pattern D: training and onboarding. Operators bringing new team members into email operations work use tools as part of training material. The tools demonstrate concepts that documentation describes abstractly, producing faster learning than documentation alone. Training sessions typically work through 4-8 tools depending on the team member role scope.
Pattern E: vendor evaluation. Operators evaluating vendor offerings use tools to validate vendor claims. Authentication validators run against vendor-provided configurations identify whether the vendor implementation actually delivers; the validation produces evidence-based vendor evaluation rather than marketing-claim-based evaluation.
Tool comparison with broader ecosystem options
The email infrastructure tooling ecosystem includes many tools from various sources. Our tools cover specific use cases with specific design choices; the comparison below identifies where our tools fit relative to broader ecosystem options.
Comparison 1: authentication validators. Many free authentication validators exist including MXToolbox, DMARCian, Mail-Tester, and several others. Our authentication validators distinguish themselves through honest reporting (specific issues identified rather than general assessment) and through privacy posture (no data retention beyond brief operational windows). Operators preferring different tradeoffs find appropriate options in the broader ecosystem.
Comparison 2: blacklist checkers. Multiple free blacklist checkers exist including HetrixTools, MXToolbox, and others. Our blacklist checker covers a specific subset of blocklists chosen for operational relevance rather than comprehensive coverage. Operators needing comprehensive blocklist monitoring benefit from dedicated monitoring services; operators needing point-in-time checks find our tool sufficient.
Comparison 3: deliverability assessment. Comprehensive deliverability assessment platforms exist including 250ok, Validity, GlockApps with extensive feature sets. Our tools cover specific operational questions rather than comprehensive deliverability assessment; operators needing comprehensive assessment benefit from the platform options. Our tools support focused diagnostic and verification work that platforms address as part of broader functionality.
Comparison 4: receiver-side reputation. Postmaster Tools (Gmail), SNDS (Microsoft), and similar receiver-side dashboards provide visibility our tools do not duplicate. Our tools complement receiver-side dashboards rather than replacing them; operators benefit from using both receiver-side dashboards and our tools.
Comparison 5: protocol-specific tools. Various specialized tools cover specific protocols (DNS analysis, TLS inspection, MTA configuration). Our tools cover the common operational protocols; specialized tools cover broader scope. The combination supports comprehensive operational visibility when specific situations warrant the broader scope.
Privacy considerations and data handling for tool usage
Privacy considerations for tool usage matter to operators who use diagnostic tools while handling sensitive customer data. Our tools follow specific data handling practices that produce privacy properties operators evaluating tool options benefit from understanding.
Practice 1: minimal logging. Tool queries log only what is required for operational purposes: brief query records for rate limiting and abuse prevention, no persistent retention of query content, no analytics tracking of individual operators using the tools. The minimal logging matches our broader operational philosophy of collecting only what operational requirements demand.
Practice 2: no third-party tracking. The tools do not include third-party analytics, advertising trackers, or social media integration. Operators using the tools do not appear in third-party analytics, do not generate marketing profiles, do not have their usage shared with parties beyond our infrastructure.
Practice 3: query content isolation. When tools query external services (DNS resolvers, receiver postmaster endpoints, blocklist services), the queries flow through our infrastructure rather than directly from the operator browser. The pattern prevents external services from observing operator IP addresses or other client-identifying information.
Practice 4: result isolation between operators. Tool results do not persist beyond the immediate session; one operator cannot see results from another operator queries; results do not accumulate into searchable archives. The isolation supports operators using the tools for sensitive diagnostic work without producing persistent records that could be subject to legal-process exposure.
Browser compatibility and accessibility considerations
Tool browser compatibility extends to current versions of major browsers including Chrome, Firefox, Safari, Edge. Older browser versions may produce reduced functionality but typically maintain core diagnostic capabilities.
Mobile browser support: tools function on mobile browsers with reduced screen real estate optimization. Operators using tools primarily for mobile diagnostic work benefit from responsive layouts; complex diagnostic work typically benefits from desktop usage where output volume justifies larger viewport.
Accessibility considerations: tools follow standard accessibility patterns including keyboard navigation, screen reader compatibility, sufficient color contrast for readability. Operators with specific accessibility requirements that current tools do not address can report issues through standard support channels; we address accessibility issues as priority items.
Feedback channels for tool improvement
Tool improvement reflects customer feedback rather than internal-only priorities. Operators encountering tool issues, suggesting improvements, or requesting new capabilities benefit from explicit feedback channels.
Feedback through standard support channels (Telegram, support tickets) reaches the team responsible for tool development. Feedback that identifies specific issues or specific improvements receives explicit response; feedback expressing preferences different from current design choices receives acknowledgment without commitment to align with the preferences.
Tool improvement priority reflects aggregate customer benefit rather than individual customer requests. Feedback from multiple customers identifying the same issue or improvement receives higher priority than feedback from individual customers; the pattern produces tool evolution that serves the customer base rather than specific customer preferences.
Because the existing tools are bad on purpose.
Most deliverability tools online require an account, capture your email, and follow up with sales sequences. The data is gated behind sign-up flows and the actual results are watered down to push you toward the paid tier.
We don't have a free-tier-to-paid-tier funnel. These tools cost us a few DNS queries and they help our customers (and competitors' customers) make better decisions about deliverability. If you become a customer because of them, that's a side effect we don't mind. If you don't, that's also fine.