DNS Health Check for Email: MX, PTR, rDNS — All Free

Email deliverability sits on a stack of DNS records. If any one of them is broken, you will see symptoms that look like a content problem, a list problem, or a reputation problem — when the real cause is a missing PTR or a broken include in SPF. A DNS health check is the first diagnostic anyone should run.

TL;DR

Seven DNS records decide email delivery: MX, SPF, DKIM, DMARC, PTR, FCrDNS (forward-confirmed reverse DNS), and Spamhaus DBL for the domain itself. A free scan queries all seven and returns a single pass/fail with remediation. No signup required here; this part should never have been gated.

The seven DNS records that matter

MX — who receives mail for your domain. Wrong or missing MX and inbound breaks entirely.
SPF — which IPs can send mail as your domain. Missing or broken = spoofable.
DKIM — cryptographic signature selector. No DKIM = no DMARC pass.
DMARC — policy for what happens when SPF/DKIM fail. Required by Gmail/Yahoo for bulk senders since 2024.
PTR / rDNS — reverse DNS of your sending IP. Must exist and must match forward DNS (FCrDNS).
FCrDNS — not a record, a relationship: the PTR resolves to a hostname that resolves back to the sending IP. Gmail and Outlook both hard-require this.
Spamhaus DBL — domain-level blacklist lookup. A listed From-domain is effectively dead for deliverability.

MX — format, priority, null-MX gotcha

MX records tell other servers where to deliver mail to your domain. Format:

yourdomain.com.  IN  MX  10  mail.yourdomain.com.
yourdomain.com.  IN  MX  20  mail2.yourdomain.com.

The number is the priority — lower is preferred. Multiple MX records provide failover. Common mistakes:

Pointing MX at an A record pointing at another A record — MX targets must be hostnames, not IPs, and the hostname must resolve to an A record, not another CNAME chain.
Missing trailing dot in the zone file, turning mail.yourdomain.com into mail.yourdomain.com.yourdomain.com.
Null MX without intent — a record of 0 . declares that the domain does not accept mail. Publish this intentionally on non-sending subdomains, never by accident.

SPF — includes, 10-lookup rule

Covered in depth in the auth check article, but the DNS-health angle is the lookup budget. SPF allows at most 10 DNS lookups during evaluation. Every include:, a, mx, ptr, exists consumes a lookup, and include: is recursive.

A single include:secureserver.net costs six on its own. Add Google Workspace (three) and another ESP and you are already over. The record returns permerror and every message fails SPF silently.

A DNS health check should count lookups and warn before you hit the limit. A health check that only verifies syntax is half a check.

DKIM — selector lookup

DKIM lives at <selector>._domainkey.yourdomain.com. Because selector names are ESP-specific, a DNS health check needs to probe the common selectors for whichever ESPs your domain uses. Absence of the selector means the ESP was configured but DNS was never updated — a surprisingly common failure state.

DMARC — p= tag, pct=

DMARC at _dmarc.yourdomain.com. The health check questions:

Does the record exist? If not, you fail Gmail/Yahoo bulk-sender requirements.
Is p= set to quarantine or reject? A p=none policy is monitor-only and provides no protection.
Is pct= 100 (or absent, which implies 100)? A pct=10 rollout is fine during a migration but should not be the steady state.
Is rua= set and pointing to a mailbox that is actually read?

PTR / rDNS — the FCrDNS requirement

Every sending IP must have a reverse DNS record (PTR), and that record must round-trip. If your sending IP is 203.0.113.5 and its PTR says mail.yourdomain.com, then looking up mail.yourdomain.com must return 203.0.113.5. That round-trip is FCrDNS, and both Gmail and Outlook hard-require it.

Missing PTR is the most common failure mode. You cannot set PTR through your normal DNS provider — it is controlled by whoever owns the IP, usually your hosting provider or ISP. Cloud providers (AWS, GCP, DigitalOcean, Hetzner) all expose PTR editing in their console, but the default value is a generic hostname like ec2-203-0-113-5.compute-1.amazonaws.com, which does not FCrDNS to your real domain.

Fix: set PTR to a hostname you control (e.g. mail.yourdomain.com), then add a matching A record in your domain's DNS. Most deliverability problems on cloud-hosted mail servers trace back to this step being skipped.

Spamhaus DBL — domain-level blacklist

Spamhaus DBL lists domains associated with spam or abuse. Unlike ZEN (IP-based), DBL applies to your domain directly. A hit means the From-domain is toxic, regardless of which IP you send from.

DBL hits are rare for legitimate senders but worth checking every time you launch a new domain or move off one. The lookup is fast and should be in every DNS health check.

Running the free scan

Paste your domain and (optionally) your sending IP into the scan. Output should include:

MX records with priority and target validity.
SPF with parsed includes, lookup count, and final qualifier.
DKIM selectors detected for common ESPs.
DMARC with parsed p, rua, pct, alignment tags.
PTR for the IP, and FCrDNS round-trip result.
Spamhaus DBL lookup for the domain.
Summary verdict: green, amber or red per row.

Inbox Check runs this scan as part of every placement test and as a standalone tool. Takes under 10 seconds. No signup.

Reading the report

The typical failure pattern we see:

SPF: pass (7/10 lookups) — within budget but close. Shave an include if possible.
DKIM: one selector present, one missing — means you rotated ESPs but never cleaned up. Harmless but messy.
DMARC: p=none — classic "published two years ago and forgot". Move to p=quarantine.
PTR: mismatch — PTR points to a generic ISP hostname. FCrDNS fails. Gmail delivery will be unreliable.

Fix the red rows first. Amber can wait. Green is green.

GlockApps comparison for DNS checks

GlockApps includes a DNS audit in its paid report — SPF, DKIM, DMARC, sometimes BIMI. PTR and FCrDNS are covered but less prominently. The output is cleaner than a raw digsession, which is the real value for non-technical users.

Credit: GlockApps will warn you about BIMI and MTA-STS in its audit, which many free tools miss. If you run BIMI or are planning to, that check is genuinely useful. For the core seven records, free tools are equivalent.

GlockApps vs Inbox Check

Inbox placement test — GlockApps: $59/mo (3 free/mo) — Inbox Check: Free, 3/day
Providers — GlockApps: ~15 (no CIS, no EU) — Inbox Check: 20+ (Gmail, Outlook, Yahoo, Mail.ru, Yandex, Rambler, GMX, Orange, ProtonMail…)
Inbox screenshots — GlockApps: No — Inbox Check: Yes
SPF/DKIM/DMARC — GlockApps: In paid report — Inbox Check: Every test, free
SpamAssassin + Rspamd — GlockApps: SpamAssassin (paid) — Inbox Check: Both (free)
DNSBL check — GlockApps: Paid — Inbox Check: Free
MCP for AI agents — GlockApps: No — Inbox Check: Yes
Signup — GlockApps: Required — Inbox Check: Not required

A caveat

A passing DNS health check does not guarantee inbox. It removes the obvious technical blockers. Content, reputation, list hygiene and engagement still decide placement once the authentication hurdle is cleared. Treat this as the necessary first step, not the full picture.

Frequently asked questions

How often should I run a DNS health check?

Once after any DNS change. Once per quarter as a regression check. Once before any major campaign. More frequently than that is overkill — DNS does not drift on its own.

Why does Gmail care about PTR / FCrDNS when SPF already covers sender IPs?

SPF proves the sender is authorised. FCrDNS proves the sender is identifiable (not a compromised box, not a NAT behind a residential router). Gmail uses both signals; SPF alone is insufficient.

My domain has no MX record because we do not receive mail. Is that a problem for sending?

Not directly, but many filters penalise a From-domain that cannot receive mail — the reasoning is that bounces and replies have nowhere to go. Publish a null-MX (0 .) to explicitly declare non-receipt, or set a real MX that discards.

Should I publish MTA-STS and BIMI as part of DNS health?

MTA-STS is increasingly expected for enterprise senders; Gmail prefers TLS-Reporting and MTA-STS. BIMI is optional and requires a VMC certificate for most providers — useful for brand visibility, not required for delivery. Standard seven records are the priority.

Email DNS health check — every record in one scan