Root-cause diagnostics

Mail Failure Doctor

Turn a bounce, NDR or SMTP rejection into a precise diagnosis and a prioritized fix plan.

email bounce analyzersmtp error analyzer550 5.7.26 fixemail rejection diagnostic
Diagnose a bounce or rejectionPaste the complete error text. Addresses are not required for most diagnoses.
Provider · stage · permanence · authentication · live DNS

What this analysis does

Paste the failure message exactly as you received it. Mailybox identifies the receiving provider, classifies the SMTP stage and error family, extracts the affected domain, checks public authentication signals, and explains the most likely root cause in plain language.

A bounce message contains more evidence than the three-digit code most people read. The receiving provider, the SMTP stage that failed, the enhanced status code and the free-text diagnostic each narrow the cause differently. Mail Failure Doctor separates those layers so remediation targets the actual failure rather than the most familiar one.

Reviewed against RFC 3463 and current provider references on 29 August 2026

Paste the bounce exactly as it arrived

Forward or copy the complete non-delivery report, including the headers your mail system added and the provider text that follows the status code. Truncating the message to the numeric code removes the part that usually identifies the cause. Two rejections that both begin with 550 5.7.1 can require entirely different fixes depending on the sentence that follows.

The analyzer identifies the receiving provider from the reporting MTA and diagnostic text, classifies the SMTP stage where the transaction stopped, and extracts the affected sender and recipient domains. Those three facts decide whether the problem belongs to DNS, to message authentication, to recipient validity or to provider policy.

  • Include the full diagnostic text, not only the status code.
  • Keep the original recipient and sender addresses in the evidence.
  • Note whether the failure is consistent or intermittent across recipients.

Temporary and permanent failures need different responses

A 4xx response asks the sender to retry later; a 5xx response rejects the current attempt outright. That distinction governs queue behaviour, but it does not identify the cause on its own. A 4xx deferral caused by reputation throttling and a 4xx deferral caused by a destination capacity problem look similar in a log and call for different action.

The enhanced status code defined by RFC 3463 adds a second dimension. The class digit repeats the temporary or permanent verdict, while the subject and detail digits point at addressing, mailbox state, network routing, content or security policy. Reading the enhanced code alongside the provider sentence is what turns a rejection into a diagnosis.

Check authentication before changing anything else

A large share of modern permanent rejections are authentication outcomes rather than address problems. When the diagnostic mentions unauthenticated mail, alignment, SPF, DKIM or DMARC, the fix belongs in DNS and in the sending platform configuration, not in the recipient list. Retrying the same message against the same configuration reproduces the same rejection.

Confirm the sending path before publishing changes. The envelope sender that SPF evaluates is frequently not the address in the visible From field, and the DKIM signing domain is often owned by the sending platform. Establish which identity actually failed, then correct that specific path.

Example: a rejection that names authentication

Evidence supplied
550-5.7.26 Unauthenticated email from example.com is not accepted due to domain policy.

How to read the result
The analysis names the receiving provider, marks the failure as a permanent security-policy rejection, extracts example.com as the affected domain and directs the investigation toward SPF, DKIM and DMARC alignment for the real sending path rather than toward the recipient address.

Known limits

  • Diagnosis is bounded by the evidence in the pasted message; a truncated bounce yields a less specific result.
  • Provider text changes over time and some providers return deliberately generic wording for security reasons.
  • A correct configuration today does not explain a historical rejection if DNS has changed since the message was sent.

Common questions

Why did the same message deliver to one provider and fail at another?

Receivers apply independent policy. A configuration gap that one provider tolerates can be enforced by another, which is why the rejecting provider must be identified before the cause is inferred.

Should a 4xx deferral be retried immediately?

No. A 4xx response asks for delayed retry with backoff. Aggressive retries can worsen reputation and convert a temporary condition into a longer deferral.

Does a passing SPF check mean authentication is not the cause?

Not necessarily. SPF can pass for a platform-owned envelope domain while DMARC still fails because that identity is not aligned with the visible From domain.