Similar tools

An email sent to several people can fail for one address while another remains in a mail server's retry queue. A delivery status notification (DSN) records those outcomes recipient by recipient. The familiar bounce email may contain a readable explanation, a structured delivery report, and a copy of the original message. The structured report connects each delivery condition to the recipient it concerns.

Mail transfer agents (MTAs) are the servers that accept, forward, and deliver email. A report describes an attempt from the reporting MTA's point of view. Forwarding, aliases, and different destination servers can produce different outcomes within the same notification. A prominent error message may concern only some recipients.

Three pieces of evidence explain an individual outcome:

  • Action records what the reporting mail system did, such as abandoning delivery or keeping it pending.
  • Status gives an enhanced status code, such as 5.1.1, describing the broad condition and its category.
  • Diagnostic-Code can add the reporting or remote mail system's explanation, including an SMTP reply. SMTP is the protocol mail servers commonly use to transfer messages.

A temporary condition can last long enough for the sender's mail system to stop trying. That makes a failed action compatible with a temporary status. Conversely, a delayed action says attempts remain pending when the report is issued. The distinction affects whether to check an existing queue or arrange a new submission after correcting the cause.

A permanent condition means resending unchanged is unlikely to help. It does not establish that an address can never work again. An address correction, mailbox cleanup, server repair, or policy change may resolve different kinds of failure. The diagnostic and the administrator's records help identify which change is relevant, without assuming that every rejection has the same cause.

Successful actions also need careful reading. Delivery does not establish that a person read the message. A relay records onward handoff, while alias expansion can lead to further recipient reports. A DSN can also be incomplete or forged, so its statements need corroboration when receipt, identity, or a consequential mailing-list change is disputed.

How to Use This Tool:

Start with the original source of one delivery notification. The initial report is a synthetic example. Load sample restores that example, and Clear empties the source. Both leave the selected format and recipient focus unchanged.

  1. Paste the notification into Delivery report source, choose Browse EML/TXT, or drop one .eml or .txt file onto the text box. Files must be UTF-8 text and no larger than 2 MiB.
    A file-loading error retains the previous source and its results. Check the loading message before treating an existing report as the new file.
  2. Choose Input format. Auto detect selects MIME when the first header block contains Content-Type; otherwise it tries direct DSN fields. Select MIME message for a supported MIME report or DSN fields for the message and recipient field blocks without a MIME wrapper.
  3. Review Recipient outcomes as the report updates automatically. Check the recipient, reported action, enhanced status, and any Review required notes before following the suggested next step.
    If Unable to analyze appears, read the accompanying reason. Obtain the original message source when you have only readable bounce prose or an SMTP log line. Preserve blank lines and MIME boundaries, choose the matching format, and obtain a smaller report if a stated limit is exceeded.
  4. Enter an address fragment in Advanced → Recipient contains when you need to focus on particular recipients. Matching ignores letter case and checks both final and original recipient values. Leave it blank for everyone. If no recipients match, clear the focus to restore the full view.

Interpreting Results:

Limited report means some readable evidence is missing, malformed, duplicated, or inconsistent. The affected recipient records remain available with review notes. A report with no review flags has passed the supported checks only; an unfamiliar detail code can still have no specific explanation.

Use Delivery evidence to compare the recorded fields with the interpretation. The reporting MTA, any remote MTA, diagnostic, attempt date, and log identifier can help a mail administrator locate the relevant attempt. Addressing failures call for checking the reported recipient; delayed network failures call for checking destination availability and the existing queue. A policy category alone does not identify the exact rule or prove an authentication failure.

The Outcome matrix counts recipient blocks by reported action and enhanced-status class. Every visible block contributes exactly once, including blocks with unknown values or review flags. Repeated addresses remain separate blocks. The total is an exact whole-number count, without rounding, and does not measure a mailing campaign's bounce rate or delivery probability.

With a recipient focus, the large recipient count and matrix describe the matching blocks. The need review count still covers the whole report, including hidden recipients. Message-level evidence remains visible while recipient evidence follows the focus. Keep the same focus when comparing counts between views or reports.

Technical Details:

RFC 3464 defines a delivery-status body as one block of message fields followed by separate recipient blocks. Blank lines mark those boundaries. Reporting-MTA is required for the message; each recipient requires Final-Recipient, Action, and Status. A diagnostic is optional. Its absence alone does not trigger a review note.

Rule Core

Interpretation proceeds from the report's structure to each recipient's evidence. An error in one recipient must not supply the meaning for another.

  1. Identify a supported delivery-status body, either directly or inside the permitted MIME report structure. Human-readable explanations and returned original content do not supply recipient outcomes.
  2. Read the message block and each recipient block independently. Field names and recognized action values are matched without regard to case. Continuation lines beginning with a space or tab are unfolded into the preceding field.
  3. Check required fields and supported field syntax. Preserve recorded fields, including duplicates and extensions, while using the first occurrence of a recognized field for interpretation.
  4. Read the action and enhanced status separately, then compare them and any recognized SMTP diagnostic class. Missing or conflicting evidence requests review instead of being replaced with a guessed outcome.

A typed field combines a type and value separated by a semicolon. For example, rfc822; user@example.org identifies an Internet-style recipient address, while dns; mx.example.net identifies a mail-system name. These checks establish only the supported structure. They do not establish that the address exists or that the named server produced the report.

Final-Recipient identifies the address covered by that recipient block, as known to the reporting MTA. Original-Recipient, when supplied, records the original envelope recipient. Forwarding or address rewriting can make the two differ. These delivery-envelope addresses need not match the visible To header.

Enhanced status anatomy

The three numbers in class.subject.detail have different jobs. Class 2 is shown as Success, 4 as Temporary condition, and 5 as Permanent condition. The subject locates the broad problem area; the detail narrows it only when that particular code is understood.

Status pattern Subject category
x.0.xOther or undefined
x.1.xAddressing
x.2.xMailbox
x.3.xMail system
x.4.xNetwork or routing
x.5.xDelivery protocol
x.6.xMessage content or media
x.7.xSecurity or policy

Here, x marks a position that varies. In 5.1.1, the first number reports a permanent condition, the second identifies addressing, and the complete code describes a reported invalid destination mailbox address. The other specific explanations supplied are mailbox full for 4.2.2 and 5.2.2, a destination host that did not answer for 4.4.1, and a policy or authorization refusal for 5.7.1.

Recognition of a prefix does not establish the meaning of an unfamiliar detail. For example, 5.7.999 retains Permanent condition and Security or policy without acquiring a specific policy explanation. 5.99.999 retains the class and shows Unrecognized subject. Neither unfamiliar value alone produces a review flag, and neither example asserts that the code is registered.

Accepted status syntax uses class 2, 4, or 5, with one to three digits each for subject and detail. Leading zeros are rejected except for the number 0 itself. Whitespace inside the code is unsupported; balanced parenthesized comments may follow it. Thus 5.1.1 (address issue) retains the meaning of 5.1.1, while 5.01.1 produces an Unknown class and a review note.

Action and status checks

The following combinations pass this reader's action/status consistency check. A separate field problem can still require review. These checks do not establish complete RFC conformance.

Action Reported meaning Class accepted by this check
failedDelivery attempts have stopped.4 or 5
delayedDelivery remains pending.4
deliveredDelivery is reported, without proving the message was read.2
relayedMail was handed onward; final delivery is unconfirmed.2
expandedAn alias was expanded; further recipient reports may follow.2

Pairs such as failed with 2.0.0, delayed with 5.1.1, or delivered with 4.4.1 request review. Both recorded values remain available, and the matrix still counts their reported combination. An unrecognized action is counted under unknown; an absent or unusable status is counted as Unknown.

SMTP diagnostics are another check on the evidence. In smtp; 550 5.1.1 Recipient does not exist, the three-digit SMTP reply and the dotted enhanced code are different kinds of code. A recognized leading SMTP reply in the 2xx, 4xx, or 5xx class is compared with the separate Status field. A class mismatch requests review without overriding either recorded field.

Will-Retry-Until belongs to a delayed action and describes when the reporting MTA expects to abandon attempts. Its presence with another action requests review. Dates remain recorded text: the analyzer does not validate every date, calculate remaining retry time, or determine whether the queue is still active now.

MIME structure and encodings

Multipurpose Internet Mail Extensions (MIME) describe the separate parts of an email. For a supported multipart/report, report-type=delivery-status identifies the report kind. There must be two or three immediate parts, with the machine-readable message/delivery-status body second. This reader accepts text or multipart/alternative first, and recognized returned-message or returned-header types third.

A directly MIME-typed message/delivery-status body is also accepted, and a delivery report may sit inside supported multipart wrappers. A loose delivery-status attachment in an unrelated multipart container is not treated as a report. Multipart boundaries must be valid, no longer than 70 characters, and properly closed. Multiple reports and ambiguous MIME headers prevent analysis. Returned original bodies are not traversed for DSNs, attachments are not extracted, and HTML is not rendered.

The delivery-status body supports 7bit, 8bit, binary, Base64, and quoted-printable. Only UTF-8 and US-ASCII delivery-status text is supported, with invalid decoding rejected. RFC 3464 specifies 7bit for classic DSNs; acceptance of the other encodings is compatibility handling, not a standards-compliance verdict. Base64 and quoted-printable multipart containers remain unsupported.

Human bounce prose, isolated SMTP replies or logs, Outlook MSG files, and RFC 6533 message/global-delivery-status reports are outside this reader's scope. UTF-8 source acceptance does not add internationalized DSN support. MIME Content-Type comments are also unsupported, so a message accepted by a general mail reader may still fall outside these parsing rules.

Evidence and resource limits

Evidence preserves field order and recorded values after line-ending normalization, trimming, and unfolding. It is not a byte-for-byte archive of the source. Duplicated standard fields covered by the checks are flagged and retained; unfamiliar extension fields remain uninterpreted evidence. A message-level problem, such as a missing Reporting-MTA, affects every recipient's review status.

A recognizable DSN with missing required values can produce a limited report. Unreadable field syntax, unsupported encoding, malformed MIME, or exceeded resource limits prevent a report rather than silently discarding the affected portion. The following bounds are product limits, not RFC maxima.

Item Maximum How the limit applies
Source and decoded DSN2,097,152 bytes each2 MiB, measured as UTF-8 bytes for pasted text; local files also have this byte limit.
Recipient blocks100One message block plus up to 100 recipient blocks.
MIME parts64Bounds apply while splitting and traversing MIME containers.
MIME nesting4 levels below the outer entityThe delivery-status part must remain within this depth.
Fields in a block256Applies to parsed MIME header blocks and DSN field blocks.
Field line length8,192 charactersApplies to each physical line before unfolding.
Recipient focus254 charactersSurrounding whitespace is trimmed before matching.

Privacy Notes:

Analysis runs in your browser. The report source and recipient focus stay in the current tab, are not submitted for analysis, and are not saved by the tool or added to shareable URLs. Only the input-format choice is shareable. Ordinary page and chart resources still load over the network. The analyzer does not send mail, probe SMTP or DNS, authenticate a sender, or verify mailbox existence.

  • Exports can contain personal addresses, mail-server names, diagnostics, and extension fields. Inspect them before sharing.
  • Recipient tables, their CSV and DOCX exports, and the matrix follow the focus. JSON retains all recipient records and message fields, including recipients hidden from view, and includes the focus text. It excludes the original input source and returned message bodies. Filtering is not redaction.
  • CSV and row-copy text receive spreadsheet-formula safeguards. Values starting with =, +, @, or -, including after initial spaces, tabs, or line breaks, receive an apostrophe prefix. Values beginning with a tab or line break receive the same treatment. The recorded fields and JSON keep their unprefixed values; exported text is not a lossless replacement for those fields.

Worked Examples:

One recipient fails while another waits

Choose Auto detect, leave Recipient contains blank, and select Load sample. The MIME report produces 2 recipients and 0 needing review. missing@example.org has action failed, status 5.1.1, and a 550 diagnostic. waiting@example.org has action delayed, status 4.4.1, and a 451 diagnostic. The matrix therefore contains 1 failed recipient under Permanent condition and 1 delayed recipient under Temporary condition. The first outcome calls for checking the address before resending; the second calls for checking the destination and existing retry queue.

Attempts stopped after a temporary condition

To inspect an abandoned attempt directly, select DSN fields, clear the recipient focus, and paste the complete field blocks below.

Reporting-MTA: dns; mx.example.net

Final-Recipient: rfc822; user@example.org
Action: failed
Status: 4.4.1
Diagnostic-Code: smtp; 451 Destination did not respond

The result is 1 recipient and 0 needing review. Its action means attempts stopped, while its class is Temporary condition and its category is Network or routing. The matrix places 1 recipient at failed and Temporary condition. The temporary status does not promise another automatic attempt; the administrator needs to check the destination problem before arranging a new submission.

References: