Free SRV record lookup – check service DNS records
SRV Record Lookup
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Enter a full SRV name above – for example _sip._tcp.example.com or _imaps._tcp.example.com – and the lookup returns every service endpoint it finds with priority, weight, port, target hostname and TTL. Lower priority wins; weight shares traffic between targets of equal priority; each target must have its own A or AAAA record. monitordefend does not monitor DNS records, but its uptime check emails you when your website stops answering.
- Free, no sign-up: priority, weight, port, target and TTL per record.
- Query the full _service._proto name – a bare domain usually shows nothing.
- Lowest priority first; weight balances equal-priority targets.
prio 10 weight 60 port 5060 sip1.example.com TTL 3600 prio 10 weight 40 port 5060 sip2.example.com TTL 3600 prio 20 weight 0 port 5060 backup.example.com TTL 3600
With this free SRV record lookup you check the service records of any domain in seconds. SRV records tell clients where a specific service lives – which host and which port to connect to, and in which order to try them. They power VoIP, chat, directory services and many SaaS integrations. When one of these connections fails, a look at the SRV record shows whether DNS sends clients to the right place.
How does the SRV record lookup work?
Type the complete SRV name into the field – the service, the protocol and the domain, each service and protocol label starting with an underscore – and start the check. The tool asks DNS for records of type SRV under exactly that name and lists every answer with its priority, weight, port, target hostname and TTL, the time-to-live that decides how long resolvers may cache the result.
The TTL is worth noting when you troubleshoot a recent change: a resolver that cached the old answer keeps using it until the TTL runs out. If the lookup already shows the new target but a client still connects to the old one, caching is the likely reason.
What is an SRV record?
An SRV record – short for service record – tells clients where to find a specific service for a domain. Instead of hard-coding a server name and port into every phone, chat client or application, the client asks DNS for the service and receives the hostname, the port and routing rules for choosing between several servers.
The format was standardised in RFC 2782. A record has four data fields: priority, weight, port and target. Because the service and protocol are part of the record name, one domain can publish different endpoints for SIP, XMPP, LDAP, CalDAV or mail access without them interfering with each other or with the website.
Which SRV name should you look up?
SRV records never live on the bare domain. They sit on a name in the form _service._proto.domain, for example _ldap._tcp.example.com or _xmpp-client._tcp.example.com. If you only look up example.com, the answer is usually empty – even when the service records are configured perfectly.
The protocol label is _tcp or _udp, sometimes _tls. The service label is defined by the protocol or the vendor you use, so check its setup guide for the exact name. Typing _sip._udp when the provider published _sip._tcp is enough to make a correct configuration look missing.
- _sip._tcp / _sip._udp / _sips._tcp – SIP telephony and VoIP
- _xmpp-client._tcp / _xmpp-server._tcp – XMPP chat
- _ldap._tcp – directory services, including Active Directory domain controllers
- _imaps._tcp / _submission._tcp – mail client autoconfiguration
- _caldavs._tcp / _carddavs._tcp – calendar and contact sync
What do the SRV fields mean?
Each SRV answer is a small routing instruction. Read the fields together, not in isolation, because priority and weight only make sense in relation to the other records under the same name.
- Client Needs the SIP service of example.com
- SRV query _sip._tcp.example.com
- Pick target Lowest priority, weighted choice
- A/AAAA Resolve target and connect to port
- Priority: which target is preferred – the lower the number, the earlier clients try it.
- Weight: load balancing between targets that share the same priority – higher weight, larger share.
- Port: the TCP or UDP port the client should connect to on the target.
- Target: the hostname that provides the service; a single dot means the service is explicitly not available.
How priority and weight decide which server is used
A client collects all SRV answers, takes the group with the lowest priority and picks one target from that group at random, proportionally to the weights. With weights of 60 and 40, roughly six out of ten connections go to the first server and four to the second. Only when every target in the lowest priority group fails does the client move on to the next priority.
This makes SRV a simple tool for redundancy: give your main servers priority 10 and a standby server priority 20. A weight of 0 is allowed and means the target is chosen rarely when other targets of the same priority have a positive weight.
When should you check an SRV record?
SRV problems rarely show themselves as DNS errors. Users see a phone that will not register, a chat client that cannot find its server or an integration stuck at “connecting”. The SRV lookup separates DNS causes from application causes quickly.
- When a service connection fails – VoIP, chat, directory or calendar sync.
- After changing a service provider or moving an endpoint to a new host.
- When verifying routing rules (priority and weight) for redundancy and failover.
- When troubleshooting DNS propagation and caching after an edit.
SRV targets need A or AAAA records
The target in an SRV record must be a hostname that resolves to an IP address through its own A or AAAA record. The SRV specification does not allow the target to be an alias, so pointing it at a CNAME is not a valid setup, even if some clients tolerate it. An IP address in the target field is not allowed either.
After checking the SRV record, look up the A and AAAA records of each target. A target that does not resolve is one of the most common reasons why a seemingly correct SRV record still leads nowhere.
My SRV record exists – why is the service not working?
When the record is there but the service still fails, work through the usual suspects in order. First confirm that you queried the exact _service._proto name the client expects. Then check that the target resolves, that the port matches what the server actually listens on and that a firewall does not block it.
Finally, some clients simply do not use SRV for every service and expect a fixed hostname instead. In that case the record is correct but ignored, and the client configuration needs the server name directly.
Adding SRV records at your DNS provider
DNS panels ask for SRV data in different ways. Some want the complete name _sip._tcp in the host field, others offer separate inputs for service, protocol and name, and a few append the domain automatically – so entering the full _sip._tcp.example.com can produce a duplicated name such as _sip._tcp.example.com.example.com. Run a lookup right after saving to see the name exactly as it was published.
Copy priority, weight, port and target from your provider’s setup guide without rounding or swapping fields; some panels order the inputs differently from the record format. Enter the target as a plain hostname, without a protocol or a path. If a guide lists several records under the same name, publish all of them – leaving out the backup target removes the redundancy the provider planned for.
Before moving a service, lower the TTL of the SRV records a day in advance. Clients then pick up the new target within minutes of the switch instead of following a cached answer for hours.
SRV records and monitordefend
monitordefend is a hosted website monitoring service. It does not monitor SRV or other DNS records, ports or VoIP services; use this free lookup when you set up or change a service. For your website, monitordefend checks the homepage every five minutes and emails you when it goes down.
Frequently asked questions
What SRV name should I look up?
Look up the full name in the form _service._proto.domain, for example _ldap._tcp.example.com. A lookup of the bare domain usually returns no SRV records even when they are configured.
What does an SRV record contain?
It contains a priority, a weight, a port and a target hostname. Together they tell clients which host and port to use for a service and how to choose between several servers.
How do priority and weight affect which server is used?
Clients try the lowest priority first. Among records with the same priority, the weight distributes connections proportionally between the targets.
Does the SRV target need an A or AAAA record?
Yes. The target must resolve to an IP address through an A or AAAA record, otherwise clients cannot connect.
Can an SRV record point to a CNAME?
Not validly. The SRV specification expects the target to have address records directly rather than being an alias.
What are SRV records commonly used for?
Service discovery in protocols such as SIP, XMPP and LDAP, for Active Directory, Microsoft 365 and mail or calendar autoconfiguration, and in some games and SaaS integrations.
My SRV record exists – why is the service not working?
Usually the wrong _service._proto name was queried, the target has no A or AAAA record, the port is wrong, or the client does not use SRV for that service.
How do I check SRV records on the command line?
Run “dig _sip._tcp.example.com SRV” on macOS or Linux, or “nslookup -type=srv _sip._tcp.example.com” on Windows.