---
title: App can't find its server? How to check SRV records with the SRV Record Lookup
description: Mail clients, SIP phones, XMPP chat, Minecraft and Active Directory find their servers through DNS SRV records, and when discovery fails the app just says it can't connect. To check an SRV record, look up the full service name (such as _submission._tcp.example.com) and read the target host, port, priority and weight. Here's how to do it with the free SRV Record Lookup, a real Gmail example, and the dig and nc commands that confirm the port answers.
canonical: https://watchfor.io/blog/how-to-check-srv-records
---

# App can't find its server? How to check SRV records with the SRV Record Lookup

2026-10-04 · WatchFor Team · Guides · guides, dns, networking

Mail clients, SIP phones, XMPP chat, Minecraft and Active Directory find their servers through DNS SRV records, and when discovery fails the app just says it can't connect. To check an SRV record, look up the full service name (such as _submission._tcp.example.com) and read the target host, port, priority and weight. Here's how to do it with the free SRV Record Lookup, a real Gmail example, and the dig and nc commands that confirm the port answers.

To check an SRV record, look up the service name, which always has the form
`_service._protocol.domain` (for example `_submission._tcp.gmail.com`), and
read the answer: the **target** host and **port** the client should connect
to, plus a **priority** and **weight** for choosing between several targets.
If the lookup returns nothing, clients that rely on the record can't discover
the server; if it returns a target and port that don't answer, they find the
server and then fail to connect.

The free [SRV Record Lookup](/srv-record-lookup) shows every SRV record for
a service name, with its TTL, from a real WatchFor location. No signup.

## What this tool answers

*Where does this service say clients should connect?* Reach for it when an
app that discovers its server automatically can't find it: a mail client
setting up an account, a SIP phone or softphone, an XMPP chat client, a
Minecraft server on a custom port, or a machine joining an Active Directory
domain. SRV records exist so that users only type a domain and the client
works out the host and port; when they're missing or wrong, the client has
nothing to go on.

## A real example

### Checking SRV records when a mail client can't find the server

RFC 6186 lets mail clients find the submission (outgoing) and IMAP or POP
(incoming) servers for a domain from SRV records, so a user only types their
address. When that discovery fails, the first question is whether the
records exist and what they say. We checked Gmail's.

In the [SRV Record Lookup](/srv-record-lookup) we typed
`_submission._tcp.gmail.com`, kept the resolver on **Auto** and pressed
**Run lookup**:

![The SRV Record Lookup for _submission._tcp.gmail.com from Europe / Lithuania: NOERROR, 1 record in 30 ms, port 587, priority 5, target smtp.gmail.com., TTL 3600, weight 0](/blog/how-to-check-srv-records-result.webp)

The lookup returned `NOERROR` with **one record** in 30 ms:

| Field | Value | In plain words |
| --- | --- | --- |
| target | smtp.gmail.com. | Connect to this host |
| port | 587 | Message submission with STARTTLS |
| priority | 5 | Only one record, so it doesn't matter here |
| weight | 0 | No load sharing between equal-priority targets |
| ttl | 3600 | Seconds this resolver may cache it |

The same lookup on Gmail's other names (see the command line section) shows
`_imaps._tcp` pointing at `imap.gmail.com:993`, `_pop3s._tcp` at
`pop.gmail.com:995`, and `_imap._tcp` at the special target `.` with port
`0`, which RFC 2782 defines as "this service is decidedly not available
here": Gmail offers IMAP only over TLS, and the record says so explicitly.

**The answer:** Gmail publishes discovery records for submission, IMAPS and
POP3S, and the submission port answers (`nc` connects to
`smtp.gmail.com:587`). For your own domain, a missing record means clients
fall back to guessing or manual setup, and a record pointing at a host or
port that doesn't answer explains a "can't connect" right after a
successful lookup.

## How to read the results

| Field | What it means |
| --- | --- |
| **target** | The host to connect to. It must have its own A/AAAA records and must not be a CNAME (RFC 2782). A lone `.` means the service isn't offered. |
| **port** | The TCP or UDP port on that host. |
| **priority** | Lower is tried first. Clients move to the next priority only if every target at the current one fails. |
| **weight** | Among targets with the same priority, the share of clients each should get. `0` everywhere means no preference. |
| **ttl** | Seconds the record may be cached, or what's left on a cached copy. Resolvers may cap long TTLs: Google's nameserver publishes this record with 86,400. |
| **NOERROR, 0 records** | No SRV record came back. For SRV lookups the tool shows this both when the name has no SRV record and when it doesn't exist at all (`_submissions._tcp.gmail.com`, for example, is NXDOMAIN in dig), so check the service and protocol labels first. |
| **Resolve time** | Green under 50 ms, amber under 200 ms, red above. |

## More ways to use it

- **Microsoft 365 and Teams.** Hybrid and federation setups rely on records
  such as `_sipfederationtls._tcp.example.com`; check them against the
  values your admin center lists.
- **Minecraft on a custom port.** `_minecraft._tcp.play.example.com` lets
  players connect without typing the port; the record must name the port
  the server actually runs on.
- **Active Directory.** Domain controllers are found through records like
  `_ldap._tcp.dc._msdcs.example.com`; a stale entry sends machines to a
  retired DC.
- **XMPP and CalDAV.** `_xmpp-client._tcp`, `_xmpp-server._tcp` and
  `_caldavs._tcp` work the same way: target, port, priority.
- **After moving a service.** Update the target and port, then confirm the
  new target resolves and the port answers with the [port checker](/port-checker).

## Tips and gotchas

- **The name has to be exact.** `_service._proto` comes from the protocol's
  specification: `_submission._tcp`, not `_smtp._tcp`; `_sip._tls` and
  `_sip._udp` are different records. A typo returns nothing.
- **Underscores are part of the name.** Some DNS editors put the service and
  protocol in separate fields; others want `_sip._tcp` in the host field.
  Check the result, not the editor screen.
- **The target can't be an alias.** Pointing an SRV record at a CNAME is not
  allowed by RFC 2782; some clients cope, others fail. Use the host's real
  name.
- **Browsers don't use SRV for websites.** HTTP clients ignore SRV records;
  for web traffic look at A/AAAA or HTTPS records instead.
- **A record that exists isn't a service that works.** Test the target and
  port directly; the SRV record only tells clients where to try.

## Check it from the command line too

```bash
dig +noall +answer SRV _submission._tcp.gmail.com @1.1.1.1
dig +noall +answer SRV _imaps._tcp.gmail.com @1.1.1.1
dig +noall +answer SRV _pop3s._tcp.gmail.com @1.1.1.1
dig +noall +answer SRV _imap._tcp.gmail.com @1.1.1.1
```

```text
_submission._tcp.gmail.com. 86400 IN	SRV	5 0 587 smtp.gmail.com.
_imaps._tcp.gmail.com.	86400	IN	SRV	5 0 993 imap.gmail.com.
_pop3s._tcp.gmail.com.	86400	IN	SRV	20 0 995 pop.gmail.com.
_imap._tcp.gmail.com.	86400	IN	SRV	0 0 0 .
```

dig prints the fields as `priority weight port target`. The last line is
the "not available" record. Then check the advertised port answers:

```bash
nc -vz -w 5 smtp.gmail.com 587
```

```text
Connection to smtp.gmail.com (142.250.147.109) 587 port [tcp/submission] succeeded!
```

## Keep watching it

When an SRV record breaks, users don't see an error page; their clients
quietly stop connecting. A [DNS monitor](/dns-monitoring) accepts a service
name such as `_sip._tcp.example.com` as its target with record type **SRV**,
re-checks it from several locations on a schedule, and with the **Expected
DNS Records** rule (the target host, such as `sip.example.com`) opens an
incident when the record stops pointing there. A
[TCP monitor](/tcp-monitoring) on the target and port covers the service
itself.

## FAQ

**What is an SRV record used for?**
It tells clients which host and port provide a service for a domain, so
users only need to know the domain. Mail clients, SIP, XMPP, Minecraft,
LDAP and Kerberos use it. [DNS record types explained](/blog/dns-record-types-explained)
covers the other common records.

**How do I look up an SRV record?**
Query the full service name, `_service._protocol.domain`, with a DNS tool or
`dig SRV _sip._tcp.example.com`. Querying the bare domain for SRV returns
nothing, because SRV records live under the underscore labels.

**What do priority and weight mean in an SRV record?**
Priority sets the order: clients try the lowest number first and fall back
to higher ones. Weight shares traffic between records with the same
priority, in proportion to their values. The
[DNS records guide](/blog/how-to-check-dns-records) shows how to compare
answers across resolvers.

---

Canonical page: https://watchfor.io/blog/how-to-check-srv-records · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt