送達通知通常包含多個伺服器名稱、日期和位址。發送報告的系統不一定是拒絕訊息的系統。在根據報告的主題行進行DNS或郵箱變更之前，解析其傳遞狀態欄位並關聯原始嘗試。
識別報告和遠端系統
RFC 3464定義了傳遞狀態主體格式。報告-MTA 標識產生通知的系統。遠端 MTA（如果存在）可識別與報告的傳送嘗試關聯的遠端系統。診斷代碼可以保留遠端協定回應。人類可讀的解釋是有幫助的，但它的散文不應取代結構化欄位。 RFC 3464第 2.2 和 2.3 節.
記錄系統標識和報告時間。從應用程式接受郵件的中繼稍後可能會收到來自收件者伺服器的拒絕並自行建立 DSN。將中繼名稱視為拒絕目標可能會將調查發送給錯誤的管理員並掩蓋原始SMTP回應。
獨立讀取每個接收者區塊
最終收件者標識應用傳遞狀態區塊的收件者。原始接收者（當存在時）可以保留較早的接收者身分。操作描述了交付操作，例如失敗或延遲。狀態帶有增強的狀態代碼。可選的 Diagnostic-Code、Last-Attempt-Date 和 Will-Retry-Until 可以提供有用的附加上下文，但並非每個報告都會提供它們。
當診斷代碼存在時， RFC 3464第 2.3.6 節將提供的遠端 MTA 解釋為其發行者；如果沒有 Remote-MTA，診斷將歸因於 Reporting-MTA。該字段規則並不能證明更早的遠端嘗試從未發生過。使用可信任日誌證實完整的歷史記錄。
DSN 可以包含多個具有不同操作和狀態值的接收者區塊。不要對原始「收件者」或「副本」標頭中的每個人都套用一次失敗。同樣，缺少可選字段並不能證明相應的事件從未發生過。將缺勤保留為未知，並使用隊列或追蹤證據來填補空白。
閱讀假設到期通知
想像一下， relay.example接受一則訊息，然後在嘗試傳遞時從mx.example收到 452 4.2.2 Mailbox full。在其配置的傳遞生命週期到期後，中繼會產生 DSN。教學摘錄可以識別報告-MTA：dns； relay.example ，遠端 MTA：dns； mx.example ，最終收件人：rfc822； recipient@example.test ，操作：失敗，狀態：5.4.7 和診斷代碼：smtp；452 4.2.2 郵箱已滿。
這是發明的現場演練，而不是完整的MIME報告或執行的郵件交換。最終狀態描述了交付時間到期，而保留的診斷描述了最後一次容量拒絕。這些字段回答不同的問題。這不是通用的首選映射： RFC 3463第 3.5 節表示在可能的情況下返回實際的交付問題代碼而不是過期代碼。保留最具體的支持原因。 RFC 3464也允許 Action: failed with a 4.xx Status after the reporting MTA 已放棄嘗試；暫時原因並不表示原始原因仍處於排隊狀態。
對於您自己的報告，請分別關聯原始提交、嘗試、到期決定和報告到達。請勿假設說明性名稱、時間或欄位與提供者相符。保留缺少的可選字段而不用猜測值填充它們。
行動前關聯
將通知與原始信封收件者、提交時間和可用佇列識別碼進行比對。 Original-Envelope-Id 可以在存在時幫助關聯；返回的 Message-ID 是另一個線索，而不是對通知本身的充分驗證。報告可能是欺騙性的或偽造造成的 回程路徑 位址，因此意外退回郵件不得自動觸發寄件者配置變更。
使用受信任的發送日誌來確定組織確實提交了訊息。避免僅因為郵件類似於退回郵件而開啟傳回的附件或遵循憑證提示。如果不存在匹配的提交，請調查該報告是否可能是未經請求的或偽造的，而不是將其視為帳戶洩露的證據。
將校正分配給右側圖層
尋址狀態將發送至郵箱或聯絡人所有者。路線或連接問題需要傳輸證據。身份驗證診斷需要實際的相關訊息身份和接收評估。保留完整的診斷訊息，以便專家可以區分類似的故障。
經批准的更正後，將任何新嘗試與其自己的佇列和訊息標識符相關聯。不要用後來的結果覆蓋歷史報告。將原始故障、維修和更換交付視為相關但不同的事件。當成功重新發送後延遲的報告到達時，這可以保留誠實的時間表。
準備特定於收件人的升級
- 關聯：使用收件人、時間和佇列證據將報告與合法提交的內容進行配對。
- 頒發者：將報告 MTA 與遠端 MTA 和診斷頒發者分開保留。
- 結果：保留操作、狀態和原始診斷代碼，而不強制它們匹配。
- 擁有者：指派實際的失敗層，而不僅僅是退回的發送者。
- 隱私權：僅提供必要的報告欄位；不轉送無關的回傳訊息內容。