An SRV (Service) record is a DNS record type defined in RFC 2782 that tells clients which host and port run a specific network service. Its format _service._proto.name TTL IN SRV priority weight port target lets applications automatically locate servers for SIP, XMPP, LDAP and other protocols without hardcoding an address in the client configuration.
This guide breaks down the SRV syntax field by field, explains how priority and weight control failover and load balancing, shows real examples for SIP, XMPP, Autodiscover and Minecraft, and lists common mistakes — from a missing trailing dot in target to an invalid service name format. It ends with how to verify an SRV record using dig or online.
What an SRV record is and why it matters
A regular A or AAAA record maps a domain name to an IP address but says nothing about the port or the service priority. An SRV record fills that gap: the client queries a special name like _service._proto.domain and receives a list of servers along with their port, priority and weight. This enables resilient, load-balanced setups without a separate load balancer.
The standard is described in RFC 2782. SRV records power mail client autoconfiguration (Autodiscover), XMPP federation, Active Directory domain controller discovery (LDAP/Kerberos) and connections to SIP providers.
SRV syntax: field by field
A full SRV record line in a zone file looks like this:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.Here _sip is the symbolic service name, _tcp is the transport protocol, example.com is the domain, 3600 is the TTL, IN is the class and SRV is the type. Four key data fields follow, and they define how the client behaves.
SRV record data fields
| Field | Purpose | Example |
|---|---|---|
| priority | Server priority: the lower number is tried first | 10 |
| weight | Weight for load balancing among servers with equal priority | 60 |
| port | TCP/UDP port where the service listens | 5060 |
| target | Fully qualified domain name (FQDN) of the host, with a trailing dot | sipserver.example.com. |
How the service name is formed
The name follows the pattern _service._proto.name. The underscore before the service and protocol labels is mandatory — it separates these service labels from ordinary subdomains and prevents naming collisions. The protocol is almost always _tcp or _udp. For example, an XMPP client-to-server connection uses _xmpp-client._tcp.example.com.
How priority and weight work
The priority and weight fields govern server selection and load distribution. The logic is two-tiered: the client looks at priority first, then at weight.
Priority
The client always contacts records with the lowest priority value first. Records with a higher priority are used only when all servers at the previous level are unreachable. This is a built-in failover mechanism: the primary server gets priority 10, the backup gets priority 20.
Weight
Among records with the same priority, the client distributes requests proportionally to weight. If two servers have weight 70 and 30, they receive roughly 70% and 30% of the traffic. A weight of 0 means the server is chosen last when other non-zero weights are present.
Memory rule: priority sets the order (who goes first), weight sets the share (how much traffic) within a single priority level.
Where SRV records are used
SRV is used by protocols that need automatic server discovery. Below are the most common scenarios.
- SIP telephony:
_sip._tcp,_sips._tcp— connecting softphones and IP PBXs to a provider. - XMPP (Jabber):
_xmpp-client._tcpand_xmpp-server._tcp— messenger federation. - Autodiscover:
_autodiscover._tcp— autoconfiguration of Outlook and other mail clients. - Active Directory:
_ldap._tcp,_kerberos._tcp— locating domain controllers. - Minecraft:
_minecraft._tcp— connecting to a server on a non-standard port without typing the port in the client.
Important: the _dmarc entry is not an SRV record — it is a plain TXT record holding a DMARC policy, despite the similar underscore-prefixed name. Do not confuse service TXT labels (SPF, DKIM, DMARC) with SRV.
SRV record examples
Autodiscover for Exchange mail:
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 mail.example.com.Two SIP servers with failover and balancing:
_sip._tcp.example.com. 3600 IN SRV 10 70 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 30 5060 sip2.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 0 5060 sip-backup.example.com.Here sip1 and sip2 split traffic 70/30 at priority 10, while sip-backup only kicks in when both primaries fail.
How to check an SRV record
The fastest terminal method is the dig utility:
dig SRV _sip._tcp.example.com +shortThe response shows four space-separated fields: priority, weight, port and target. On Windows the equivalent is nslookup -type=SRV _sip._tcp.example.com. To check a record in the browser with no tools installed, use the enterno.io DNS lookup — choose the SRV type and enter the full service name.
Common SRV record mistakes
Missing trailing dot in target
The target field must be a full FQDN ending with a dot: sipserver.example.com. Without the dot, many DNS servers append the zone name and produce sipserver.example.com.example.com, so the service is never found.
Invalid service name format
The underscore before service and proto is mandatory. A record like sip.tcp.example.com instead of _sip._tcp.example.com will simply not be recognized as SRV. Watch the protocol too — SIP over TCP and over UDP are separate records.
Using an IP instead of a name in target
Per RFC, target must be a domain name, not an IP address. Putting an IP there violates the standard and is often ignored by clients. Create an A/AAAA record for the host and point target at it.
Weight on a single record
If there is only one server, weight is irrelevant, but many people mistakenly assign different priorities to the same host and break the failover logic. For a single server, set priority 0 and weight 0.
SRV in the context of other DNS records
SRV does not work in isolation. Learn how the other record types are structured: an overview in DNS record types, the server roles in DNS server types explained, and mail setup in the guide on MX records and email setup. For format documentation, see the MDN DNS Glossary.
Frequently Asked Questions
How is SRV different from an MX record?
An MX record serves mail only and carries no port — it is always 25. SRV is universal: it describes any service and includes port, priority and weight. In essence SRV generalizes the MX idea to arbitrary protocols, which is why it explicitly states both the port and the destination host.
Is the trailing dot in target mandatory?
Yes, for correct operation the target must be a full FQDN with a dot at the end. Without it, the DNS server treats the value as a relative name and appends the current zone name, which almost always yields the wrong host and an unreachable service.
Can there be several SRV records for one service?
Yes, and it is normal practice. Multiple records with different priorities provide failover, while records with the same priority and different weight provide load balancing. The client selects a server using the priority and weight rules described in RFC 2782.
How quickly does an SRV record update?
Update speed depends on the record's TTL value. If the TTL is 3600, caching resolvers keep the old value for up to an hour. Before a planned migration, lower the TTL in advance so changes propagate faster, then raise it back afterward.
Do all services support SRV records?
No, the service must know how to look up SRV. Protocols like SIP, XMPP, LDAP, Autodiscover and Minecraft do this by default. HTTP/SSL/TLS проверку historically does not use SRV — the web typically relies on A/AAAA and CNAME запись, although newer SVCB and HTTPS records carry a similar idea.