{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
        "slug": "enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy",
        "url": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/"
        },
        "title": "Enforce MTA-STS only after retrieving and authenticating domain policy",
        "summary": "Use RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "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:02+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 607,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)",
        "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 8461 — SMTP MTA Strict Transport Security (MTA-STS)",
            "url": "https://www.rfc-editor.org/rfc/rfc8461.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 connect an official requirement or behavior to observable evidence: Enforce MTA-STS only after retrieving and authenticating domain policy. 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/rfc8461.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>A sender discovers MTA-STS through the policy domain&#8217;s _mta-sts TXT record, whose id value distinguishes policy revisions. The research record locates this support at <strong>Section 3.1 (MTA-STS TXT Records)</strong>.</li>\n<li>The sender fetches the policy from the fixed HTTPS path on mta-sts.&lt;policy-domain&gt;; only a 200 response with a certificate valid for that host yields a live policy. The research record locates this support at <strong>Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching)</strong>.</li>\n<li>In enforce mode, the sender requires STARTTLS and valid MX identity for each candidate, while a still-valid cached policy remains applicable when live retrieval fails. The research record locates this support at <strong>Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow)</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 3.1 (MTA-STS TXT Records)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow)</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>For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.</p>\n<h2>Verification and evidence</h2>\n<p>Keep the source locations <strong>Section 3.1 (MTA-STS TXT Records)</strong>; <strong>Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching)</strong>; <strong>Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow)</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>Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc8461.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Use this document to connect an official requirement or behavior to observable evidence: Enforce MTA-STS only after retrieving and authenticating domain policy. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA sender discovers MTA-STS through the policy domain’s _mta-sts TXT record, whose id value distinguishes policy revisions. The research record locates this support at Section 3.1 (MTA-STS TXT Records).\nThe sender fetches the policy from the fixed HTTPS path on mta-sts.<policy-domain>; only a 200 response with a certificate valid for that host yields a live policy. The research record locates this support at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching).\nIn enforce mode, the sender requires STARTTLS and valid MX identity for each candidate, while a still-valid cached policy remains applicable when live retrieval fails. The research record locates this support at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow).\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 3.1 (MTA-STS TXT Records), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow), 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.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nKeep the source locations Section 3.1 (MTA-STS TXT Records); Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching); Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow) 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.\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\nOfficial references\n\nRFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Use this document to connect an official requirement or behavior to observable evidence: Enforce MTA-STS only after retrieving and authenticating domain policy. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- A sender discovers MTA-STS through the policy domain’s _mta-sts TXT record, whose id value distinguishes policy revisions. The research record locates this support at Section 3.1 (MTA-STS TXT Records).\n\n- The sender fetches the policy from the fixed HTTPS path on mta-sts.<policy-domain>; only a 200 response with a certificate valid for that host yields a live policy. The research record locates this support at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching).\n\n- In enforce mode, the sender requires STARTTLS and valid MX identity for each candidate, while a still-valid cached policy remains applicable when live retrieval fails. The research record locates this support at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow).\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 3.1 (MTA-STS TXT Records), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow), 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\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\n\n## Verification and evidence\n\nKeep the source locations Section 3.1 (MTA-STS TXT Records); Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching); Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow) 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\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\n\n## Official references\n\n- [RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.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/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
                "url": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Enforce MTA-STS only after retrieving and authenticating domain policy",
                        "item": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/#article",
                "identifier": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
                "url": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/",
                "headline": "Enforce MTA-STS only after retrieving and authenticating domain policy",
                "description": "Use RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) to review this narrow operational decision without extending the source beyond its stated…",
                "abstract": "Use RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Use this document to connect an official requirement or behavior to observable evidence: Enforce MTA-STS only after retrieving and authenticating domain policy. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA sender discovers MTA-STS through the policy domain’s _mta-sts TXT record, whose id value distinguishes policy revisions. The research record locates this support at Section 3.1 (MTA-STS TXT Records).\nThe sender fetches the policy from the fixed HTTPS path on mta-sts.<policy-domain>; only a 200 response with a certificate valid for that host yields a live policy. The research record locates this support at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching).\nIn enforce mode, the sender requires STARTTLS and valid MX identity for each candidate, while a still-valid cached policy remains applicable when live retrieval fails. The research record locates this support at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow).\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 3.1 (MTA-STS TXT Records), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow), 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.\nFor an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence.\nVerification and evidence\nKeep the source locations Section 3.1 (MTA-STS TXT Records); Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching); Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow) 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.\nPreserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent.\nOfficial references\n\nRFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:17:02+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/"
                },
                "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/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/#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": "Enforce MTA-STS only after retrieving and authenticating domain policy"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Advisory priority"
                ],
                "genre": "Guide",
                "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": 607,
                "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 8461 — SMTP MTA Strict Transport Security (MTA-STS)",
                    "url": "https://www.rfc-editor.org/rfc/rfc8461.html"
                }
            }
        ]
    }
}