A delivery notification often contains several server names, dates and addresses. The system sending the report is not necessarily the system that rejected the message. Parse its delivery-status fields and correlate the original attempt before making a DNS or mailbox change based on the report's subject line.
Identify the reporting and remote systems
RFC 3464 defines the delivery-status body format. Reporting-MTA identifies the system producing the notification. Remote-MTA, when present, identifies a remote system associated with the reported delivery attempt. Diagnostic-Code can preserve the remote protocol response. The human-readable explanation is helpful, but its prose should not replace the structured fields. RFC 3464 sections 2.2 and 2.3.
Record both system identities and the reported times. A relay that accepted mail from the application might later receive a refusal from a recipient server and construct the DSN itself. Treating the relay's name as the rejecting destination can send an investigation to the wrong administrator and obscure the original SMTP response.
Read each recipient block independently
Final-Recipient identifies the recipient to which a delivery-status block applies. Original-Recipient, when present, can preserve an earlier recipient identity. Action describes the delivery action, such as failed or delayed. Status carries an enhanced status code. Optional Diagnostic-Code, Last-Attempt-Date and Will-Retry-Until can provide useful additional context, but not every report supplies them.
When Diagnostic-Code is present, RFC 3464 section 2.3.6 interprets a supplied Remote-MTA as its issuer; without Remote-MTA, the diagnostic is attributed to Reporting-MTA. That field rule does not prove that no earlier remote attempt ever occurred. Corroborate the complete history with trusted logs.
A DSN can include multiple recipient blocks with different actions and status values. Do not apply one failure to everyone in the original To or Cc header. Similarly, a missing optional field is not proof that the corresponding event never occurred. Preserve absence as unknown and use queue or trace evidence to fill the gap.
Read a hypothetical expiry notification
Imagine relay.example accepts a message, then receives 452 4.2.2 Mailbox full from mx.example when attempting delivery. After its configured delivery lifetime expires, the relay produces a DSN. A teaching excerpt could identify Reporting-MTA: dns; relay.example, Remote-MTA: dns; mx.example, Final-Recipient: rfc822; recipient@example.test, Action: failed, Status: 5.4.7 and Diagnostic-Code: smtp; 452 4.2.2 Mailbox full.
This is an invented field walkthrough, not a complete MIME report or an executed mail exchange. The final status describes delivery-time expiry, while the preserved diagnostic describes the last capacity refusal. The fields answer different questions. This is not a universal preferred mapping: RFC 3463 section 3.5 says to return the actual delivery-problem code instead of expiry when possible. Preserve the most specific supported cause. RFC 3464 also permits Action: failed with a 4.x.x Status after the reporting MTA has abandoned attempts; a transient cause does not mean the original remains queued.
For your own report, correlate the original submission, attempts, expiry decision and report arrival separately. Do not assume the illustrative names, timing or fields match a provider. Preserve missing optional fields without filling them with guessed values.
Correlate before acting
Match the notification to the original envelope recipient, submission time and available queue identifiers. Original-Envelope-Id may assist correlation when present; a returned Message-ID is another clue rather than sufficient authentication of the notification itself. Reports can be spoofed or caused by forged return-path addresses, so an unexpected bounce must not automatically trigger a sender-configuration change.
Use trusted sending logs to establish that the organization actually submitted the message. Avoid opening returned attachments or following credential prompts merely because the message resembles a bounce. If no matching submission exists, investigate the report as potentially unsolicited or forged instead of treating it as proof of account compromise.
Assign the correction to the right layer
An addressing status goes to the mailbox or contact owner. A route or connection problem needs transport evidence. An authentication diagnostic requires the actual relevant message identities and receiving evaluation. Retain the complete diagnostic so the specialist can distinguish similar-looking failures.
After an approved correction, correlate any new attempt with its own queue and message identifiers. Do not overwrite the historical report with the later outcome. Close the original failure, the repair and the replacement delivery as related but distinct events. This preserves an honest timeline when a delayed report arrives after a successful resend.
Prepare a recipient-specific escalation
- Correlation: match the report to a legitimate submission using recipient, time and queue evidence.
- Issuer: retain Reporting-MTA separately from Remote-MTA and the diagnostic issuer.
- Outcome: preserve Action, Status and original Diagnostic-Code without forcing them to match.
- Owner: assign the actual failure layer, not simply the sender of the bounce.
- Privacy: provide only necessary report fields; do not forward unrelated returned message content.