DNS Tools
SERVICE DISCOVERY DIAGNOSTICS

SRV Lookup

Check where a service such as SIP, XMPP or a mail submission service is located: which hosts and ports are published, in what order, and whether the targets resolve.

Run SRV records

Either this, or service + protocol + domain below.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What an SRV record is

An SRV record tells a client which host and port provide a named service for a domain, so the port does not need to be fixed or guessed. The record lives at a name made of the service, the transport protocol and the domain, each of the first two prefixed with an underscore, for example _sip._tcp.example.com. The value has four fields: priority, weight, port and target host.

Applications that use SRV include SIP and XMPP, some calendar and contact discovery, directory services and several chat and game systems. Web browsers and most mail clients do not use SRV for ordinary web or mail delivery, so a missing SRV record for HTTP is normal.

Entering the query

The tool accepts either a complete name such as _sip._tcp.example.com, or the three parts: service, protocol (tcp, udp or tls) and domain. Give one form only. The first two labels must start with an underscore, and the tool explains an input error without running a query.

How priority and weight work

Clients try the lowest priority number first. Among records that share the same priority, weight decides how often each is chosen: a record of weight 60 should receive roughly three times the attempts of a weight 20 record. Weight is a load-sharing hint and only applies inside a priority group. A client falls back to the next priority only when all hosts of the better group fail.

How to read the result

  • Records with targets that resolve to public addresses: reported as a pass, with the number of records and targets.
  • Target "." (a single dot): a single record whose target is a lone dot states that the service is deliberately not available at this domain (RFC 2782). That is informational. A dot mixed with real targets contradicts itself and is flagged.
  • Port 0 or out of range: reported as a medium-severity improvement, since a client cannot connect to it.
  • Target without an address: the host named by the record has neither A nor AAAA, so the entry is unusable.
  • Target is a CNAME: RFC 2782 says the target must be a name with address records, not an alias; some clients fail on aliased targets.
  • Target only resolves to non-public addresses: unreachable for clients on the internet.
  • Duplicate records: identical entries listed more than once are noted.
  • NODATA or NXDOMAIN: nothing is published for this service name. A timeout, SERVFAIL or REFUSED says nothing about its existence and is reported as such.

Common SRV problems

  • Wrong label format: missing underscores, or the protocol and service in the wrong order.
  • Target typed without a trailing dot: your DNS panel appends the zone, producing a target that does not exist.
  • Port mismatch: the record names a port the service does not listen on, perhaps after the service moved.
  • Provider-specific names: a service may expect a particular service label, for example _submission._tcp for mail submission or _autodiscover._tcp for some mail clients. Use the exact name the provider documents.
  • Priorities all identical, weights all zero: a legitimate but uninformative combination, which leaves clients to choose among hosts.

How to change SRV records safely

Take the service name, hosts, ports and weights from your service provider's setup instructions. Publish the new target hosts' address records before the SRV that points at them, and keep old hosts running until caches have expired.

Moving traffic gradually is straightforward with SRV: add a new record at the same priority with a small weight, then increase the weight, then retire the old record.

  1. Save the existing SRV records and TTL.
  2. Make sure each new target has an A or AAAA record and listens on the port.
  3. Add or update the SRV record using a trailing dot on the target.
  4. Run this lookup and verify priority, weight, port and target resolution.
  5. Test with a real client that uses SRV discovery.
  6. To roll back, restore the saved set.

What this test does not cover

The tool reads DNS and checks that targets resolve. It does not connect to the port, speak the protocol, check a certificate or confirm that a client implements SRV discovery. Results come from the system resolver and the zone's authoritative servers at one moment, so a record changed a few minutes ago may still be cached elsewhere.

Frequently asked questions

Why do SRV names start with underscores?

The underscore labels mark them as service and protocol names, which keeps them from colliding with ordinary host names.

Does a lower priority mean a higher preference?

Yes. The lowest priority number is tried first, as with MX records. Weight only distributes load among equal priorities.

Can the target be an IP address or a CNAME?

No. The target must be a host name that has address records of its own, not an IP literal and not an alias.

What does a target of a single dot mean?

The service is explicitly not provided at that domain. Clients should not keep trying.

Do browsers use SRV records for websites?

Generally not. Web traffic uses address records and fixed ports, so lacking SRV for HTTP is normal.

Does the tool test that the port is open?

No. It only reads DNS. Use the open port checker for connectivity.

Written by DNS Tools editorial · Last updated 2026-10-09