{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/emit-machine-readable-message-and-recipient-delivery-status-fields/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
        "slug": "emit-machine-readable-message-and-recipient-delivery-status-fields",
        "url": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/emit-machine-readable-message-and-recipient-delivery-status-fields/"
        },
        "title": "Emit machine-readable message and recipient delivery-status fields",
        "summary": "Use RFC 3464 — An Extensible Message Format for Delivery Status Notifications to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "explainer",
            "name": "Explainer"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-27T12:17:03+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 594,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 3464 — An Extensible Message Format for Delivery Status Notifications",
        "dse_recommendation": "Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards.",
        "primary_source": {
            "name": "RFC 3464 — An Extensible Message Format for Delivery Status Notifications",
            "url": "https://www.rfc-editor.org/rfc/rfc3464.html",
            "published_on": null,
            "authority": "www.rfc-editor.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Frame this document as a source-led configuration and assurance check: Emit machine-readable message and recipient delivery-status fields. Only the official source and traced locations below supply facts. Confirm applicability before acting.</p>\n<h2>Source fact:</h2>\n<p>The official <a href=\"https://www.rfc-editor.org/rfc/rfc3464.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 3464 — An Extensible Message Format for Delivery Status Notifications</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>A delivery-status notification is a multipart/report with report-type delivery-status, a human-readable part, and a message/delivery-status part; returned original content is optional. The research record locates this support at <strong>Section 2 (Format of a Delivery Status Notification)</strong>.</li>\n<li>The message/delivery-status body places its per-message fields first, followed by one or more blank-line-separated groups of per-recipient fields. The research record locates this support at <strong>Section 2.1 (The message/delivery-status content-type)</strong>.</li>\n<li>Each recipient group identifies the final recipient and records the delivery action and status, with optional diagnostic and retry fields. The research record locates this support at <strong>Section 2.3 (Per-Recipient DSN fields)</strong>.</li>\n</ul>\n<p>Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source&#8217;s stated conditions.</p>\n<h2>What the source does not establish</h2>\n<p>This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>For source statement 1 at <strong>Section 2 (Format of a Delivery Status Notification)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 2.1 (The message/delivery-status content-type)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 2.3 (Per-Recipient DSN fields)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?</li>\n<li>Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?</li>\n<li>Who owns the decision, and which observation requires stopping, escalation, or rollback?</li>\n</ul>\n<h2>DSE recommendation:</h2>\n<p>DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.</p>\n<p>Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels.</p>\n<h2>Verification and evidence</h2>\n<p>Keep the source locations <strong>Section 2 (Format of a Delivery Status Notification)</strong>; <strong>Section 2.1 (The message/delivery-status content-type)</strong>; <strong>Section 2.3 (Per-Recipient DSN fields)</strong> adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.</p>\n<p>Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc3464.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 3464 — An Extensible Message Format for Delivery Status Notifications</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Frame this document as a source-led configuration and assurance check: Emit machine-readable message and recipient delivery-status fields. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 3464 — An Extensible Message Format for Delivery Status Notifications from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA delivery-status notification is a multipart/report with report-type delivery-status, a human-readable part, and a message/delivery-status part; returned original content is optional. The research record locates this support at Section 2 (Format of a Delivery Status Notification).\nThe message/delivery-status body places its per-message fields first, followed by one or more blank-line-separated groups of per-recipient fields. The research record locates this support at Section 2.1 (The message/delivery-status content-type).\nEach recipient group identifies the final recipient and records the delivery action and status, with optional diagnostic and retry fields. The research record locates this support at Section 2.3 (Per-Recipient DSN fields).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Section 2 (Format of a Delivery Status Notification), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 2.1 (The message/delivery-status content-type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 2.3 (Per-Recipient DSN fields), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nDo not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels.\nVerification and evidence\nKeep the source locations Section 2 (Format of a Delivery Status Notification); Section 2.1 (The message/delivery-status content-type); Section 2.3 (Per-Recipient DSN fields) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nRetain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.\nOfficial references\n\nRFC 3464 — An Extensible Message Format for Delivery Status Notifications — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Frame this document as a source-led configuration and assurance check: Emit machine-readable message and recipient delivery-status fields. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 3464 — An Extensible Message Format for Delivery Status Notifications](https://www.rfc-editor.org/rfc/rfc3464.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- A delivery-status notification is a multipart/report with report-type delivery-status, a human-readable part, and a message/delivery-status part; returned original content is optional. The research record locates this support at Section 2 (Format of a Delivery Status Notification).\n\n- The message/delivery-status body places its per-message fields first, followed by one or more blank-line-separated groups of per-recipient fields. The research record locates this support at Section 2.1 (The message/delivery-status content-type).\n\n- Each recipient group identifies the final recipient and records the delivery action and status, with optional diagnostic and retry fields. The research record locates this support at Section 2.3 (Per-Recipient DSN fields).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\n\n## What the source does not establish\n\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\n\n## Applicability questions\n\n- For source statement 1 at Section 2 (Format of a Delivery Status Notification), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 2.1 (The message/delivery-status content-type), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 2.3 (Per-Recipient DSN fields), which observable configuration, record, or test can confirm applicability here?\n\n- Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\n\n- Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\n\n- Who owns the decision, and which observation requires stopping, escalation, or rollback?\n\n## DSE recommendation:\n\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\n\nDo not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels.\n\n## Verification and evidence\n\nKeep the source locations Section 2 (Format of a Delivery Status Notification); Section 2.1 (The message/delivery-status content-type); Section 2.3 (Per-Recipient DSN fields) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\n\nRetain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.\n\n## Official references\n\n- [RFC 3464 — An Extensible Message Format for Delivery Status Notifications](https://www.rfc-editor.org/rfc/rfc3464.html) — RFC Editor / Internet Engineering Task Force"
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
                "url": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Emit machine-readable message and recipient delivery-status fields",
                        "item": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/#article",
                "identifier": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
                "url": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/",
                "headline": "Emit machine-readable message and recipient delivery-status fields",
                "description": "Use RFC 3464 — An Extensible Message Format for Delivery Status Notifications to review this narrow operational decision without extending the source…",
                "abstract": "Use RFC 3464 — An Extensible Message Format for Delivery Status Notifications to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Frame this document as a source-led configuration and assurance check: Emit machine-readable message and recipient delivery-status fields. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 3464 — An Extensible Message Format for Delivery Status Notifications from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA delivery-status notification is a multipart/report with report-type delivery-status, a human-readable part, and a message/delivery-status part; returned original content is optional. The research record locates this support at Section 2 (Format of a Delivery Status Notification).\nThe message/delivery-status body places its per-message fields first, followed by one or more blank-line-separated groups of per-recipient fields. The research record locates this support at Section 2.1 (The message/delivery-status content-type).\nEach recipient group identifies the final recipient and records the delivery action and status, with optional diagnostic and retry fields. The research record locates this support at Section 2.3 (Per-Recipient DSN fields).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Section 2 (Format of a Delivery Status Notification), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 2.1 (The message/delivery-status content-type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 2.3 (Per-Recipient DSN fields), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nDo not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels.\nVerification and evidence\nKeep the source locations Section 2 (Format of a Delivery Status Notification); Section 2.1 (The message/delivery-status content-type); Section 2.3 (Per-Recipient DSN fields) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nRetain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.\nOfficial references\n\nRFC 3464 — An Extensible Message Format for Delivery Status Notifications — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:17:03+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Emit machine-readable message and recipient delivery-status fields"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Explainer",
                    "Advisory priority"
                ],
                "genre": "Explainer",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 594,
                "timeRequired": "PT3M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "RFC 3464 — An Extensible Message Format for Delivery Status Notifications",
                    "url": "https://www.rfc-editor.org/rfc/rfc3464.html"
                }
            }
        ]
    }
}