What is an SRV record? (and why email rarely needs one)

The one-sentence version

An SRV (service) record tells a client where a named service lives: which host answers it, on which port, and in what priority order. It is for service discovery, so a program can find a server without anyone typing in a hostname and port.

What an SRV record looks like

The name encodes the service and protocol, and the value carries four parts:

_submission._tcp.example.com.   3600   IN   SRV   0   1   587   mail.example.com.
                                                ^   ^   ^^^   ^^^^^^^^^^^^^^^^^^
                                          priority  |  port   target host
                                                  weight

• Priority works like an MX record: clients try the lowest number first.
• Weight spreads load across records that share a priority.
• Port is the actual port the service listens on.
• Target is the hostname providing it.

SRV does not route your email

Say this part plainly, because it is the most common confusion: SRV records have nothing to do with where your mail is delivered. Inbound mail routing is the MX record's job, and no mail server consults SRV to decide where to deliver a message. SRV is for clients finding services, not servers finding each other.

Where SRV does touch email: client autoconfig

The one email-relevant use is helping a mail program configure itself. A standard set of SRV records lets a mail client take just a user's email address and discover the right servers and ports:

• _submission._tcp points to your outgoing (SMTP submission) server, typically port 587.
• _imap._tcp and _imaps._tcp point to your IMAP server (typically 143, or 993 for direct TLS).
• _pop3._tcp and _pop3s._tcp do the same for POP3 (110, or 995 for direct TLS).

Those port numbers are the usual defaults, but they are not fixed: the whole point of the port field is that a provider can publish whatever port it actually uses. (Newer setups that use TLS from the first byte on port 465 use a separate _submissions._tcp label.)

Autodiscover, honestly

SRV is one way clients auto-configure, not the universal one, and it is easy to overstate:

• Microsoft Outlook can use an _autodiscover._tcp SRV record, but only as a fallback. It checks an autodiscover CNAME and HTTPS endpoints first, and reaches for the SRV record only if those do not answer.
• Mozilla Thunderbird does not use SRV at all. It relies on well-known configuration URLs and a central database of provider settings.

The same rules as MX and NS

An SRV target follows the familiar pointer rules: it must be a real hostname with its own A or AAAA address record, never a CNAME. And a target of a single dot (.) is a deliberate signal that the service is not offered at this domain, the same idea as a null MX.

Do you need to publish SRV records?

For most domains, no. SRV records do not affect whether your mail is delivered or whether it passes SPF, DKIM, or DMARC. They only make client setup smoother. And the big providers handle that for you: Google Workspace and Microsoft 365 run autodiscover through their own infrastructure (Microsoft publishes an autodiscover CNAME, not your SRV record), so a typical tenant never publishes email SRV records. Add your own only if you self-host mail, or your provider specifically tells you to.

Common questions

Does an SRV record affect email delivery?

No. Delivery is decided by your MX record and your authentication by SPF, DKIM, and DMARC. SRV only helps mail clients find your servers during setup.

Do I need an SRV record for Google Workspace or Microsoft 365?

No. Both handle mail-client autoconfiguration through their own systems (Microsoft 365 uses an autodiscover CNAME). You do not publish your own email SRV records for them.

What does a target of “.” mean in an SRV record?

It means the service is deliberately not available at this domain, so clients should not keep looking. It is the SRV equivalent of a null MX.