Email Deliverability Checker – SPF, DKIM & DMARC

A passing DNS audit proves authentication setup—not inbox placement

This checker answers whether a domain has published the records receiving mail systems expect to find. MX identifies where inbound mail should go. SPF authorizes sending infrastructure. DKIM exposes the public key needed to verify a message signature. DMARC connects those checks to the address visible in the From header and publishes a handling policy. MTA-STS and TLS reporting cover transport security between mail servers. These are observable facts in public DNS, so the tool can inspect them without access to a mailbox or a commercial reputation feed.

A perfect configuration score cannot promise delivery to the inbox. Gmail, Outlook, Yahoo, and private gateways also evaluate complaint rates, message engagement, volume changes, content, account history, blocklists, and recipient-specific behavior. Those signals are private or change per message. Use this page to diagnose the authentication foundation; use a controlled test message and its full headers to verify what actually happened during delivery.

Read the MX result before troubleshooting SPF, DKIM, or DMARC

An MX record names the servers that accept mail for the domain. No MX can be valid for a domain that only sends and never receives, but it is a serious fault when people are expected to reply. Multiple MX records are normal: the preference number determines which server is tried first, while higher-numbered servers provide fallback. A host that appears in MX must ultimately resolve to an address; pointing MX directly to an IP address or to an unresolved hostname is invalid.

The reverse-DNS row checks whether the receiving hosts resolve from name to address and back consistently. That is useful infrastructure hygiene, but outbound deliverability depends on the PTR of the actual sending IP, which may be operated by a different provider. If a newsletter platform sends on your behalf, inspect a received message to identify that outbound address rather than assuming the MX hosts send your mail.

SPF must be singular, complete, and kept below its DNS lookup limit

A domain should publish exactly one TXT record beginning with v=spf1. Two SPF records do not combine; receivers normally treat that as a permanent error. The policy should authorize every service that uses the domain in the SMTP envelope—from the company mail server to support desks and marketing platforms—then end with an intentional qualifier such as -all or ~all.

SPF evaluation permits at most ten DNS-triggering mechanisms. Nested include, a, mx, exists, and redirect terms all contribute. A visually short record can therefore exceed the limit through provider includes. This checker confirms publication and detects duplicate records; a complete operational review should also expand the include chain and compare it with a real message's envelope sender.

DKIM cannot be tested reliably without the sender's selector

A DKIM key lives at selector._domainkey.example.com. The selector is deliberately chosen by the sending system and is not listed in a standard directory, so guessing a few popular names can produce a reassuring but incomplete result. Enter the selector shown in your provider settings or copy the value after s= from a delivered message's DKIM-Signature header. Multiple selectors are normal during key rotation or when several providers send for one domain.

A published key only proves that a verifier can retrieve it. It does not prove that outgoing messages are being signed, that the signature survives a mailing list, or that the signing domain aligns with the visible From address. Confirm those details in the receiving server's Authentication-Results header.

DMARC alignment is the bridge between authentication and the From address

DMARC passes when either SPF or DKIM passes and the authenticated domain aligns with the domain users see in From. This is why a third-party sender can show “SPF pass” while DMARC still fails: SPF may authenticate the provider's bounce domain instead of yours. DKIM can rescue alignment when the provider signs with your domain, and SPF can align when a custom return-path is configured.

Begin a new policy with reporting, review legitimate sources, then move deliberately toward enforcement. A policy of p=none gathers data but asks receivers to take no action. p=quarantine requests suspicious treatment; p=reject gives the strongest spoofing protection. Do not jump to enforcement until every legitimate sender is aligned.

Fix failures in an order that avoids blocking legitimate mail

1. Confirm the domain and every MX hostname resolve correctly.
2. Consolidate SPF into one record and inventory every authorized sender.
3. Enable DKIM at each sending provider and test the exact selectors in use.
4. Publish DMARC reporting, study the reports, and correct alignment failures.
5. Advance DMARC toward quarantine or reject only after legitimate traffic passes.
6. Add MTA-STS and TLS reporting after basic mail flow is stable.
7. Send a controlled message and inspect its authentication trail with the Trace Email Headers tool.

Email authentication questions this checker is designed to answer

Why does the DKIM row say “not tested”?

DNS does not provide a dependable way to enumerate selectors. Enter the selector configured by your sender or take it from a message header; an empty selector is reported as unknown instead of being scored as a failure.

Why can mail fail when SPF and DKIM both pass?

DMARC evaluates alignment, not only authentication. Both checks can pass for provider-owned domains while neither aligns with the visible From domain. Reputation, rate limits, content, and recipient rules can also reject a fully authenticated message.

Does this checker submit or retain an email address?

No message or mailbox is required. A one-off check reads public DNS for the submitted domain and selectors. The tool does not send mail, log in to a provider, or buy a private reputation score.