RunTheTests
/

Full Email Deliverability Audit

MX, SPF, DKIM and DMARC for a domain — with the one that cannot be checked said so.

MX, SPF with its lookup count, DMARC, and DKIM at the common selectors — queried straight from your browser.

How this lookup works

Four checks, in the order receivers care about them. MX first, because a domain with no mail servers cannot receive bounces or replies. Then SPF, resolved recursively so the ten-lookup limit is counted rather than assumed. Then DKIM — which is the interesting one, because a DKIM record lives at a selector chosen by whoever sends the mail, and selectors cannot be listed from DNS. The common ones are tried and a miss is reported as unknown, not as missing. Then DMARC, where a policy of none is reported as the sensible first step rather than as a pass.

What the results mean

MX
Where mail for the domain is delivered. None at all means bounces and replies have nowhere to go, whatever else is configured.
SPF lookups
Counted recursively. Past ten, receivers return a permanent error and SPF fails for the whole domain.
DKIM unknown
The common selectors were tried and none matched. That means the guesses missed — check a message you have sent for its signature header.
DMARC p=none
Monitoring without enforcement. The right first step and not a destination.

Common problems and fixes

It says DKIM unknown but we definitely have it
Expected if your selector is not one of the common ones. Look at the DKIM-Signature header of a message you have sent — the s= value is the selector.
Everything passes and mail still goes to spam
Authentication is a precondition rather than a guarantee. Placement is decided by reputation systems that are private, and content, volume and complaint rates drive them.
We use a provider for sending — does this still apply?
Yes, and alignment is the thing to check. A provider that sends for you passes SPF for its own domain, which does not align with yours unless you have configured a custom sending domain.

Frequently asked questions

Why can a checker not find my DKIM record?

Because DKIM records are stored under a selector — a name chosen by the sending system — and DNS provides no way to list what selectors exist. A checker can only try the common ones. The reliable way to find yours is to open a message you have sent and read the s= value in its DKIM-Signature header, which names the selector directly.

What do I need for good deliverability?

MX so replies and bounces work, SPF within the lookup limit, DKIM signing with your own domain, and DMARC — starting at none with a reporting address, then moving up once the reports are clean. Beyond that it stops being configuration: reputation is built by sending mail people want, and no record changes that.

Does this check whether my mail is blacklisted?

No — that is a separate check against a sending IP address rather than a domain, and it has its own page. The two are independent: a perfectly configured domain can send from a listed address, and a clean address can send from a domain with no authentication at all.

Put this on your own site

Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.

Embed code
<iframe src="https://runthetests.com/embed/email-deliverability-check/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Full Email Deliverability Audit" loading="lazy"></iframe>

Preview it at https://runthetests.com/embed/email-deliverability-check/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.

More in WebAudit