SRV Service Locator Common
Specifies the hostname, port, priority, and weight for a specific service running on a domain.
What it's for
An SRV (Service) record specifies not just where a service is hosted (a hostname) but also the port it runs on, and lets you weight and prioritize multiple servers offering the same service. It's how protocols like SIP (VoIP), XMPP (chat), and Microsoft's Active Directory/Exchange auto-discovery locate the right server for a specific service on a domain, without hardcoding a port or relying on a fixed well-known port the way HTTP relies on 443.
The record name itself encodes the service and protocol it applies to, using a specific underscore-prefixed format — _service._proto.name.
Format & syntax
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
- Name —
_service._protocol.domain, e.g._sip._tcp.example.com.for SIP over TCP - Priority — lower number = higher priority, same convention as MX
- Weight — used to load-balance between records of equal priority; a higher weight means a proportionally higher chance of being selected
- Port — the TCP or UDP port the service actually listens on
- Target — the hostname running the service, which resolves via a normal A/AAAA record
Multiple SRV records for the same service let clients fail over to a secondary server, or spread load across several servers at the same priority using the weight field.
How it's used in practice
- Microsoft services auto-discovery — Active Directory domain controllers, Exchange Autodiscover, and Skype for Business/Teams all rely on specific SRV records so clients can locate the right servers automatically just from a domain name and a well-known service label.
- VoIP and SIP — SIP trunking and VoIP providers commonly require SRV records (
_sip._tcpor_sip._udp) so client devices and PBX systems know which server and port to register against. - XMPP/chat services — federated chat protocols use SRV records (
_xmpp-client._tcp,_xmpp-server._tcp) to locate the right server for client connections versus server-to-server federation. - Minecraft servers and gaming — a well-known non-enterprise use case: Minecraft Java Edition supports
_minecraft._tcpSRV records so a server can run on a non-default port while players still just type the plain domain name.
Common mistakes & gotchas
- Wrong underscore/service naming format — the
_service._protonaming is strict, and typos (missing underscore, wrong protocol label) mean clients that expect a specific SRV lookup simply won't find it — no error, just silent failure to auto-discover. - Forgetting the target needs its own A/AAAA record — the SRV target field is a hostname, not an IP, and that hostname needs to resolve normally, same restriction as MX.
- Assuming SRV works for arbitrary services without client support — SRV only helps if the client software is written to actually look up SRV records for that service. Plenty of protocols (HTTP being the biggest one) never adopted SRV lookups in mainstream clients despite technically being supportable, which is part of why SVCB/HTTPS records exist as a more modern equivalent for the web specifically.
- Priority/weight confusion — treating weight like priority (lower-is-better) when weight actually works the opposite way — a higher weight means more traffic, used only to split load between records that already share the same priority tier.
Comparison & FAQ
| Type | Purpose | Key difference from SRV |
|---|---|---|
| MX | Mail-specific service location with priority only | SRV generalizes this to any service, and adds port + weight fields MX doesn't have |
| NAPTR | Rule-based rewriting, often used alongside SRV in SIP/ENUM setups | NAPTR is more of a "figure out what to look up next" step, sometimes resolving to an SRV lookup |
| SVCB / HTTPS | Modern service binding records, primarily for web/HTTP use cases | Purpose-built for HTTP(S) and general service parameters (like TLS/ALPN hints), where SRV historically had limited client adoption |
Why does my client not seem to use the SRV record I set up?
The client software has to explicitly support SRV lookups for that specific service — not every protocol's clients check for SRV records, even though the DNS record type itself works fine. Confirm the specific service/software you're configuring actually documents SRV support.
What's the difference between priority and weight in an SRV record?
Priority works like MX — lower numbers are tried first. Weight only matters between records that share the same priority, and controls the relative proportion of traffic/selection each one gets; a higher weight means it's chosen more often.
Can I use SRV records for a website instead of just a normal A record?
Not with mainstream web browsers — HTTP/HTTPS clients historically don't check SRV records for websites, which is exactly the gap that newer HTTPS and SVCB record types were designed to fill.
Why does the SRV record name start with underscores?
It's a naming convention (RFC 2782, later formalized further in RFC 8552) that marks the name as a "service" label rather than an actual hostname, preventing collisions with real subdomains someone might register.