Skip to content

Email diagnostic tools

The Mailexam website includes a set of free tools for checking DNS records and domain reputation. No sign-up is required: enter a domain or IP and get results with explanations and recommendations.

The tools are available from the Quick test section on the homepage and from the site footer. Each tool page links to the others.

When to use them

  • Before production mail — confirm SPF, DKIM, and DMARC are configured correctly.
  • When deliverability drops — check RBL listings, PTR, and MTA-STS policy.
  • For brand display in inboxes — verify your BIMI record and logo readiness.

Available checks

Tool What it checks Link
SPF Sender Policy Framework TXT record: authorized senders, syntax, -all policy Check SPF
DKIM Public key in DNS by selector; if missing — key pair generator and ready-to-publish TXT Check DKIM
DMARC _dmarc policy, p= mode, reporting address Check DMARC
RBL IP or domain against 50–100 major spam lists (Spamhaus, Barracuda, SURBL, etc.); results stream in real time Check RBL
Reverse DNS (PTR) Sending IP PTR record and forward/reverse DNS alignment Check PTR
MTA-STS and TLS-RPT Enforced SMTP encryption policy and TLS reporting record Check MTA-STS
BIMI Brand Indicators for Message Identification — BIMI record and brand logo display readiness Check BIMI

SPF, DKIM, and DMARC

These three tools share one page template: enter a domain; for DKIM also provide a selector (default default). After the check you see:

  • status: pass, needs attention, or not found;
  • the DNS record found and a syntax breakdown;
  • step-by-step setup guidance if the record is missing or unsafe.

For DKIM with a “not found” status, you can generate a key pair (1024, 2048, or 4096 bits) with a ready TXT value for DNS.

Background on the terms — in the glossary: SPF, DKIM, DMARC.

Tools vs sandbox

DNS checks are not tied to Mailexam test SMTP: for sandbox you only change SMTP credentials; domain records are not required. These tools are most useful when you move to production mail to real recipients.

RBL (blocklists)

RBL (Realtime Blackhole List) and DNSBL (DNS-based Blackhole List) are public lists of IP addresses and domains associated with spam, phishing, malware, or other suspicious sending behavior. Large mailbox providers and anti-spam filters check the sender against these lists before evaluating SPF, DKIM, and message content.

How a listing affects deliverability

Situation Typical outcome
IP on one “soft” list Mail more often lands in spam or is deprioritized
IP on several authoritative lists (Spamhaus, Barracuda) SMTP rejection (550), widespread bounces
Sending domain on SURBL and similar lists Filtering by links and domain reputation, even if the IP is clean

A listing does not always mean you are sending spam: the address may inherit bad reputation from a previous VPS tenant, get listed because of a compromised forum on the same IP, or trigger complaints about transactional mail without a proper unsubscribe path.

What the tool checks

Enter an IP address (e.g. 203.0.113.10) or domain (mail.example.com). The service queries 50–100 major DNSBLs (Spamhaus, Barracuda, SURBL, etc.) sequentially and streams live progress:

  • which lists list or do not list the address;
  • the DNSBL response code and a link to that list’s description;
  • a summary of critical hits that need immediate attention.

What to do if you are listed

  1. Confirm you are checking the right IP — the one actually used for outbound SMTP (not internal NAT or a web server IP if mail goes through a separate relay).
  2. Fix the root cause — close open relays, patch CMS, audit SMTP accounts, add rate limiting and proper bounce handling.
  3. Request delisting following that list’s procedure (Spamhaus, Barracuda, and others each have their own forms and timelines).
  4. Re-run the check after 24–72 hours; DNSBL updates are not instant.

For managers

If “mail is not arriving” and the provider asks you to “check IP reputation,” start with an RBL check. It is faster than debugging SPF/DKIM blindly and shows immediately whether your address is blocked at the gate.

PTR (reverse DNS)

A PTR (pointer) record maps an IP address to a hostname. For mail this is reverse DNS: IP 203.0.113.10 should resolve to a meaningful name like mail.example.com, not an auto-generated ip-10-0-0-1.provider.net.

Why recipients care

Large mailbox providers use PTR as one signal of sender legitimacy:

Check Meaning
PTR exists The IP has an owner with a meaningful DNS name
PTR points to the sending domain The SMTP server is tied to the domain in From:
FCrdNS (forward-confirmed reverse DNS) The PTR hostname, looked up forward (A/AAAA), returns the same IP

FCrdNS is the key point: any random PTR is not enough. A name like random123.hosting.com may exist, but if it does not match the domain in message headers and is not confirmed by forward DNS, filters may lower reputation or reject the connection.

Common problems

  • Generic hosting PTR — vps12345.provider.com instead of mail.yourcompany.com. Common on cheap VPS and shared hosting.
  • HELO/EHLO does not match PTR — the SMTP server introduces itself with one name while PTR points to another.
  • PTR exists but no A record — forward DNS does not confirm reverse; FCrdNS fails.
  • Mail through a third-party ESP — the email provider (SendGrid, Amazon SES, etc.) sets PTR for their outbound IPs, not your website DNS. In that case, check their sending IPs, not your site’s.

What the tool checks

Provide the sending server IP. The tool:

  • finds the PTR record and shows the linked hostname;
  • checks forward DNS (A/AAAA) for that name;
  • evaluates FCrdNS alignment and recommends fixes when they diverge.

PTR is configured by the IP owner (hosting, cloud, ISP) — not in your domain’s DNS panel. If the record is wrong, ask hosting support to set mail.example.com for your outbound IP.

MTA-STS and TLS-RPT

Two related mechanisms that strengthen SMTP transport security between mail servers: one requires encryption, the other reports encryption failures.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS is a domain policy telling receiving servers: “deliver mail to my domain only over encrypted TLS.” Without MTA-STS, SMTP traditionally allows opportunistic TLS — the server tries to encrypt, but may continue in cleartext after a certificate error or downgrade attempt.

The policy is published in two places:

Component Location Contents
_mta-sts DNS record TXT on the domain Version, mode (none / testing / enforce), HTTPS policy file URL
Policy file https://mta-sts.example.com/.well-known/mta-sts.txt MX hosts, validity period (max_age), enforce mode

Mode enforce is strict: if TLS cannot be established correctly, mail must not be delivered in cleartext. Mode testing monitors without blocking; none disables the policy.

TLS-RPT (TLS Reporting)

TLS-RPT is a DNS TXT record at _smtp._tls pointing to an address (usually mailto:) where receiving servers send aggregated reports about TLS problems delivering to your domain: bad certificates, incompatible ciphers, cleartext delivery attempts while MTA-STS is enabled.

Reports help you spot — before user complaints — an expired MX certificate, downgrade attempts, or broken TLS after a hosting migration.

Why configure them

  • Protect mail in transit between MTAs.
  • Meet corporate encryption requirements for communication channels.
  • Detect misconfiguration early after MX moves or certificate renewals.

MTA-STS and TLS-RPT do not replace SPF, DKIM, or DMARC — they address transport security, not sender authenticity.

What the tool checks

For the given domain, the tool verifies:

  • presence and syntax of the _mta-sts DNS TXT record;
  • HTTPS policy file availability and content consistency;
  • presence of the _smtp._tls (TLS-RPT) record and validity of the reporting address;
  • common mistakes: expired max_age, MX mismatch between policy and live DNS, unreachable HTTPS.

BIMI

BIMI (Brand Indicators for Message Identification) is the standard for showing a brand logo next to messages in supporting mail clients (Yahoo, Apple Mail, etc.). Recipients see a familiar icon instead of a generic letter avatar — improving recognition and trust.

What BIMI requires

BIMI builds on domain authentication already in place. Minimum requirements:

Requirement Purpose
DMARC with p=quarantine or p=reject Prove the domain is protected from spoofing — clients will not show a logo without this
BIMI TXT record in DNS (default._bimi) Point to a logo URL in SVG Tiny P/S format
VMC (Verified Mark Certificate) Required by some clients (including Yahoo); proves trademark rights

The logo must be SVG Tiny P/S (a strictly limited SVG profile), usually square, with a transparent or solid background. Raster PNG/JPEG is not used in BIMI.

What BIMI does not do

  • Does not replace DMARC — it depends on it.
  • Does not guarantee inbox placement — it affects display, not spam scoring directly.
  • Does not work everywhere — support varies by client; unsupported clients simply ignore BIMI.

What the tool checks

The tool assesses BIMI readiness for the domain:

  • presence and syntax of the BIMI TXT record (default._bimi);
  • availability of the SVG logo at the specified URL;
  • DMARC status (policy at least quarantine);
  • VMC in the record when required for target clients;
  • common errors: invalid SVG format, unreachable HTTPS, DMARC in p=none mode.

For managers

BIMI is the “cherry on top” after SPF, DKIM, and DMARC. If authentication is not set up yet, start with the SPF/DKIM/DMARC tools; BIMI makes sense once transactional and marketing mail already passes checks reliably.

How tools relate to Mailexam

Task Tools Core product
Test templates and send logic in development — Sandbox + integration examples
Check HTML/CSS across mail clients — Compatibility check
Configure DNS before production mail Tools (this page) —
Automate message checks in CI/CD — REST API · CLI