D
DNS Monitor

DNS SRV Record Explained

What DNS SRV records are, how they work, their syntax and fields, and how services like VOIP, XMPP, and Microsoft 365 use them for service discovery.

SRV (Service) records tell clients where to find specific services for a domain. While A records say "this domain is at this IP address" and MX records say "send mail to this server," SRV records say "the SIP phone service for this domain runs on this server, on this port, with this priority."

SRV records are less common than A, CNAME, or MX records, but they are essential for certain protocols and services. If you use Microsoft 365, VoIP systems, XMPP chat, or any protocol that supports SRV-based service discovery, understanding SRV records matters. For a broader overview of record types, see DNS Record Types Explained.

SRV Record Syntax

An SRV record has a specific naming convention and format that differs from other DNS records:

_service._protocol.name.    TTL    IN    SRV    priority weight port target

A real example for a SIP (VoIP) service:

_sip._tcp.example.com.    86400    IN    SRV    10 60 5060 sipserver.example.com.

Breaking Down Each Field

_service: The symbolic name of the service, prefixed with an underscore. Common values include _sip (SIP/VoIP), _xmpp-client (XMPP chat), _ldap (LDAP directory), and _minecraft (Minecraft servers).

_protocol: The transport protocol, also prefixed with an underscore. Almost always _tcp or _udp.

name: The domain the service belongs to.

priority: A number indicating preference, where lower values are preferred (like MX priority). A server with priority 10 is preferred over one with priority 20.

weight: A number used for load balancing among servers with the same priority. Higher weights get more traffic. If two servers both have priority 10 but weights of 60 and 40, the first server should receive roughly 60% of connections and the second 40%.

port: The TCP or UDP port number where the service is running. This is one of the key features of SRV records -- they let you run services on non-standard ports without requiring the client to know the port in advance.

target: The hostname of the server providing the service. This must be a hostname with an A or AAAA record, not an IP address directly.

How SRV Records Work

When a client application needs to find a service, it queries DNS for the SRV record matching the service name and protocol under the domain. The DNS response tells the client exactly which server to connect to and on which port.

For example, a SIP phone client configured for example.com would query:

_sip._tcp.example.com

The DNS response might return:

_sip._tcp.example.com.    SRV    10 60 5060 sip1.example.com.
_sip._tcp.example.com.    SRV    10 40 5060 sip2.example.com.
_sip._tcp.example.com.    SRV    20 0  5060 sip-backup.example.com.

The client processes the response:

  1. First, try servers with the lowest priority (10). Both sip1 and sip2 have priority 10.
  2. Among priority 10 servers, distribute connections by weight: 60% to sip1, 40% to sip2.
  3. If both priority 10 servers are unavailable, try sip-backup (priority 20).
  4. Connect to the selected server on port 5060.

This gives you failover (through priority) and load balancing (through weight) built into DNS.

Common Uses of SRV Records

Microsoft 365 / Office 365

Microsoft 365 uses SRV records for autodiscovery of Exchange Online and Skype for Business/Teams services:

_autodiscover._tcp.example.com.    SRV    0 0 443 autodiscover.outlook.com.
_sip._tls.example.com.             SRV    100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp.example.com. SRV   100 1 5061 sipfed.online.lync.com.

The autodiscover SRV record lets Outlook clients find the Exchange server without manual configuration. When a user enters their email address, Outlook queries the SRV record and connects to the correct server automatically.

VoIP / SIP

SIP (Session Initiation Protocol) is one of the most common users of SRV records. VoIP systems use SRV records to locate SIP servers:

_sip._udp.example.com.    SRV    10 50 5060 voip1.example.com.
_sip._tcp.example.com.    SRV    10 50 5060 voip1.example.com.
_sips._tcp.example.com.   SRV    10 50 5061 voip1.example.com.

The _sips service is SIP over TLS (encrypted).

XMPP / Jabber

XMPP messaging uses SRV records for both client and server-to-server connections:

_xmpp-client._tcp.example.com.    SRV    5 0 5222 xmpp.example.com.
_xmpp-server._tcp.example.com.    SRV    5 0 5269 xmpp.example.com.

The _xmpp-client record is queried by chat clients connecting to the server. The _xmpp-server record is queried by other XMPP servers for federation (server-to-server communication).

CalDAV and CardDAV

Calendar and contact synchronization protocols use SRV records for service discovery:

_caldavs._tcp.example.com.    SRV    0 0 443 cal.example.com.
_carddavs._tcp.example.com.   SRV    0 0 443 contacts.example.com.

LDAP

Directory services use SRV records for locating LDAP servers:

_ldap._tcp.example.com.    SRV    0 0 389 ldap.example.com.

Active Directory environments rely heavily on SRV records for domain controller discovery.

Minecraft

Minecraft servers use SRV records to allow players to connect to a custom domain without specifying a port:

_minecraft._tcp.play.example.com.    SRV    0 5 25565 mc.example.com.

Without the SRV record, players would need to type mc.example.com:25565. With the SRV record, they can type play.example.com and the game client discovers the correct server and port automatically.

Setting Up SRV Records

To create an SRV record in your DNS provider's interface:

  1. Go to your domain's DNS management panel.
  2. Add a new record with type "SRV."
  3. For the name/host field, enter the service and protocol prefix (e.g., _sip._tcp). Some providers add the domain automatically; others require the full name.
  4. Set the priority, weight, port, and target according to your service's requirements.
  5. Set an appropriate TTL (3600 seconds is common; use lower values during initial setup for faster iteration).
  6. Save the record.

Each DNS provider's interface handles SRV records differently. Some have dedicated fields for each component (priority, weight, port, target). Others expect you to enter the entire value string in a single field.

Verify the record format after saving

SRV records have more fields than most record types, and DNS provider interfaces handle them inconsistently. After saving, use dig SRV _service._protocol.yourdomain.com to verify that the record is published correctly with the right priority, weight, port, and target.

Checking SRV Records

Using dig

dig SRV _sip._tcp.example.com

# Short output
dig SRV _sip._tcp.example.com +short

Using nslookup

nslookup -type=SRV _sip._tcp.example.com

Using host

host -t SRV _sip._tcp.example.com

For more lookup tools, see the dig Command Guide and the nslookup Command Guide.

Priority and Weight in Detail

Priority and weight together give you flexible traffic distribution.

Priority determines the order of preference. Clients must try all servers at the lowest priority number before moving to the next priority level. This provides failover: primary servers at priority 10, backup servers at priority 20.

Weight provides proportional load balancing among servers at the same priority. The weight is relative, not absolute. Among servers with the same priority, the probability of selecting a given server is its weight divided by the sum of all weights at that priority.

Example:

SRV    10 70 5060 server-a.example.com.
SRV    10 30 5060 server-b.example.com.
SRV    20 50 5060 server-c.example.com.
  • Server A: 70/(70+30) = 70% of traffic at priority 10.
  • Server B: 30/(70+30) = 30% of traffic at priority 10.
  • Server C: Only used if both Server A and Server B are unavailable.

A weight of 0 means the server should only be selected as a last resort among servers at the same priority.

Limitations of SRV Records

Not all protocols support SRV records. HTTP/HTTPS notably does not use SRV records for service discovery. Web browsers do not query SRV records when navigating to a URL. This is a long-standing gap that proposals like HTTPSSVC (now HTTPS/SVCB records) aim to address.

Client support is required. The client application must be programmed to query SRV records. If a client does not implement SRV lookup, the record is useless for that client.

No IP addresses in the target field. The target must be a hostname, not an IP address. That hostname must have its own A or AAAA record.

The target cannot be a CNAME. SRV records should point to hostnames that resolve directly to A or AAAA records, not to CNAMEs.

Disabling a Service with SRV Records

To explicitly indicate that a service is not available for a domain, create an SRV record with a single dot (.) as the target:

_xmpp-client._tcp.example.com.    SRV    0 0 0 .

This tells clients that the service does not exist for this domain and they should not attempt to connect. Without this record, clients might try default ports or fall back to other discovery methods.

References

  1. RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)," February 2000. https://datatracker.ietf.org/doc/html/rfc2782
  2. RFC 6120, "Extensible Messaging and Presence Protocol (XMPP): Core," March 2011. https://datatracker.ietf.org/doc/html/rfc6120
  3. Microsoft, "External DNS records required for Office 365," https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records

Monitor your SRV records for changes

DNS Monitor tracks all your DNS record types, including SRV records. Get alerted when service discovery records change and catch misconfigurations before they cause outages.

Try DNS Monitor

Related Articles