{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/discover-mail-endpoints-through-service-specific-srv-records/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/",
        "slug": "discover-mail-endpoints-through-service-specific-srv-records",
        "url": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/discover-mail-endpoints-through-service-specific-srv-records/"
        },
        "title": "Discover mail endpoints through service-specific SRV records",
        "summary": "Use RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services 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": "managed-it",
            "label": "Managed IT operations",
            "alt": "A controlled technology lifecycle progressing from assessment to approved production.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-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:04+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 608,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services",
        "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 6186 — Use of SRV Records for Locating Email Submission/Access Services",
            "url": "https://www.rfc-editor.org/rfc/rfc6186.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: Discover mail endpoints through service-specific SRV records. 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/rfc6186.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services</a> from RFC Editor / Internet Engineering Task Force supports the following bounded statements:</p>\n<ul>\n<li>A mail client uses the domain part of the user&#8217;s address to query service-specific SRV names and obtains the selected endpoint&#8217;s target host and port. The research record locates this support at <strong>Section 4 (Guidance for MUAs)</strong>.</li>\n<li>The _imap and _pop3 labels identify explicit-TLS-upgrade services, while _imaps and _pop3s identify services that begin TLS immediately on connection. The research record locates this support at <strong>Sections 3.2 (IMAP) and 3.3 (POP3)</strong>.</li>\n<li>When several SRV records describe one service, the client must apply SRV priority and weight; a target of a single dot marks that service unavailable. The research record locates this support at <strong>Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs)</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 4 (Guidance for MUAs)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Sections 3.2 (IMAP) and 3.3 (POP3)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs)</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>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>Keep the source locations <strong>Section 4 (Guidance for MUAs)</strong>; <strong>Sections 3.2 (IMAP) and 3.3 (POP3)</strong>; <strong>Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs)</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>Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc6186.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services</a> — RFC Editor / Internet Engineering Task Force</li>\n</ul>",
        "content_text": "Treat this document as a focused evidence review: Discover mail endpoints through service-specific SRV records. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA mail client uses the domain part of the user’s address to query service-specific SRV names and obtains the selected endpoint’s target host and port. The research record locates this support at Section 4 (Guidance for MUAs).\nThe _imap and _pop3 labels identify explicit-TLS-upgrade services, while _imaps and _pop3s identify services that begin TLS immediately on connection. The research record locates this support at Sections 3.2 (IMAP) and 3.3 (POP3).\nWhen several SRV records describe one service, the client must apply SRV priority and weight; a target of a single dot marks that service unavailable. The research record locates this support at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs).\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 4 (Guidance for MUAs), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Sections 3.2 (IMAP) and 3.3 (POP3), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs), 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.\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\nKeep the source locations Section 4 (Guidance for MUAs); Sections 3.2 (IMAP) and 3.3 (POP3); Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs) 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.\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\nOfficial references\n\nRFC 6186 — Use of SRV Records for Locating Email Submission/Access Services — RFC Editor / Internet Engineering Task Force",
        "content_markdown": "Treat this document as a focused evidence review: Discover mail endpoints through service-specific SRV records. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services](https://www.rfc-editor.org/rfc/rfc6186.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\n- A mail client uses the domain part of the user’s address to query service-specific SRV names and obtains the selected endpoint’s target host and port. The research record locates this support at Section 4 (Guidance for MUAs).\n\n- The _imap and _pop3 labels identify explicit-TLS-upgrade services, while _imaps and _pop3s identify services that begin TLS immediately on connection. The research record locates this support at Sections 3.2 (IMAP) and 3.3 (POP3).\n\n- When several SRV records describe one service, the client must apply SRV priority and weight; a target of a single dot marks that service unavailable. The research record locates this support at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs).\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 4 (Guidance for MUAs), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Sections 3.2 (IMAP) and 3.3 (POP3), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs), 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\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\nKeep the source locations Section 4 (Guidance for MUAs); Sections 3.2 (IMAP) and 3.3 (POP3); Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs) 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\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\n\n## Official references\n\n- [RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services](https://www.rfc-editor.org/rfc/rfc6186.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/discover-mail-endpoints-through-service-specific-srv-records/",
                "url": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Discover mail endpoints through service-specific SRV records",
                        "item": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/#article",
                "identifier": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/",
                "url": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/",
                "headline": "Discover mail endpoints through service-specific SRV records",
                "description": "Use RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services to review this narrow operational decision without extending the source…",
                "abstract": "Use RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Treat this document as a focused evidence review: Discover mail endpoints through service-specific SRV records. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services from RFC Editor / Internet Engineering Task Force supports the following bounded statements:\n\nA mail client uses the domain part of the user’s address to query service-specific SRV names and obtains the selected endpoint’s target host and port. The research record locates this support at Section 4 (Guidance for MUAs).\nThe _imap and _pop3 labels identify explicit-TLS-upgrade services, while _imaps and _pop3s identify services that begin TLS immediately on connection. The research record locates this support at Sections 3.2 (IMAP) and 3.3 (POP3).\nWhen several SRV records describe one service, the client must apply SRV priority and weight; a target of a single dot marks that service unavailable. The research record locates this support at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs).\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 4 (Guidance for MUAs), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Sections 3.2 (IMAP) and 3.3 (POP3), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs), 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.\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\nKeep the source locations Section 4 (Guidance for MUAs); Sections 3.2 (IMAP) and 3.3 (POP3); Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs) 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.\nKeep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.\nOfficial references\n\nRFC 6186 — Use of SRV Records for Locating Email Submission/Access Services — RFC Editor / Internet Engineering Task Force",
                "datePublished": "2026-08-27T12:17:04+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/"
                },
                "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/discover-mail-endpoints-through-service-specific-srv-records/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Discover mail endpoints through service-specific SRV records"
                },
                "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": 608,
                "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 6186 — Use of SRV Records for Locating Email Submission/Access Services",
                    "url": "https://www.rfc-editor.org/rfc/rfc6186.html"
                }
            }
        ]
    }
}