Start with what a DNS check can answer
This email deliverability test is a DNS preflight. Enter a From domain to collect receiving MX, top-level SPF, the exact _dmarc TXT name and five common DKIM selectors. The tool keeps observations separate rather than turning record presence into a score. It sends no mail, opens no SMTP connection and cannot know what happened to your campaign or support reply.
A public default domain demonstrates the report without proving anything about your own domain. Change the input before acting on it. Use the downloadable report to preserve resolver statuses and the time of the check; a later DNS change can make a screenshot of an old result misleading.
What each observation means
| Observation | Question it helps answer | Evidence still needed |
|---|---|---|
| Receiving MX | Which receiving targets are advertised? | Address routing, null or implicit MX handling and actual SMTP availability |
| Top-level SPF | Is an SPF-like formula visible at this name? | Expanded includes, evaluation limits, sending IP and envelope identity |
| Exact-name DMARC | What record do the resolvers return here? | Policy discovery, aligned message results and receiver handling |
| Common DKIM selectors | Is key-like TXT visible at one of five names? | The actual selector, key validity and cryptographic signature verification |
A published key can be unused. A published SPF formula can authorise a different domain from the one recipients see. A DMARC report destination can be unreachable. These are reasons to continue an investigation, not reasons to label the domain healthy after four green cells.
Empty, unknown and conflicting evidence
An empty observation means usable DNS responses did not contain the requested record. It describes the names and resolvers tried. Unknown means the request failed or the responses were insufficient to support an absence claim. Partial positive evidence preserves the record that was seen and the resolver failure beside it. Conflicting observations stay visible rather than being collapsed into a single selected policy.
For DMARC, a negative answer at the exact name does not rule out an applicable parent policy. For DKIM, unsuccessful probes at default, google, selector1, s1 and k1 do not rule out a different selector. For receiving mail, no MX answer is not automatically a total failure: SMTP routing rules include an implicit-MX case. This tool does not evaluate that routing path.
A practical next step for a real failure
Suppose your helpdesk mail is refused but personal replies work. Save one delivery error and one successfully received helpdesk message if available. Compare the sending system, From domain and Authentication-Results. Use its real signing selector for a targeted DKIM check and inspect the DMARC record at the relevant domain. Changing MX merely because the combined report lacks a receiving target would address a different question.
Suppose a marketing message passes authentication and still lands in spam. Keep that result and investigate complaints, consent, volume, content and provider feedback. Repeatedly switching p between monitoring and rejection cannot demonstrate an improvement in those measurements. Gmail’s sender guidelines provide a concrete provider reference; verify the requirements that apply to your sending volume and recipient systems.
Keep the investigation reproducible
Record the affected provider, sending platform, approximate time, error text and domain identities. Do not paste message bodies, recipient lists or credentials into a public diagnostic tool. Check the SPF formula with its recursive evaluation limit in mind; this report does not expand includes. Review the DMARC rollout guide before tightening a live policy, and use why legitimate mail goes to spam for the parts of delivery that cannot be inferred from DNS alone.