{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
        "slug": "separate-authenticated-message-submission-policy-from-smtp-relay-handling",
        "url": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/separate-authenticated-message-submission-policy-from-smtp-relay-handling/"
        },
        "title": "Separate authenticated message submission policy from SMTP relay handling",
        "summary": "Use RFC 6409 — Message Submission for Mail to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "briefing",
            "name": "Briefing"
        },
        "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:16:50+00:00",
        "modified_at": "2026-08-27T12:36:16+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 555,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 6409 — Message Submission for Mail",
        "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 6409 — Message Submission for Mail",
            "url": "https://www.rfc-editor.org/rfc/rfc6409.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>Use this document to resolve one bounded operational decision: Separate authenticated message submission policy from SMTP relay handling. 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/rfc6409.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6409 — Message Submission for Mail</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>Port 587 identifies ESMTP message submission, while port 25 may be used only when a site explicitly distinguishes submission agents from transfer agents. The research record locates this support at <strong>Section 3.1 (Submission Identification)</strong>.</li>\n<li>A submission agent requires authentication by default unless the session is already independently authenticated or authorized. The research record locates this support at <strong>Section 4.3 (Require Authentication)</strong>.</li>\n<li>A submission agent may reject syntactically invalid message data or content that conflicts with the user&#8217;s permissions or site policy. The research record locates this support at <strong>Section 6.3 (Check Message Data)</strong>.</li>\n</ul>\n<p>These statements are the factual basis for this document. Do not extend them into a broader assurance. Review sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling only where the source and recorded environment align.</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. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and the environment&#8217;s recorded constraints.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>For source statement 1 at <strong>Section 3.1 (Submission Identification)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 4.3 (Require Authentication)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 6.3 (Check Message Data)</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. Start with applicability, then compare the observed state with the cited source. 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>An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.</p>\n<h2>Verification and evidence</h2>\n<p>Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations <strong>Section 3.1 (Submission Identification)</strong>; <strong>Section 4.3 (Require Authentication)</strong>; <strong>Section 6.3 (Check Message Data)</strong>. Favor sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, linked to stable identifiers, time, and operator.</p>\n<p>Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today&#8217;s observation is not a continuing guarantee.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc6409.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6409 — Message Submission for Mail</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Use this document to resolve one bounded operational decision: Separate authenticated message submission policy from SMTP relay handling. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6409 — Message Submission for Mail from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nPort 587 identifies ESMTP message submission, while port 25 may be used only when a site explicitly distinguishes submission agents from transfer agents. The research record locates this support at Section 3.1 (Submission Identification).\nA submission agent requires authentication by default unless the session is already independently authenticated or authorized. The research record locates this support at Section 4.3 (Require Authentication).\nA submission agent may reject syntactically invalid message data or content that conflicts with the user’s permissions or site policy. The research record locates this support at Section 6.3 (Check Message Data).\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling only where the source and recorded environment align.\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. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and the environment’s recorded constraints.\nApplicability questions\n\nFor source statement 1 at Section 3.1 (Submission Identification), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.3 (Require Authentication), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 6.3 (Check Message Data), 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. Start with applicability, then compare the observed state with the cited source. 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.\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\nVerification and evidence\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3.1 (Submission Identification); Section 4.3 (Require Authentication); Section 6.3 (Check Message Data). Favor sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, linked to stable identifiers, time, and operator.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 6409 — Message Submission for Mail — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Use this document to resolve one bounded operational decision: Separate authenticated message submission policy from SMTP relay handling. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 6409 — Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- Port 587 identifies ESMTP message submission, while port 25 may be used only when a site explicitly distinguishes submission agents from transfer agents. The research record locates this support at Section 3.1 (Submission Identification).\n\n- A submission agent requires authentication by default unless the session is already independently authenticated or authorized. The research record locates this support at Section 4.3 (Require Authentication).\n\n- A submission agent may reject syntactically invalid message data or content that conflicts with the user’s permissions or site policy. The research record locates this support at Section 6.3 (Check Message Data).\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling only where the source and recorded environment align.\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. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and the environment’s recorded constraints.\n\n## Applicability questions\n\n- For source statement 1 at Section 3.1 (Submission Identification), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 4.3 (Require Authentication), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 6.3 (Check Message Data), 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. Start with applicability, then compare the observed state with the cited source. 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\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\n\n## Verification and evidence\n\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3.1 (Submission Identification); Section 4.3 (Require Authentication); Section 6.3 (Check Message Data). Favor sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, linked to stable identifiers, time, and operator.\n\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\n\n## Official references\n\n- [RFC 6409 — Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409.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/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
                "url": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Separate authenticated message submission policy from SMTP relay handling",
                        "item": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/#article",
                "identifier": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
                "url": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/",
                "headline": "Separate authenticated message submission policy from SMTP relay handling",
                "description": "Use RFC 6409 — Message Submission for Mail to review this narrow operational decision without extending the source beyond its stated scope.",
                "abstract": "Use RFC 6409 — Message Submission for Mail to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Use this document to resolve one bounded operational decision: Separate authenticated message submission policy from SMTP relay handling. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6409 — Message Submission for Mail from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nPort 587 identifies ESMTP message submission, while port 25 may be used only when a site explicitly distinguishes submission agents from transfer agents. The research record locates this support at Section 3.1 (Submission Identification).\nA submission agent requires authentication by default unless the session is already independently authenticated or authorized. The research record locates this support at Section 4.3 (Require Authentication).\nA submission agent may reject syntactically invalid message data or content that conflicts with the user’s permissions or site policy. The research record locates this support at Section 6.3 (Check Message Data).\n\nThese statements are the factual basis for this document. Do not extend them into a broader assurance. Review sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling only where the source and recorded environment align.\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. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and the environment’s recorded constraints.\nApplicability questions\n\nFor source statement 1 at Section 3.1 (Submission Identification), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.3 (Require Authentication), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 6.3 (Check Message Data), 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. Start with applicability, then compare the observed state with the cited source. 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.\nAn implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence.\nVerification and evidence\nEvidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3.1 (Submission Identification); Section 4.3 (Require Authentication); Section 6.3 (Check Message Data). Favor sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, linked to stable identifiers, time, and operator.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 6409 — Message Submission for Mail — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:16:50+00:00",
                "dateModified": "2026-08-27T12:36:16+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/separate-authenticated-message-submission-policy-from-smtp-relay-handling/"
                },
                "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/separate-authenticated-message-submission-policy-from-smtp-relay-handling/#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": "Separate authenticated message submission policy from SMTP relay handling"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Briefing",
                    "Advisory priority"
                ],
                "genre": "Briefing",
                "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": 555,
                "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 6409 — Message Submission for Mail",
                    "url": "https://www.rfc-editor.org/rfc/rfc6409.html"
                }
            }
        ]
    }
}