{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
        "slug": "aggregate-smtp-tls-policy-outcomes-into-daily-json-reports",
        "url": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/"
        },
        "title": "Aggregate SMTP TLS policy outcomes into daily JSON reports",
        "summary": "Use RFC 8460 — SMTP TLS Reporting to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "checklist",
            "name": "Checklist"
        },
        "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:09+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 554,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 8460 — SMTP TLS Reporting",
        "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 8460 — SMTP TLS Reporting",
            "url": "https://www.rfc-editor.org/rfc/rfc8460.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>Treat this document as a focused evidence review: Aggregate SMTP TLS policy outcomes into daily JSON reports. 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/rfc8460.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8460 — SMTP TLS Reporting</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>An SMTP TLS aggregate report is I-JSON containing report metadata, applied policy, aggregate session counts, and optional per-failure details. The research record locates this support at <strong>Section 4 (Reporting Schema)</strong>.</li>\n<li>A report should cover one UTC day, and senders should delay delivery to avoid overloading the report processor. The research record locates this support at <strong>Section 4.1 (Report Time Frame)</strong>.</li>\n<li>TLS reports may be delivered as email or by HTTP POST, using the transport-specific formats defined for each route. The research record locates this support at <strong>Section 5 (Report Delivery)</strong>.</li>\n</ul>\n<p>Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match.</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 4 (Reporting Schema)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 4.1 (Report Time Frame)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 5 (Report Delivery)</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. Begin by recording scope and current state before deciding whether a change is warranted. 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>Build a reproducible chain from <strong>Section 4 (Reporting Schema)</strong>; <strong>Section 4.1 (Report Time Frame)</strong>; <strong>Section 5 (Report Delivery)</strong> to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier.</p>\n<p>Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc8460.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8460 — SMTP TLS Reporting</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Treat this document as a focused evidence review: Aggregate SMTP TLS policy outcomes into daily JSON reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 8460 — SMTP TLS Reporting from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nAn SMTP TLS aggregate report is I-JSON containing report metadata, applied policy, aggregate session counts, and optional per-failure details. The research record locates this support at Section 4 (Reporting Schema).\nA report should cover one UTC day, and senders should delay delivery to avoid overloading the report processor. The research record locates this support at Section 4.1 (Report Time Frame).\nTLS reports may be delivered as email or by HTTP POST, using the transport-specific formats defined for each route. The research record locates this support at Section 5 (Report Delivery).\n\nOnly the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match.\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 4 (Reporting Schema), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.1 (Report Time Frame), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 5 (Report Delivery), 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. Begin by recording scope and current state before deciding whether a change is warranted. 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\nBuild a reproducible chain from Section 4 (Reporting Schema); Section 4.1 (Report Time Frame); Section 5 (Report Delivery) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier.\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\nOfficial references\n\nRFC 8460 — SMTP TLS Reporting — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Treat this document as a focused evidence review: Aggregate SMTP TLS policy outcomes into daily JSON reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 8460 — SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- An SMTP TLS aggregate report is I-JSON containing report metadata, applied policy, aggregate session counts, and optional per-failure details. The research record locates this support at Section 4 (Reporting Schema).\n\n- A report should cover one UTC day, and senders should delay delivery to avoid overloading the report processor. The research record locates this support at Section 4.1 (Report Time Frame).\n\n- TLS reports may be delivered as email or by HTTP POST, using the transport-specific formats defined for each route. The research record locates this support at Section 5 (Report Delivery).\n\nOnly the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match.\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 4 (Reporting Schema), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 4.1 (Report Time Frame), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 5 (Report Delivery), 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. Begin by recording scope and current state before deciding whether a change is warranted. 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\nBuild a reproducible chain from Section 4 (Reporting Schema); Section 4.1 (Report Time Frame); Section 5 (Report Delivery) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier.\n\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\n\n## Official references\n\n- [RFC 8460 — SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.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/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
                "url": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Aggregate SMTP TLS policy outcomes into daily JSON reports",
                        "item": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/#article",
                "identifier": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
                "url": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/",
                "headline": "Aggregate SMTP TLS policy outcomes into daily JSON reports",
                "description": "Use RFC 8460 — SMTP TLS Reporting to review this narrow operational decision without extending the source beyond its stated scope.",
                "abstract": "Use RFC 8460 — SMTP TLS Reporting to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Treat this document as a focused evidence review: Aggregate SMTP TLS policy outcomes into daily JSON reports. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 8460 — SMTP TLS Reporting from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nAn SMTP TLS aggregate report is I-JSON containing report metadata, applied policy, aggregate session counts, and optional per-failure details. The research record locates this support at Section 4 (Reporting Schema).\nA report should cover one UTC day, and senders should delay delivery to avoid overloading the report processor. The research record locates this support at Section 4.1 (Report Time Frame).\nTLS reports may be delivered as email or by HTTP POST, using the transport-specific formats defined for each route. The research record locates this support at Section 5 (Report Delivery).\n\nOnly the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match.\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 4 (Reporting Schema), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 4.1 (Report Time Frame), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 5 (Report Delivery), 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. Begin by recording scope and current state before deciding whether a change is warranted. 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\nBuild a reproducible chain from Section 4 (Reporting Schema); Section 4.1 (Report Time Frame); Section 5 (Report Delivery) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier.\nRecord the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.\nOfficial references\n\nRFC 8460 — SMTP TLS Reporting — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:17:09+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/"
                },
                "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/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/#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": "Aggregate SMTP TLS policy outcomes into daily JSON reports"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Checklist",
                    "Advisory priority"
                ],
                "genre": "Checklist",
                "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": 554,
                "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 8460 — SMTP TLS Reporting",
                    "url": "https://www.rfc-editor.org/rfc/rfc8460.html"
                }
            }
        ]
    }
}