An SRV record (DNS type 33) tells clients not just where a service lives but on which port, with built-in priority and load-balancing fields. It answers a question a plain A record cannot: "where do I connect for SIP, or XMPP, or LDAP, on this domain, and what is the backup if the main host is down?" An SRV record carries four data fields (priority, weight, port, and target) under a specially named host of the form _service._protocol.name. This guide breaks down that naming convention, each field, real examples for the services that use SRV, why A records and CNAMEs cannot do the same job, and the mistakes that trip people up.
The record format
Every SRV record follows one exact shape. The owner name encodes the service and transport protocol; the data section holds four space-separated values ending in a target hostname.
_service._proto.name. TTL IN SRV priority weight port target.A concrete example for a SIP service over TLS:
_sips._tcp.example.com. 3600 IN SRV 10 60 5061 sip1.example.com.
_sips._tcp.example.com. 3600 IN SRV 10 40 5061 sip2.example.com.
_sips._tcp.example.com. 3600 IN SRV 20 0 5061 sip-backup.example.com.The owner name: _service._protocol
The host side of an SRV record is built from two underscore-prefixed labels followed by the domain. The underscores exist specifically to prevent a service label from colliding with a real hostname. The first label is the service (for example _sip, _xmpp-client, _ldap, _kerberos, _autodiscover, _minecraft). The second is almost always the transport, either _tcp or _udp. So _ldap._tcp.example.com means "the LDAP service over TCP for example.com."
The four data fields
| Field | Meaning |
|---|---|
| Priority | Which group of targets to try first. Lower wins. Clients use the lowest-priority set before any higher number, giving you active-passive failover. |
| Weight | Relative share of traffic among targets of the same priority. Higher gets more. A rough proportional load balancer. |
| Port | The TCP or UDP port the service listens on. This is the field A and CNAME records cannot express. |
| Target | The hostname running the service, as a fully qualified name ending in a dot. It must have its own A or AAAA record. |
How priority and weight work together
Think of priority as tiers and weight as the split inside a tier. A client gathers all SRV records, sorts by priority ascending, and tries the lowest-numbered tier first. Within that tier, it distributes connections across targets in proportion to their weights. Only if every target in a tier is unreachable does it fall through to the next priority. In the SIP example above, sip1 and sip2 share priority 10 and split traffic 60/40 by weight; sip-backup at priority 20 is used only when both priority-10 hosts fail. A weight of 0 is legal and simply means "use this only when no positively weighted target in the tier is available," or acts as the sole target if it is alone in its tier.
Real examples by service
; SIP (VoIP) over UDP
_sip._udp.example.com. 3600 IN SRV 10 100 5060 sip.example.com.
; XMPP client-to-server (chat)
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.
; XMPP server-to-server
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.
; LDAP (directory)
_ldap._tcp.example.com. 3600 IN SRV 0 100 389 ldap.example.com.
; Kerberos authentication
_kerberos._udp.example.com. 3600 IN SRV 0 100 88 kdc.example.com.
; Microsoft Autodiscover (Outlook)
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 autodiscover.example.com.
; Minecraft (lets players connect without typing a port)
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25565 mc-host.example.com.The Minecraft case is a good illustration of why SRV exists: a server running on a nonstandard port can publish an SRV record so players just enter play.example.com and the client silently learns the real port and host.
Why A records and CNAMEs cannot do this
- No port. An A record maps a name to an IP address, full stop. It has no field for a port number, so a client has to already know the port. SRV carries the port explicitly.
- No failover or weighting. You can publish several A records for round-robin, but DNS has no idea which targets are alive and A records carry no priority or weight. SRV gives you ordered tiers plus a weighted split.
- CNAME is an alias, not a locator. A CNAME points one name at another name; it still cannot specify a port or a preference order, and it cannot coexist with other record types on the same name.
Common setup mistakes
- Missing or wrong trailing dot on the target. The target should be a fully qualified domain name ending in a dot (
sip.example.com.). Without the dot, many DNS editors append the zone, turning it intosip.example.com.example.com. Note that the number fields have no dots; only the target does. - Pointing the target at a CNAME. The SRV target must resolve directly to an A or AAAA record. Aiming it at a CNAME violates the spec and breaks some clients. Use the real hostname.
- Wrong protocol label. Using
_tcpwhere the service runs on UDP (or vice versa), or inventing a label. SIP signaling, for instance, may be UDP, TCP, or TLS; match what the service actually uses. - Putting an IP address in the target. The target is a hostname, not an IP. Give it a name that has its own address record.
- Forgetting the port is mandatory. All four fields are required; there is no default port.
- Mismatched priorities when you meant to load balance. Targets must share the same priority number to split traffic by weight. Different priorities create failover tiers, not balancing.
Verifying an SRV record
Query the full underscore-prefixed name and ask specifically for the SRV type. The answer lists priority, weight, port, and target in that order.
$ dig +short SRV _sip._udp.example.com
10 100 5060 sip.example.com.
$ dig SRV _xmpp-client._tcp.example.com +noall +answer
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.
# Confirm the target actually resolves to an address
$ dig +short A sip.example.com
203.0.113.20Always follow up by confirming the target name resolves to an A or AAAA record and that the service is genuinely listening on the stated port. An SRV record that points at a host with no address record, or a closed port, will resolve cleanly in DNS yet still fail to connect.
Quick reference
Keep this mental model: the owner name says what service and protocol, priority says which tier first (lower wins), weight says how to split within a tier (higher gets more), port says where to knock, and target says which host (an FQDN with a trailing dot, backed by its own A or AAAA record, never a CNAME).
Setting up SRV for VoIP, chat, a directory, or a game server? Run the record through the Valla DNS propagation checker to confirm all four fields published correctly and that the target resolves, and explore our /learn/ guides on A, AAAA, CNAME, and MX records to see exactly where SRV fits among the record types.