SRV Record Lookup
and does that target actually exist?

What an SRV Record Is, and What This Lookup Checks

An SRV record answers a question an A record cannot: which host and which port does this particular service live on? An A record maps a name to an address. A service record maps a service — mail submission, SIP, XMPP, Matrix federation, a game server — to a host, a port, a priority and a weight. That mechanism has a name: service discovery in DNS, and SRV is the record type that carries it. That is why an SRV record lookup is the first thing to run when a client cannot find a server it is supposed to discover automatically.

This SRV record checker does four separate things, and keeps the answers separate because they fail separately:

1. The lookup itself. Did the question get an answer, and what was it — records, a name that does not exist, or a failure? Those three are not the same thing, and most tools show the last two identically.
2. What is published. Every record at that name: priority, weight, port, target and TTL.
3. Whether each target exists. Every target is resolved for A and AAAA records, and checked for being an alias.
4. What a client would actually do. RFC 2782's selection rules applied to your records, so you see the host and port a client really picks, and the share each one gets.

SRV is one record type among many. If you want the whole picture for a domain — A, AAAA, MX, TXT, NS, SOA, CNAME and CAA — our DNS lookup tool returns all of those in one pass, and this page stays out of its way by answering only the SRV question.

If the machinery underneath is what you are after rather than one record, the guide to how DNS resolves a domain name to an address walks through the whole journey from a client's question to an answer. Every record type on this page rides on that same process.

How to Read Your SRV Lookup Result

An SRV record lookup here returns four tiles rather than one verdict, because four different things can be wrong and a single pass-or-fail hides three of them. Read them left to right: the lookup, what is published, the targets, and what a client does with it.

Underneath, each finding carries a label saying where the rule comes from: RFC 2782 for the standard itself, vendor docs for something a service's own documentation specifies, DNS layer for the response code, and TrustMyIP view for our opinion. That last label matters. An opinion dressed as a standard is how checker tools teach people the wrong thing, so ours is labelled as an opinion.

Why it also asks your own nameserver

The records above come from a recursive resolver, which is what a client would use — and which may be holding a copy that is minutes or hours old. So the tool then finds the zone's authoritative nameserver and asks it the same question directly, with recursion switched off, and compares the two answers. If they match, nothing you are reading is stale. If they differ, the resolver is holding an older copy, and the page says so rather than leaving you to guess.

That comparison is only made when the zone's own server really answered as the zone: the authoritative flag set, and a response code that is an answer rather than a failure. A server that refuses the question, or a network that quietly answers DNS on its behalf, proves nothing. A checker that treated either as a disagreement would be inventing a fault, so neither is counted.

The SRV Record Format: Get the Name Right First

More failed lookups come from the name than from the record. RFC 2782 defines the owner name as _Service._Proto.Name, and says the underscores exist "to avoid collisions with DNS labels that occur in nature". So the SRV record format for secure IMAP on example.com is _imaps._tcp.example.com, and the record itself carries four values:

One detail worth knowing before you copy a name off this page: a DNS label may contain any octet, not only letters and digits. RFC 4343 puts it plainly — "the individual octets of which DNS names consist are not limited to valid ASCII character codes. They are 8-bit bytes, and all values are allowed." So this tool prints every name in the escaped form dig and a zone file use. An octet that is not a printable character appears as a back-slash and three digits — \032 for a space, say. The characters that are special in a master file are back-slashed too: a quote, a semicolon, an @, a dollar sign, brackets, and a dot inside a label. A name copied from here pastes straight into a zone file or into dig without changing meaning.

Three things bite people here:

• _tcp and _udp are not interchangeable. A record published under one is completely invisible to a client asking under the other. SIP genuinely uses both, and they mean different transports.
• Some services add labels in the middle. Active Directory does not use _ldap._tcp.example.com but _ldap._tcp.dc._msdcs.example.com to find a domain controller, which is why a domain that looks empty from a plain lookup is full of records when you ask the right name. The service list in the tool builds these for you.
• Case and the trailing dot do not matter; the spelling does. DNS matches names without regard to case, so _IMAPS._TCP is the same name. An internationalised domain is a different matter: it has to be in its punycode form before you build the record name, because that is the only form DNS carries.

Priority and Weight: Which Target Clients Really Use

These two fields are the reason SRV exists, and they do different jobs. Priority is failover. RFC 2782: a client "MUST attempt to contact the target host with the lowest-numbered priority it can reach". Lower number first; higher numbers are the standby that only gets traffic when everything above it is unreachable. Weight is load sharing, and it only counts between records that share a priority. The RFC's words: "Larger weights SHOULD be given a proportionately higher probability of being selected."

That is the same job a load balancer does, one layer up — the guide to virtual IPs and load balancing covers the server-side version. The difference is that with SRV the client does the balancing, which is cheap and has one sharp edge worth knowing about.

Small weights do not split traffic the way the numbers suggest

RFC 2782 does not just say "proportionately". It gives an algorithm: order the records with the weight-0 ones first, add the weights up, then "choose a uniform random number between 0 and the sum computed (inclusive)" and take the first record whose running total reaches it. That inclusive zero has a consequence nobody mentions. Running that algorithm 200,000 times per case while building this tool gave these results:

With weights in the tens or hundreds the difference is a fraction of a percent and you can ignore it. With weights of 1 and 2 the split is not 1:2 at all. Implementations also differ in how they read that sentence — some use a floating-point random number, some exclude the zero — so small weights make the outcome depend on the client rather than on your intent.

Why a Valid SRV Record Still Does Not Work

This is the question behind most searches for a way to check an SRV record, and the honest answer is that the record is usually fine. What is broken is something the record points at. In order of how often it happens:

1. The target does not exist any more

The record is published, the syntax is perfect, and the hostname in it returns NXDOMAIN. Nothing can connect, and nothing looks wrong. On 26 September 2026, while building this tool, we asked 134 well-known domains for 44 service names each. Of the 359 SRV records that came back, 77 pointed at a hostname that does not resolve at all.

One cause accounts for a large share of them. Sixteen of those domains still publish _sip._tls pointing at sipdir.online.lync.com. That was the client-discovery host for Skype for Business Online. Microsoft's own lifecycle page gives its retirement date as 31 July 2021, and adds: "After that time, the service will no longer be accessible." Five years later the records are still there. And the near-identical sipfed.online.lync.com — three letters away — is current — Microsoft still publishes it for Teams federation. Which is exactly why this tool resolves the target instead of guessing from the name.

2. The target resolves, but has no address

The name exists in the zone and has no A and no AAAA record. Often it is a host that was decommissioned and left in DNS, or a name that only exists on an internal view of the zone, so it works from the office and not from anywhere else.

3. The target is a CNAME

RFC 2782 forbids it, most clients do it anyway, and that is the trap: it works until something strict refuses to follow the alias. Point the record at a name with its own address record.

4. The port is wrong, or zero

Choosing the port is the whole point of an SRV record, so an unusual port is not an error — but a port the service is not listening on is. Whether anything answers there is a different question, and our port scanner is the tool for it: this page checks DNS, not the socket.

5. The lookup failed rather than answered

A SERVFAIL is not "no record". It usually means the zone is broken or its DNSSEC signatures do not validate, in which case validating resolvers refuse to answer anything about the domain — our DNSSEC checker shows where that chain breaks.

What the Record Should Look Like, Service by Service

Every name below is taken from the document that defines it, and the tool's service list builds them for you. Where a name comes from a vendor rather than a standard, that is said; where no first-party source exists, that is said too.

Three notes worth having before you publish one. The Matrix specification marks _matrix._tcp deprecated in favour of _matrix-fed._tcp, and says administrators are "encouraged to use .well-known over any form of SRV records". A Minecraft SRV record is the one entry here with no first-party specification we could find — it is a convention documented by hosting providers, and it works, but it is not a standard. And SIP is the biggest real-world user of SRV by a wide margin — 152 of the 359 records in our survey were SIP-family — which is why setting up voice, as our guide to how VoIP works describes, nearly always involves publishing one. RFC 3263 also expects a NAPTR lookup before the SRV lookup when the URI names no transport.

The mail entries are part of a bigger picture: autoconfiguration records tell a client where to connect, while SPF, DKIM, DMARC and MTA-STS decide whether your mail is accepted. Our email health check grades that side of it in one pass.

What This SRV Record Test Cannot Tell You

An SRV record lookup proves that a client can find your server. It does not prove much more than that, and these four limits are stated plainly, because a checker that hides them is how people end up trusting the wrong answer.

It cannot tell you the service is running. Whether anything accepts a connection on the port the record names is a different layer, and a different tool. A record can be perfect while the daemon behind it is stopped.

It sees the public internet only. Plenty of SRV targets resolve inside a company network and nowhere else. This page will report such a target as having no address, which is true from outside and misleading from inside — if that is your situation, the record is doing exactly what you designed it to do.

It cannot tell you what one specific client does. RFC 3263 has SIP clients try NAPTR first. The Matrix specification puts a .well-known lookup ahead of the SRV record. Microsoft states that a missing Autodiscover record "should only be considered an error if you intended to configure your environment" to use SRV discovery at all. This tool answers the DNS question; the client's order of preference is its own.

It is one view at one moment. Records are cached along the way, so a change you made minutes ago may not be visible everywhere yet. This page asks the zone's own nameserver as well as a resolver and tells you when the two disagree — but how long a stale copy lasts anywhere else is a TTL question, and our DNS propagation checker is built for it.

SRV Record Questions People Actually Ask