SRV Record Lookup

Find Service (SRV) records specifying the location (hostname and port) of servers for specific services.

About SRV Records & Formatting

A Service (SRV) record points to the hostname and port of a specific service hosting application. They are widely used by services like SIP, XMPP, LDAP, and Microsoft Active Directory/Office 365.

Required Format: _service._protocol.domain.com
Example: _sip._tcp.example.com or _autodiscover._tcp.example.com

Fields: SRV records contain a Priority (lower is preferred), Weight (used to load balance records with the same priority), Port (the TCP/UDP port), and Target (the canonical hostname of the machine providing the service).

Our SRV Record Lookup queries service location records for any domain, returning the target host, port, priority and weight for services such as SIP, XMPP, Microsoft 365 autodiscover, LDAP and Minecraft. Use it to verify service discovery is correctly published.

What is an SRV Record?

An SRV (Service) record tells clients where a specific service runs — both the hostname and the port number. It is the only standard DNS record type that carries a port, which is what makes protocol-level service discovery possible.

SRV records use a distinctive naming pattern: _service._protocol.domain. For example _sip._tcp.example.com locates a SIP server, and _xmpp-client._tcp.example.com locates an XMPP chat server. The leading underscores prevent collisions with ordinary hostnames.

Each record carries four values: priority, weight, port and target. Priority works like MX preference — lower is tried first. Weight distributes load between records that share the same priority.

Names both the host and the port for a specific service
Uses the _service._protocol.domain naming convention
Carries priority and weight for failover and load balancing
Defined in RFC 2782
Used by SIP, XMPP, LDAP, Kerberos, Microsoft 365 and many game servers

Why SRV Records Matter

Where SRV records are used, they are the only way clients find the service at all. A VoIP handset, a chat client or an Outlook autodiscover request does not guess at hostnames — it queries DNS for the SRV record and connects to whatever it finds. A missing record means the service is simply undiscoverable, even though the server is running perfectly.

They also expose infrastructure. Because the naming convention is standardised, anyone can enumerate which services a domain runs by querying a known list of service names — a standard step in reconnaissance.

Clients cannot locate SIP, XMPP or Kerberos services without them
Priority and weight give true failover and load distribution in DNS
Microsoft 365 and Teams depend on specific SRV records
A wrong port value fails silently and is hard to diagnose
Standardised names let attackers enumerate your service inventory

How This SRV Record Lookup Works

The tool queries DNS for SRV records at the service name you supply and decodes all four fields.

Validates the service name input against format and SSRF safety checks
Queries DNS for records of type SRV at the supplied name
Parses the priority, weight, port and target of each record
Sorts the results by priority and then by weight
Resolves each target hostname to confirm it points somewhere real

How to Use the SRV Record Lookup

Enter the full service name, for example _sip._tcp.example.com
Remember the underscores — they are part of the name, not decoration
Run the lookup to query live DNS
Review the target host and port for each record returned
Confirm each target hostname resolves to a valid address

Understanding Your SRV Record Results

Each SRV record packs four values. Here is what each one controls:

Field / Value	Meaning
`Priority`	Which record clients try first. The lowest number wins, exactly like MX preference. Use a higher number for backup servers.
`Weight`	Relative share of traffic among records that share a priority. A record with weight 20 receives roughly twice the connections of one with weight 10. Set to 0 when there is only one record at that priority.
`Port`	The TCP or UDP port the service listens on. This is the only DNS record type that carries a port, and a wrong value causes silent connection failures.
`Target`	The hostname running the service. It must have its own A or AAAA record. A single dot as the target means the service is explicitly unavailable at this domain.
`Service name`	The _service._protocol prefix identifies what the record is for. Common examples are _sip._tcp, _xmpp-client._tcp, _ldap._tcp and _autodiscover._tcp.

Common Problems & How to Fix Them

The most common cause is a missing underscore or a misspelled service name. The full name must be exactly _service._protocol.domain.

Check your service provider documentation for the precise name and protocol. For Microsoft 365 autodiscover, for example, the record is _autodiscover._tcp.yourdomain.com with target autodiscover.outlook.com and port 443.

The SRV record names a host with no A or AAAA record, so clients have nowhere to connect.

Verify the target hostname is spelled correctly and has its own address record. SRV targets must be hostnames — a raw IP address in the target field is invalid.

The record resolves and the host is reachable, but connections are refused or time out. A wrong port is invisible in DNS diagnostics because the record itself looks perfectly valid.

Confirm the port against the service documentation: 5060 or 5061 for SIP, 5222 for XMPP client connections, 389 or 636 for LDAP, 443 for Microsoft autodiscover.

With identical priority and weight, clients distribute connections evenly and treat every server as equal. That is correct for a true load-balanced pool, but wrong when one server is a standby.

Give the primary a lower priority number, such as 10, and the backup a higher one, such as 20. Backups then receive traffic only when the primary is unreachable.

Best Practices

Use the exact _service._protocol.domain format, underscores included
Always point the target at a hostname with its own A or AAAA record
Give primary servers a lower priority number than backups
Use weight to split load only between records at the same priority
Set weight to 0 when a priority level has a single record
Publish a target of "." to declare explicitly that a service is unavailable
Verify the port against the service documentation, not from memory

Security Recommendations

Remember SRV records are publicly enumerable and advertise exactly which services you run
Do not publish SRV records for internal-only services in public DNS — use split-horizon DNS instead
Avoid target hostnames that reveal internal naming schemes or server roles
Confirm services named in SRV records are themselves hardened, since the record is effectively an invitation to connect
Enable DNSSEC so SRV answers cannot be forged to redirect clients to an attacker-controlled host
Remove SRV records for decommissioned services, since a dangling target is a takeover opportunity

Frequently Asked Questions

An SRV record specifies the hostname and port where a particular service runs. It is the only standard DNS record type that includes a port number, which is what allows clients to discover services automatically. It is defined in RFC 2782.

The underscore prefix distinguishes service labels from ordinary hostnames and prevents collisions, since underscores are not valid in normal hostnames. The format is _service._protocol.domain, for example _sip._tcp.example.com.

Priority determines the order in which records are tried — the lowest number first, like MX preference. Weight only applies among records that share the same priority, distributing traffic proportionally. Priority is for failover, weight is for load balancing.

SIP and VoIP, XMPP chat, LDAP and Active Directory, Kerberos, CalDAV and CardDAV, Microsoft 365 autodiscover and Teams federation, and many game servers including Minecraft. Your provider documentation will give the exact names required.

No. The target must be a hostname that has its own A or AAAA record. Placing a raw IP address in the target field makes the record invalid and clients will fail to connect.

A target of "." explicitly declares that the service is not available at this domain. It is a positive statement of absence, which lets clients fail fast instead of falling back to guessing hostnames.

No. Websites use A, AAAA and CNAME records, and email uses MX records. SRV records are only needed for protocols that specify them, such as SIP, XMPP, LDAP and Microsoft autodiscover.