Diagnose email failure when the website works

A working website proves only that a tested web hostname reached a usable web path. Email can use different owner names, MX targets, address records, providers, ports, credentials, sender policies, recipient systems, and queues. Do not edit web A, AAAA, or CNAME records merely because mail fails.

Scope the symptom

Separate:

• inbound mail versus outbound submission;
• all senders or recipients versus one pair;
• permanent reject, temporary defer, timeout, authentication failure, spam placement, or missing message;
• envelope sender, header From, recipient domain, and mailbox;
• exact mail domain queried for MX;
• sending application, SMTP submission host, port, and TLS mode;
• first and last failure times; and
• recent DNS, provider, credential, routing, or policy changes.

The DNS-zone owner controls MX and policy records. The receiving mail provider controls exchangers, mailboxes, filtering, and inbound logs. The sending provider or application controls submission, authentication, envelope data, and outbound logs.

Read-only checks

1. Use the DNS Lookup pathway to query MX at the exact recipient domain, then resolve every exchanger’s A and AAAA records.
2. Distinguish a normal MX RRset, no MX with SMTP’s implicit fallback, and an intentional null MX.
3. Query SPF at the envelope-sender domain, DKIM at the exact selector owner, and DMARC at _dmarc for the header-From organizational path.
4. Review the Email Security Checker pathway for an explicit public-DNS policy check.
5. Inspect sender and receiver logs, queue IDs, enhanced status codes, and the full rejection or defer text.
6. Confirm the application’s configured SMTP hostname, port, encryption mode, username scope, and secret-rotation time without exposing credentials.

SMTP uses MX preference order and defines fallback behavior when no MX RRset exists [2]. A single null MX explicitly states that a domain accepts no mail [4]. The DNS wire format for an MX record contains a preference and exchange domain name [1].

Interpret the observations

Observation	Supported interpretation	Responsible owner
MX is absent, but the domain has web addresses	Senders may try implicit fallback; deliberate mail routing is not established	DNS and mail owners
Null MX is published	The domain declares that it accepts no SMTP mail	DNS-zone owner
MX targets do not resolve	Mail routing fails after the MX lookup	DNS owner of exchanger names
SMTP connection succeeds but recipient is rejected	Mailbox, relay, or recipient policy is implicated	Receiving mail provider
Submission authentication fails	Application credentials, port, or TLS mode is implicated	Sending application owner
SPF, DKIM, or DMARC fails while SMTP accepts	Authentication or alignment is implicated, not basic MX reachability	Sending-domain owner
Provider accepts the message but it never arrives	Queue, filtering, reputation, or downstream delivery needs logs	Mail providers

SPF authorizes sending hosts for an identity; it is not an inbound routing or mailbox protocol [3].

Likely causes

• missing, stale, or unintended MX records after a DNS migration;
• MX targets lacking usable A or AAAA data;
• a null MX published on a mail-receiving domain;
• old and new providers receiving mail during cache overlap;
• missing mailbox, alias, accepted-domain, or routing configuration;
• blocked port, TLS-mode mismatch, or submission authentication failure;
• expired or rotated SMTP credentials;
• incorrect SPF scope, DKIM selector, or DMARC alignment;
• provider rejection, throttling, filtering, spam placement, or queue delay; or
• the application uses a different SMTP hostname than the domain’s inbound MX.

Safe next actions

• Read-only: preserve DNS answers, SMTP codes, queue IDs, logs, message headers, and timestamps before retrying.
• Reversible: correct application submission settings or a reviewed DNS policy record with prior values captured.
• Reversible: after reviewing its data-handling boundary, use the SMTP Tester pathway with an approved test account and mailbox to isolate connection, TLS, authentication, and SMTP responses.
• Availability-impacting: change MX only from an approved mail-routing plan; keep old receivers accepting and forwarding during the cache and queue overlap.

Stop before changing MX if the complete current RRset, provider acceptance state, required mailboxes, old-provider access, or rollback owner is unknown. Never paste production credentials into ClueDNS.

Verification

Verify separately:

1. authoritative and named recursive MX answers;
2. A and AAAA for every exchanger;
3. inbound SMTP acceptance for an approved test recipient;
4. outbound submission, authentication, and provider queue acceptance;
5. SPF evaluation, DKIM signing and verification, and DMARC alignment;
6. final delivery and placement with message headers preserved; and
7. continued website behavior without unrelated DNS changes.

One successful message is a scoped observation, not proof of universal deliverability.

What this evidence does not prove

A working website, valid MX answer, or successful SMTP connection does not by itself prove:

• a recipient mailbox exists;
• every sender is authorized or aligned;
• the message reached the inbox;
• the sending IP has acceptable reputation;
• every cached sender sees the same MX; or
• the web host and mail provider are operated by the same owner.

Next protocol layer

When MX and exchanger addresses are correct, move into SMTP connection, authentication, recipient acceptance, queue, filtering, and delivery logs. If DNS observers disagree, use resolver disagreement diagnosis. Use the Email Security Checker for DNS policy evidence and the SMTP Tester only as an explicit, approved transport test.