Free SRV Record Lookup & Checker

Your IP:
Check the DNS record Propagation in Multi-Region Check Multi-Region
Domain Type Primary NS Responsible Person Serial Refresh Retry Expire Minimum TTL
Name Server IP Address TTL
Domain Type TTL Record Value
Trace Result
Domain Type Record Status
Domain Type Record Status

Check live SRV DNS records, TTL values, and trace the full root-to-authoritative resolution path.

SRV (Service) Records Overview

What is a SRV record?

An SRV record specifies the hostname and port of the servers for a specific service and protocol, such as SIP, XMPP, LDAP, or autodiscover.

Why do you need a SRV record?

SRV records let clients automatically discover the correct server and port for a service, instead of relying on hardcoded values.

SRV record structure

An SRV record uses a _service._protocol.domain name and stores priority, weight, port, and target. Example: _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.

How to create a SRV record?

In your DNS provider's console, add an SRV record using the _service._protocol.domain name, then set the priority, weight, port, and the target hostname of the server.

FAQs

They are priority, weight, port, and target. Priority (lowest first) and weight (load balancing among equal priorities) decide which target a client picks, while port and target give the server's location.

_service._protocol.domain - for example _sip._tcp.example.com or _xmpp-client._tcp.example.com.

Clients try the lowest priority number first; among targets with the same priority, weight distributes traffic proportionally (a higher weight receives more).

No. Like an MX record, the SRV target must be a hostname that resolves via A/AAAA records, not a literal IP address.

VoIP/SIP, XMPP (chat), LDAP, Microsoft Active Directory, mail-client autodiscover, Minecraft servers, and more.

SRV Record Troubleshooting & Common Fixes

VoIP, SIP, or game clients fail to connect: “No server found”

RFC 2782 explicitly prohibits raw IP addresses in the SRV target field; DNS resolvers expect a hostname that resolves via standard A or AAAA records. If an IPv4 address is entered directly into the target field, client connection discovery fails silently.

How to fix: Point the target field to a fully qualified domain name (e.g. sip.example.com), never an IP address. Verify that an active A or AAAA record exists for that target hostname. If editing raw BIND zone files, ensure you include a trailing dot (sip.example.com.) so your nameserver doesn't accidentally double-append your domain (sip.example.com.example.com).

Priority and weight failover traffic not balancing as intended

Traffic fails to route to the expected server because priorities are inverted or misunderstood. In SRV specifications, lower priority numbers have higher precedence (priority 10 is chosen before priority 20). If backup servers are assigned lower numbers, your primary host will never receive traffic.

How to fix: Assign your primary active server the lowest priority value (such as 10) and standby servers higher values (such as 20 or 30). For active-active load sharing among servers sharing the same priority, use weights (from 0 to 65535) to set proportional request distribution (for example, weights 70 and 30 split traffic 70/30).

Malformed SRV record name format in DNS provider dashboard

SRV records require a strict naming scheme: _service._protocol.domain (such as _autodiscover._tcp.example.com or _minecraft._tcp.example.com). Control panels differ widely: some automatically append the protocol and domain, causing inadvertent duplicate labels like _sip._tcp._sip._tcp.example.com.

How to fix: Inspect the live output in our lookup tool above. If your DNS host provides dedicated fields for “Service” and “Protocol”, enter only the service name (e.g. _sip) and protocol (e.g. _tcp). If it provides a single “Name/Host” field, enter _service._protocol (such as _sip._tcp) without re-typing the root domain.

DNS Info extension for Chrome is now available

Install