Use of SRV Records for Locating Email Submission/Access Services
updated by
- rfc-8314 — Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
updates
Extracted elements (19)
The specification was motivated by the poor user experience of requiring users to manually enter FQDNs and port numbers for email services. By using SRV records, an MUA need only prompt for the user's email address, from which the domain portion is extracted to perform SRV lookups, enabling fully automatic service configuration.
The SRV priority field is repurposed to express domain-wide preference between IMAP and POP3 protocols, not just between servers for a single service. This allows a domain operator to steer capable MUAs toward a preferred protocol without requiring protocol-specific configuration in the MUA.
RFC 6186 updates RFC 1939 (POP3) and RFC 3501 (IMAP) by defining SRV-based discovery for those protocols. It does not update RFC 5321 (SMTP) directly but defines a new `_submission` label for the RFC 4409 submission profile, which does not use MX records.
If an SRV RR target is set to ".", clients MUST assume the specified service is not available at that domain and rely on SRV RRs for other services to determine domain preference.
MUAs MUST first use the full email address as the user identifier for authentication. If that fails, they SHOULD fall back to using only the local-part of the email address. If both fail, the MUA SHOULD prompt the user for a valid identifier.
MUAs SHOULD cache the successfully used service details (hostname, port, user identity) and reuse them on subsequent connections. If a subsequent connection or authentication fails, MUAs SHOULD re-try the SRV lookup to refresh cached data.
Service providers SHOULD configure servers to allow authentication with either full email addresses or local-parts. Email addresses used as login names MUST NOT conflict with other permitted login names; local-parts MUST NOT conflict with any login name on the server.
Service providers using TLS MUST install a certificate verifiable by MUAs per RFC 6125 (SRV RR as starting point). If multiple domains are hosted on the same IP address, the service provider MUST enable support for TLS Server Name Indication (RFC 6066).
Sites SHOULD offer both IMAP and POP3 SRV record sets and set priority values such that the preferred service has a lower-numbered priority. When an MUA supports both protocols, it SHOULD retrieve records for both and use the one with the lowest priority value.
Upon connection failure or authentication failure, MUAs MUST NOT switch from IMAP to POP3 (or vice versa) due to changes in SRV priorities without explicit user interaction; the re-try must be for the same protocol the client had already chosen.
When considering multiple SRV records for different protocols at the same priority but with different weights, the client MUST first select the protocol it intends to use, then apply the weight selection algorithm from RFC 2782 to records for that protocol only.
When multiple SRV records are returned for a service, the MUA MUST use the priority and weight fields in the record to determine which one to use, as specified in RFC 2782.
When using TLS (STARTTLS or direct TLS), MUAs SHOULD use TLS Server Name Indication (RFC 6066). Certificate verification MUST use the procedure outlined in Section 6 of RFC 6125 with respect to verification where an SRV RR is the starting point.
The `_submission._tcp` SRV service label identifies a Mail Submission Agent (MSA) using RFC 4409. It covers connections both with and without TLS as defined for SMTP in RFC 3207. The conventional port is 587.
Two SRV service labels are defined for IMAP: `_imap._tcp` (port 143) identifies an IMAP server that MAY require STARTTLS before authentication; `_imaps._tcp` (port 993) identifies an IMAP server where TLS is initiated directly upon connection.
Two SRV service labels are defined for POP3: `_pop3._tcp` (port 110) identifies a POP3 server that MAY require the STLS extension before authentication; `_pop3s._tcp` (port 995) identifies a POP3 server where TLS is initiated directly upon connection.
A malicious attacker with access to DNS data can cause MUAs to connect to attacker-chosen servers. In the absence of secure DNS, MUAs SHOULD verify that the SRV target FQDN matches the queried service domain; if not, SHOULD confirm with the user before connecting. When TLS is used, MUAs MUST apply RFC 6125 verification.
Email clients and servers MUST NOT request, offer, or use SSL 2.0 due to known security vulnerabilities, as noted in Appendix E.2 of RFC 5246.
If a user has explicitly requested a secure connection, the MUA MUST successfully negotiate TLS before sending any authentication command. This applies to imaps, pop3s, imap with STARTTLS, or pop3 with STLS.