An SRV record advertises the host and port for a specific service. It lets clients discover where a protocol lives without hardcoding.
SRV records answer the question 'where does this service run for this domain?'. They encode a target host and port along with priority and weight values, all under a structured name like _sip._tcp.example.com. Protocols such as SIP, XMPP, LDAP, Microsoft Teams, and game servers like Minecraft use SRV records so administrators can move a service to a new host or port by editing DNS instead of reconfiguring every client.
Because the priority and weight fields let you steer traffic, SRV records double as a lightweight load-balancing and failover mechanism: clients try the lowest priority first and distribute load across equal priorities according to weight. A malformed SRV, a wrong port, or a target that does not resolve will quietly stop clients from connecting. This checker fetches the SRV record for your service name across many locations, so you can confirm the host, port, priority, and weight are consistent everywhere and that a recent change has propagated. Divergent answers between regions mean the update is still spreading through resolver caches.
Frequently asked questions
- What format does an SRV record use?
- It lists priority, weight, port, and target host, under a name like _service._proto.domain.
- How do priority and weight work?
- Clients pick the lowest priority, then split load across equal priorities by weight.