RFC 6186: SRV Records for Email Service Autodiscovery

Current Standard DNS & Mail Routing DNS SRVAutodiscoveryIMAPMail Submission

ELI5: When you type your email address into a mail client like Thunderbird or Apple Mail, it needs to figure out which servers to connect to for sending and receiving. Instead of making you type in server names and port numbers, the client can look up special DNS records that say “the IMAP server for this domain is over here, the submission server is over there.” That is what RFC 6186 standardizes.

Why This Exists

Configuring an email client requires knowing multiple server hostnames, ports, and security settings: an IMAP or POP3 server for reading mail, and a submission server for sending. Most users cannot provide this information. Before SRV records, email clients relied on:

Guessing common hostnames like mail.example.com or imap.example.com
Proprietary autodiscovery protocols (Microsoft Autodiscover, Mozilla ISPDB)
Manual configuration guides

RFC 6186 provides a standard, DNS-based mechanism that works for any domain. The domain administrator publishes SRV records, and any compliant email client can discover the correct servers automatically.

How It Works

The email client extracts the domain from the user's email address, then queries DNS for SRV records under specific service names.

SRV Record Format

Name:     _service._proto.domain
Type:     SRV
Content:  priority weight port target

Required DNS Records

For a domain example.com with email hosted on mail.provider.net:

; Receiving mail (IMAP over TLS)
_imaps._tcp.example.com.    IN SRV  0 1 993 mail.provider.net.

; Receiving mail (IMAP with STARTTLS)
_imap._tcp.example.com.     IN SRV  0 1 143 mail.provider.net.

; Receiving mail (POP3 over TLS)
_pop3s._tcp.example.com.    IN SRV  0 1 995 mail.provider.net.

; Sending mail (Submission over TLS)
_submissions._tcp.example.com. IN SRV  0 1 465 mail.provider.net.

; Sending mail (Submission with STARTTLS)
_submission._tcp.example.com.  IN SRV  0 1 587 mail.provider.net.

Disabling a Service

To indicate that a service is not available, publish an SRV record with a target of . (a single dot):

; We do not offer POP3
_pop3._tcp.example.com.     IN SRV  0 0 0 .
_pop3s._tcp.example.com.    IN SRV  0 0 0 .

Key Technical Details

Service Names Defined by RFC 6186

SRV Name	Protocol	Default Port	Security
`_imaps._tcp`	IMAP	993	Implicit TLS (preferred)
`_imap._tcp`	IMAP	143	STARTTLS
`_pop3s._tcp`	POP3	995	Implicit TLS
`_pop3._tcp`	POP3	110	STARTTLS
`_submissions._tcp`	Submission	465	Implicit TLS (preferred)
`_submission._tcp`	Submission	587	STARTTLS

Client Discovery Priority

Query for _imaps._tcp first (implicit TLS is preferred over STARTTLS per RFC 8314).
If no _imaps record, fall back to _imap._tcp with mandatory STARTTLS.
For submission, prefer _submissions._tcp (port 465) over _submission._tcp (port 587).
Use SRV priority and weight fields for load balancing and failover across multiple servers.

TLS Certificate Verification

Per RFC 7817, the client must verify the server's TLS certificate against the SRV target hostname (e.g., mail.provider.net), not the user's email domain. This allows hosting providers to serve many domains with a single certificate.

Common Mistakes

Not publishing SRV records at all. Many domains rely on proprietary autodiscovery or assume users will configure manually. Publishing SRV records takes minutes and helps every standards-compliant email client.
Publishing only STARTTLS variants. RFC 8314 recommends implicit TLS. Publish both _imaps and _submissions records (implicit TLS) as the primary option, with STARTTLS variants as fallback.
SRV target pointing to a CNAME. The SRV target must be an A or AAAA record, not a CNAME. This is a DNS protocol requirement (RFC 2782). Pointing SRV at a CNAME can cause resolution failures.
Forgetting to disable unused services. If you do not support POP3, publish a "dot" SRV record to tell clients explicitly. Otherwise they may spend time probing ports that will never respond.
Certificate mismatch with SRV target. If your SRV record targets mail.provider.net, the TLS certificate on that server must include mail.provider.net in its SAN. Mismatches cause connection failures in clients that validate certificates.

Deliverability Impact

Reduces user misconfiguration. Autodiscovery means fewer users entering wrong settings, which means fewer "unable to send" support tickets and fewer messages stuck in outboxes.
Enforces TLS from the start. By advertising only TLS-enabled services via SRV, you ensure clients connect securely by default rather than starting unencrypted.
Enables smooth hosting migrations. When moving email to a new provider, update the SRV records and clients will automatically find the new servers without manual reconfiguration.
Complements submission best practices. SRV records for _submissions direct clients to the correct authenticated submission port (RFC 6409), keeping submission traffic properly separated from MX relay traffic.