DNS Records & Concepts
What is an SRV record?
An SRV record, Service record, is a DNS record that specifies the hostname and port number of servers that provide a specific service for a domain. Where an A record simply maps a domain name to an IP address, an SRV record is more structured, it identifies not just which server to connect to but which service is being provided, which protocol it uses, on which port it listens, and how multiple servers providing the same service should be prioritised and load-balanced.
SRV records were defined in 1996 as a generalisable mechanism for service location in DNS, a way to publish information about any service associated with a domain without requiring clients to know port numbers in advance or rely on hardcoded connection details. The idea was that a client needing to connect to, say, the XMPP chat service for example.com could look up an SRV record rather than assuming a default port or requiring manual configuration.
SRV records are not encountered as frequently as A records, CNAME records, or TXT records in everyday domain management. They appear in specific contexts, VoIP systems, instant messaging platforms, Microsoft services, certain email configurations, and game servers, where clients need to discover service endpoints through DNS rather than through hardcoded configuration. Understanding SRV records is relevant for anyone managing domains that host these services alongside web presence and redirect configurations.
How an SRV record works
A client that needs to connect to a specific service for a domain queries DNS for an SRV record with a specially formatted name that identifies the service and protocol. The SRV record returns the information needed to establish the connection, which server to contact, on which port, and in what order to try if multiple servers are available.
The SRV record query name follows a specific format combining the service name and protocol with the domain:
For example to discover the XMPP client connection service for example.com a client queries:
The authoritative nameserver returns the SRV record or records for that query name. The client reads the response and connects to the specified server on the specified port.
If multiple SRV records exist for the same service the client uses the priority and weight values to determine which server to try first, which to fall back to, and how to distribute connections across equally-prioritised servers.
SRV record format and fields
An SRV record contains six components, the service-protocol name, the record type, the TTL, and four value fields that specify how to connect to the service.
A complete SRV record in zone file format looks like:
Breaking this down into its components:
Name, _xmpp-client._tcp.example.com: the query name for this service. The underscore prefix on service and protocol names is a DNS convention that distinguishes SRV-related labels from regular domain name components and prevents conflicts with actual hostnames. _xmpp-client identifies the XMPP client connection service. _tcp specifies the TCP protocol. example.com is the domain.
Priority, 10: a number between 0 and 65535 that controls failover ordering. Clients try servers with lower priority numbers first. A primary server with priority 10 is tried before a backup server with priority 20. When the primary is unavailable the client falls back to the next lowest priority. Priority in SRV records works identically to priority in MX records: lower is higher preference.
Weight, 20: a number between 0 and 65535 that controls load distribution among servers with the same priority. When multiple SRV records share the same priority value clients distribute connections proportionally according to weight. A server with weight 60 receives three times as many connections as a server with weight 20 in the same priority group. Weight zero means the server receives connections only when all non-zero-weight servers of the same priority are unavailable.
Port, 5222: the TCP or UDP port number on which the service is available. This is the critical piece of information that A records and CNAME records cannot provide. The SRV record tells the client not just which server to connect to but on which port the service is listening. Port 5222 is the standard port for XMPP client connections.
Target, xmpp.example.com: the hostname of the server providing the service. The client performs an additional DNS lookup, an A record or AAAA record lookup, for this hostname to find the server’s IP address. The target must be a hostname with its own A record, it cannot be an IP address directly and cannot be a CNAME record. A target value of .: a single dot, means the service is explicitly unavailable and clients should not attempt to connect.
Common uses of SRV records
SRV records appear in a specific set of applications and services where dynamic service discovery through DNS is the established approach.
VoIP and SIP: Session Initiation Protocol uses SRV records extensively for VoIP service discovery. A client needing to make a call for example.com looks up _sip._tcp.example.com and _sip._udp.example.com to find the SIP server. SRV records allow VoIP providers to direct calls to the appropriate servers and implement failover without requiring clients to know specific server addresses.
XMPP, Jabber instant messaging: the XMPP protocol uses SRV records for both client-to-server and server-to-server connections. _xmpp-client._tcp.example.com for client connections and _xmpp-server._tcp.example.com for federation between XMPP servers. Any XMPP client configured with just the domain name can discover the correct server and port through SRV lookup.
Microsoft services: Microsoft uses SRV records extensively for Skype for Business, Microsoft Teams, Exchange Server autodiscovery, and other enterprise services. Setting up custom domains for Microsoft 365 typically requires adding several SRV records alongside CNAME records, MX records, and TXT records.
Common Microsoft 365 SRV records include:
Game servers: some multiplayer games use SRV records for server discovery, allowing game clients configured with just the game domain to find the server’s address and port without hardcoded configuration.
Email autodiscovery: some email clients support SRV records for autodiscovery, finding IMAP, POP3, and SMTP server addresses and ports by querying SRV records rather than requiring manual server configuration. Mozilla Thunderbird and some other clients support SRV-based autodiscovery through _imaps._tcp.example.com, _submission._tcp.example.com, and similar records.
CalDAV and CardDAV: calendar and contact synchronisation protocols used by Apple Calendar, Contacts, and similar applications use SRV records for server discovery. _caldavs._tcp.example.com and _carddavs._tcp.example.com allow clients to find the correct server endpoint without manual configuration.
Kubernetes and container orchestration: some Kubernetes service discovery mechanisms use SRV records internally to publish service endpoints, allowing clients to discover the hostname and port of services running in the cluster through DNS queries.
SRV records and redirect management
SRV records have no direct relationship with URL redirects or redirect management, they operate at the service discovery layer of DNS rather than at the HTTP layer where redirects function. However they are relevant to redirect management in several indirect ways.
Coexistence with redirect infrastructure DNS: domains connected to redirect management infrastructure via A records or CNAME records can simultaneously have SRV records for other services. Adding SRV records for VoIP, XMPP, or Microsoft services does not affect the redirect rules or the A/CNAME records connecting the domain to the redirect platform. The records serve different purposes and operate independently.
Domain migration considerations: when migrating a domain to a new hosting or redirect configuration, SRV records must be preserved at the new DNS provider alongside other record types. A migration that recreates only A, CNAME, MX, and TXT records while missing SRV records breaks any services that depend on SRV for discovery. A complete DNS audit before migration should identify all record types, including SRV, to ensure nothing is missed.
Nameserver changes: changing nameservers to a DNS provider that supports redirect management, Cloudflare, Route 53, and others, requires recreating all existing DNS records at the new provider including SRV records. The new provider’s interface must support SRV record creation, all major providers do, though the interface varies. Missing SRV records after a nameserver change breaks SRV-dependent services immediately.
Multiple SRV records and server selection
When a service has multiple SRV records the client uses a specific algorithm to select which server to contact.
Priority ordering: the client first considers priority values. It builds a list of all SRV records and groups them by priority value. The lowest priority value group is tried first. Only when all servers in the lowest priority group are unavailable does the client move to the next priority group.
Weighted random selection within a priority group: within a priority group the client selects a server using a weighted random algorithm. It sums all the weight values and generates a random number between 0 and the sum. It then selects the server whose cumulative weight range includes the random number. This produces a selection probability proportional to weight, a server with weight 60 is selected approximately three times as often as a server with weight 20.
Trying in order with fallback: the client connects to the selected server. If the connection fails it removes that server from consideration and repeats the selection algorithm with the remaining servers in the priority group. If all servers in the priority group fail the client moves to the next priority group.
This two-level selection algorithm, priority for failover, weight for load balancing within a priority, is what makes SRV records suitable for high-availability service configurations with multiple servers.
SRV records with zero weight
A weight value of zero in an SRV record is a special case in the selection algorithm. Zero-weight servers within a priority group are tried only after all non-zero-weight servers in that group have failed.
Zero weight is used for servers that should serve as last-resort options within a priority group, perhaps a lower-capacity backup server that should only receive traffic when primary servers are unavailable, but that should be tried before falling to the next priority group.
The selection algorithm handles zero-weight servers by separating them from non-zero-weight servers. Non-zero-weight servers in the priority group are selected using weighted random selection first. Only when all non-zero-weight servers have been tried and failed are zero-weight servers tried.
Checking SRV records
SRV records are queried using the same DNS tools as other record types but require specifying the full service-protocol query name.
dig command: on Linux and macOS:
Returns SRV records for the XMPP client service at example.com. Adding +short returns a condensed view showing priority weight port and target:
For Microsoft Teams SRV records:
nslookup: on Windows and other platforms:
Online tools: web-based DNS lookup tools support SRV record queries. Microsoft provides its own Microsoft 365 DNS check tool that verifies all required SRV, CNAME, MX, and TXT records for custom domain configuration. Tools like MXToolbox check SRV records for specific services.
Verifying target resolution: after verifying an SRV record exists also verify that the target hostname resolves to a valid IP address. An SRV record pointing to a target that has no A record causes connection failures even though the SRV record itself is correctly configured.
Common SRV record mistakes
Wrong query name format: SRV records require the underscore-prefixed service-protocol format _service._protocol.domain. Querying without the underscores or without specifying both service and protocol returns no results. Always use the exact query name format specified by the service’s documentation.
Missing target A record: an SRV record pointing to a target hostname that has no A record causes connection failures. The client finds the SRV record but cannot resolve the target to an IP address. Verify the target hostname resolves correctly after configuring SRV records.
Target is a CNAME: the DNS specification prohibits SRV record targets from being CNAME records. The target must be a hostname with its own A record. Some DNS implementations silently accept CNAME targets but the resulting configuration may cause unpredictable behaviour with strict clients.
Port number conflicts: specifying an incorrect port number in the SRV record causes clients to connect to the wrong port on the correct server. Verify port numbers against the service’s official documentation before configuring.
Missing SRV records during DNS migration: SRV records are often overlooked during DNS migration because they are less familiar than A, CNAME, MX, and TXT records. A complete export of all DNS records before migration must include SRV records. Missing them breaks SRV-dependent services immediately after the nameserver change.
Incorrect priority and weight values: accidentally setting a backup server’s priority lower than the primary makes it the preferred server, it receives all traffic while the primary sits idle. Verify that lower priority numbers are assigned to more capable preferred servers.