Skip to content
IPeek

SRV Lookup

Service location records

Checking…

What is an SRV record?

An SRV (Service) record advertises the hostname and port for a specific service — such as SIP, XMPP, LDAP or Microsoft autodiscover — along with priority and weight for load balancing. Unlike an A record, it tells clients not just where a service lives but on which port, so applications can locate services without hardcoded configuration. Query them using the _service._proto.domain form.

How the SRV record format works

An SRV record is named with a distinctive pattern: _service._proto.domain, for example _sip._tcp.example.com. The underscores prevent clashes with ordinary hostnames. The record's data holds four values: priority, weight, port and target. Priority works like MX — lower numbers are tried first. Weight distributes load among targets at the same priority, with higher weights getting proportionally more traffic. Port is the TCP or UDP port the service listens on, and target is the hostname providing it, which must have its own A or AAAA record.

How to read your SRV lookup results

IPeek returns each SRV record's priority, weight, port and target host for the service name you queried. Read priority first: clients use the lowest-priority targets before falling back to higher ones. Among equal priorities, weight decides the share of traffic each target receives. Confirm the port matches the service you expect — 5060 for SIP, 389 for LDAP, 443 for many autodiscover setups. Check that each target resolves to a valid host. An empty result means the service is not advertised under that name on the domain.

When you need SRV records

SRV records matter whenever clients must discover a service automatically rather than rely on fixed settings. Microsoft Teams, Skype for Business and SIP providers use them to locate voice and presence servers. XMPP chat, LDAP directory lookups, Minecraft servers and Kerberos all depend on SRV discovery. The big advantage is flexibility: move a service to a new host or port, or spread it across several servers, and clients follow the SRV records without reconfiguration. If a service requires a specific _service._proto name, publish a matching SRV record or clients will not find it.

Frequently asked questions

What does the _service._proto.domain naming format mean?

This pattern names an SRV record by the service and protocol it describes. _service is the service label (like _sip or _ldap), _proto is the transport (_tcp or _udp), and domain is your domain. For example, _sip._tcp.example.com advertises SIP over TCP. The leading underscores keep these labels from colliding with normal hostnames.

How do priority and weight work in an SRV record?

Priority and weight control which target a client chooses. Priority works like MX records: clients try the lowest-priority targets first and fall back to higher numbers. Among targets sharing a priority, weight sets the proportion of traffic each receives, so a higher weight draws more connections. Together they enable both failover and load balancing.

What is the difference between an SRV record and an A record?

An A record maps a hostname to an IP address, while an SRV record additionally specifies the port and adds priority and weight for a named service. SRV lets clients discover both where and on which port a service runs, plus how to balance load, which a plain A record cannot express. SRV targets still rely on A records to resolve.

Which services commonly use SRV records?

SIP and VoIP systems, XMPP chat, LDAP and Active Directory, Kerberos, Microsoft Teams and Skype for Business, and even Minecraft servers commonly use SRV records. Any protocol that benefits from automatic service discovery without hardcoded host and port settings is a candidate. The client must be written to query the relevant _service._proto name.

Why is my SRV lookup returning no results?

An empty SRV result usually means no record is published under that exact _service._proto.domain name. Check the service label, protocol and domain are spelled correctly, including the underscores. The service may use a different name than expected, or the record may simply not exist. Confirm the precise name the client application requires.