SRV Record
Service Record
A DNS record that publishes not just where a service lives but which port it answers on — with built-in priority and weight for failover and load balancing. It is how protocols like SIP, XMPP, and Microsoft 365 find their servers.
An SRV record (service record) answers a richer question than an A record. An A record says "this name is at this IP." An SRV record says "the service you want runs on this host, at this port, and here is how to prioritise and balance across several of them." That extra information lets a protocol move its servers or change ports without touching a single client configuration.
Anatomy of an SRV record
SRV records use a structured name and a four-field value:
; _service._proto.name TTL type prio weight port target
_sip._tcp.example.com. 3600 SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. 3600 SRV 10 40 5060 sip2.example.com.
_sip._tcp.example.com. 3600 SRV 20 0 5060 backup.example.com.
The name encodes the service (_sip) and transport (_tcp or _udp), each prefixed with an underscore. The value carries four numbers: priority, weight, port, and the target hostname (which you then resolve with an A/AAAA record).
| Field | Meaning |
|---|---|
| Priority | Lower number wins; higher numbers are used only as failover |
| Weight | Among equal priorities, distributes load proportionally |
| Port | The TCP/UDP port the service listens on |
| Target | The hostname running the service |
Priority and weight in practice
The two numeric fields give DNS-level resilience without any load balancer. Priority behaves like an MX record: clients exhaust all the lowest-priority targets before trying higher numbers, so in the example above backup.example.com (priority 20) is only contacted if both priority-10 hosts are down. Weight splits traffic among targets that share a priority: sip1 at weight 60 takes about 60% of connections and sip2 at weight 40 takes the rest. Together they provide failover and proportional load balancing purely through DNS.
Where SRV records are used
- SIP / VoIP:
_sip._udpand_sips._tcplet phones find the call server and port automatically. - XMPP chat:
_xmpp-client._tcpand_xmpp-server._tcplocate messaging servers. - Microsoft 365 / Teams: autodiscovery relies on SRV records to point clients at the right endpoints.
- LDAP / Active Directory: domain controllers advertise themselves via SRV records.
- Minecraft and other games: an SRV record lets a server run on a non-default port while players connect using just the domain.
Looking up an SRV record
# macOS / Linux
dig _sip._tcp.example.com SRV +short
# Windows
nslookup -type=SRV _sip._tcp.example.com
The reply lists each target with its priority, weight, and port. Because the target is a hostname rather than an IP, a client performs a second lookup (an A or AAAA query on the target) to find the actual address before connecting — so a working SRV setup depends on the target's forward records existing too.