Send, receive, and shield emails with PostScale. One API, EU-hosted. PostScale

    DNS SRV Record Explained — Service Discovery via DNS

    Learn how DNS SRV records enable service discovery by advertising the host, port, priority, and weight for network services. Covers SIP, XMPP, LDAP, Active Directory, CalDAV, and more with dig examples.

    What you'll learn

    • Understand the SRV record naming convention (_service._proto.name) and its four data fields
    • Configure SRV records for common protocols including SIP, XMPP, LDAP, and CalDAV
    • Use priority and weight fields to implement failover and weighted load balancing
    • Query and troubleshoot SRV records using dig and common diagnostic techniques

    Most DNS record types map a name to an address. A records give you an IPv4 address. AAAA records give you an IPv6 address. MX records add a priority layer for mail delivery. But none of them tell a client which port to connect to, or how to distribute load across a pool of servers.

    That is the job of the SRV record. Defined in RFC 2782, the SRV record provides a general-purpose mechanism for service discovery via DNS. It advertises the hostname, port number, priority, and weight for any service — allowing clients to locate, fail over, and load-balance services automatically.


    The SRV Record Format

    An SRV record follows a strict naming convention and carries four data fields:

    _service._protocol.name.    TTL    IN    SRV    priority weight port target

    Here is a concrete example:

    _sip._tcp.example.com.    3600    IN    SRV    10 60 5060 sip1.example.com.

    This tells any SIP client: "To reach the SIP service over TCP at example.com, connect to sip1.example.com on port 5060. This server has priority 10 and weight 60."

    The Name: _service._protocol.domain

    The record name is built from three parts:

    PartDescriptionExamples
    _serviceIANA-registered service name, prefixed with underscore_sip, _xmpp-client, _ldap, _minecraft
    _protocolTransport protocol, prefixed with underscore_tcp, _udp, _tls
    nameThe domain name the service belongs toexample.com.

    The underscore prefix is required by the specification. It prevents collisions with regular hostnames — you would never have a host called _sip.

    The Four Data Fields

    FieldDescriptionRange
    PriorityLower values are preferred. Clients try servers in ascending priority order.0 – 65535
    WeightRelative load-balancing weight among servers with the same priority. Higher values get more traffic.0 – 65535
    PortThe TCP or UDP port the service listens on.1 – 65535
    TargetThe hostname of the server providing the service. Must have an A or AAAA record.FQDN

    Tip: The target field must be a hostname, not an IP address. The client performs a separate A/AAAA lookup on the target to get the actual IP. The target should never be a CNAME — point it directly to a name with A/AAAA records.


    How Service Discovery Works

    When a client application needs to connect to a service, it performs the following steps:

    1. Construct the SRV query name — e.g., _xmpp-client._tcp.example.com
    2. Query DNS for SRV records at that name
    3. Sort by priority — group servers by priority value, lowest first
    4. Select within priority group by weight — within each group, pick a server randomly but biased by weight (a server with weight 70 is chosen ~7x more often than one with weight 10)
    5. Connect to the chosen target on the specified port
    6. Fall back — if the connection fails, try the next server in the priority/weight order

    This is the same conceptual model as MX record priority for email, but extended with port numbers and weighted load balancing.


    Priority: Failover Between Tiers

    Priority controls the order in which servers are tried. Lower values mean higher preference:

    _sip._tcp.example.com.  3600  IN  SRV  10 50 5060 primary.example.com.
    _sip._tcp.example.com.  3600  IN  SRV  20 50 5060 secondary.example.com.
    _sip._tcp.example.com.  3600  IN  SRV  30 50 5060 tertiary.example.com.

    Clients connect to primary.example.com first (priority 10). If it is unreachable, they try secondary.example.com (priority 20), then tertiary.example.com (priority 30).

    Tip: Leave gaps between priority values (10, 20, 30 rather than 1, 2, 3). This makes it easy to insert new servers between tiers later without renumbering everything. This is the same advice that applies to MX record priorities.


    Weight: Load Balancing Within a Tier

    Among servers with the same priority, the weight field controls traffic distribution:

    _sip._tcp.example.com.  3600  IN  SRV  10 70 5060 server1.example.com.
    _sip._tcp.example.com.  3600  IN  SRV  10 20 5060 server2.example.com.
    _sip._tcp.example.com.  3600  IN  SRV  10 10 5060 server3.example.com.

    All three servers are priority 10, so they are all equally preferred. But server1 (weight 70) receives approximately 70% of connections, server2 (weight 20) gets ~20%, and server3 (weight 10) gets ~10%.

    A weight of 0 has special meaning: servers with weight 0 should only be chosen when no other servers in that priority group are available. This is useful for "last resort" backends.

    _sip._tcp.example.com.  3600  IN  SRV  10 60 5060 fast.example.com.
    _sip._tcp.example.com.  3600  IN  SRV  10 0  5060 slow-backup.example.com.

    Use Cases

    SIP / VoIP

    SIP is one of the original drivers behind SRV records. VoIP clients query SRV to discover where to register and where to send calls:

    _sip._tcp.example.com.    3600  IN  SRV  10 100 5060 sip1.example.com.
    _sip._tcp.example.com.    3600  IN  SRV  20 100 5060 sip2.example.com.
    _sip._udp.example.com.    3600  IN  SRV  10 100 5060 sip1.example.com.
    _sips._tcp.example.com.   3600  IN  SRV  10 100 5061 sip1.example.com.

    Note the separate entries for TCP, UDP, and TLS (_sips) transports.

    XMPP / Jabber

    XMPP uses two service names — one for client connections and one for server-to-server federation:

    _xmpp-client._tcp.example.com.  3600  IN  SRV  5 0 5222 xmpp.example.com.
    _xmpp-server._tcp.example.com.  3600  IN  SRV  5 0 5269 xmpp.example.com.

    Clients connect on port 5222; other XMPP servers federate on port 5269.

    LDAP and Active Directory

    Microsoft Active Directory relies heavily on SRV records for domain controller discovery. Workstations and member servers find domain controllers, global catalog servers, and Kerberos KDCs by querying SRV names under _msdcs:

    _ldap._tcp.example.com.              3600  IN  SRV  0 100 389 dc1.example.com.
    _ldap._tcp.dc._msdcs.example.com.    3600  IN  SRV  0 100 389 dc1.example.com.
    _kerberos._tcp.example.com.          3600  IN  SRV  0 100 88  dc1.example.com.
    _gc._tcp.example.com.                3600  IN  SRV  0 100 3268 dc1.example.com.

    If Active Directory DNS is broken, domain joins, group policy processing, and user logins will all fail. These SRV records are critical infrastructure.

    CalDAV / CardDAV

    Calendar and contact clients (Apple Calendar, Thunderbird, DAVx5) use SRV to auto-discover the right server:

    _caldavs._tcp.example.com.   3600  IN  SRV  0 1 443  cal.example.com.
    _carddavs._tcp.example.com.  3600  IN  SRV  0 1 443  contacts.example.com.

    The s suffix in _caldavs and _carddavs indicates TLS-secured connections on port 443.

    Game Servers (Minecraft)

    Minecraft clients check SRV records so players can connect with just a domain name instead of needing to know the port:

    _minecraft._tcp.example.com.  3600  IN  SRV  0 5 25565 mc.example.com.

    A player types example.com in the Minecraft client, which queries _minecraft._tcp.example.com, discovers port 25565 on mc.example.com, and connects.

    Matrix / Element Chat

    The Matrix federation protocol uses SRV for server-to-server communication:

    _matrix._tcp.example.com.  3600  IN  SRV  10 0 8448 matrix.example.com.

    Microsoft 365 / Teams

    Skype for Business and Teams federation relies on SRV records:

    _sipfederationtls._tcp.example.com.  3600  IN  SRV  100 1 5061 sipfed.online.lync.com.
    _sip._tls.example.com.               3600  IN  SRV  100 1 443  sipdir.online.lync.com.

    Disabling a Service via SRV

    To explicitly declare that a service is not available at a domain, set the target to a single dot (.) with port 0:

    _sip._tcp.example.com.  3600  IN  SRV  0 0 0 .

    This is preferable to simply having no SRV record, because it gives a definitive "this service does not exist here" answer instead of leaving clients to time out.


    Querying SRV Records with dig

    Basic SRV Query

    dig SRV _sip._tcp.example.com

    This returns the full DNS response including the authority and additional sections (which often contain the A/AAAA records for the targets).

    Short Output

    dig SRV _sip._tcp.example.com +short

    Returns just the data fields:

    10 60 5060 sip1.example.com.
    20 40 5060 sip2.example.com.

    Query the Authoritative Server

    To bypass resolver caches and check what your nameserver is actually serving:

    dig SRV _xmpp-client._tcp.example.com @ns1.dnscale.eu +short

    Check Multiple Service Types

    # Check SIP, XMPP, and LDAP for a domain
    for svc in _sip._tcp _xmpp-client._tcp _ldap._tcp; do
      echo "=== $svc ==="
      dig SRV $svc.example.com +short
    done

    Verify the Target Resolves

    After confirming the SRV record exists, verify the target hostname has an address record:

    dig SRV _sip._tcp.example.com +short
    # Output: 10 60 5060 sip1.example.com.
     
    dig A sip1.example.com +short
    # Output: 198.51.100.10

    If the target has no A or AAAA record, clients will discover the service but fail to connect.


    Common Mistakes

    1. Missing A/AAAA Records for the Target

    The SRV target must resolve to an IP address. If sip1.example.com has no A or AAAA record, the SRV record is useless. Always create the target's address records before or alongside the SRV record.

    2. Using an IP Address as the Target

    SRV targets must be hostnames, not IP addresses. This is invalid:

    # Wrong
    _sip._tcp.example.com.  SRV  10 60 5060 198.51.100.10

    Create an A record for a hostname and point the SRV target at it instead.

    3. Pointing the Target at a CNAME

    While technically possible, pointing an SRV target at a CNAME adds an extra DNS lookup and can cause problems with some resolvers. Use a direct A/AAAA name.

    4. Forgetting the Underscore Prefix

    The service and protocol components must start with an underscore. sip._tcp is wrong; _sip._tcp is correct.

    5. Wrong Protocol

    SIP can run over both TCP and UDP. If you only create _sip._tcp records but your phones use UDP, they will not discover the server. Check your application's documentation for which protocol it queries.

    6. Not Checking Application Support

    Not all applications implement SRV lookup. Some older software hardcodes hostnames and ports. Always test with your specific client software to confirm it actually queries SRV records.


    SRV vs. HTTPS and SVCB Records

    The newer HTTPS and SVCB record types address some limitations of SRV for web traffic:

    FeatureSRVHTTPS / SVCB
    Port advertisementYesYes
    PriorityYesYes (via SvcPriority)
    WeightYesNo (not directly)
    ALPN negotiationNoYes (h2, h3)
    ECH supportNoYes
    IP hintsNoYes
    Browser supportNoYes (HTTPS type)
    General service discoveryYesYes (SVCB type)

    When to use which:

    • Use SRV for protocols that were designed around it: SIP, XMPP, LDAP, CalDAV, Minecraft, Matrix, Active Directory
    • Use HTTPS for web services that benefit from ALPN, HTTP/3, and ECH
    • Use SVCB as the general-purpose successor to SRV for new protocol designs

    SRV is not going away — it is deeply embedded in dozens of protocols — but new protocol specifications increasingly adopt SVCB instead.


    Real-World Configuration Example

    Here is a complete SRV setup for a company running self-hosted XMPP, SIP, and CalDAV services, with failover and load balancing:

    ; XMPP — client and server federation
    _xmpp-client._tcp.example.com.  3600  IN  SRV  10 70 5222 xmpp1.example.com.
    _xmpp-client._tcp.example.com.  3600  IN  SRV  10 30 5222 xmpp2.example.com.
    _xmpp-server._tcp.example.com.  3600  IN  SRV  10 50 5269 xmpp1.example.com.
    _xmpp-server._tcp.example.com.  3600  IN  SRV  20 50 5269 xmpp2.example.com.
     
    ; SIP — primary with hot standby
    _sip._tcp.example.com.           3600  IN  SRV  10 100 5060 sip1.example.com.
    _sip._tcp.example.com.           3600  IN  SRV  20 100 5060 sip2.example.com.
    _sip._udp.example.com.           3600  IN  SRV  10 100 5060 sip1.example.com.
     
    ; CalDAV — single server
    _caldavs._tcp.example.com.       3600  IN  SRV  0 1 443  cal.example.com.
    _carddavs._tcp.example.com.      3600  IN  SRV  0 1 443  cal.example.com.
     
    ; Supporting A records for all targets
    xmpp1.example.com.   3600  IN  A  198.51.100.10
    xmpp2.example.com.   3600  IN  A  198.51.100.11
    sip1.example.com.    3600  IN  A  198.51.100.20
    sip2.example.com.    3600  IN  A  198.51.100.21
    cal.example.com.     3600  IN  A  198.51.100.30

    XMPP client connections are load-balanced 70/30 between two servers at the same priority. XMPP federation has a primary (xmpp1, priority 10) and failover (xmpp2, priority 20). SIP has a hot standby. CalDAV runs on a single server.


    • A — IPv4 address for the SRV target
    • AAAA — IPv6 address for the SRV target
    • MX — similar priority-based discovery, but specific to email
    • CNAME — canonical name alias (avoid as SRV target)
    • HTTPS — modern service binding for web traffic
    • SVCB — general-purpose service binding, the modern successor to SRV
    • TXT — often used alongside SRV for service configuration metadata
    • NS — delegates DNS zones to nameservers

    For a complete overview of all record types, see the DNS Record Types guide.


    Conclusion

    SRV records solve a fundamental problem in networked computing: how does a client find the right server, on the right port, with the right fallback behavior, without hardcoding anything? By encoding priority, weight, port, and target into a single DNS record with a standardized naming convention, SRV enables automatic service discovery for SIP, XMPP, LDAP, Active Directory, CalDAV, game servers, and dozens of other protocols. While newer record types like HTTPS and SVCB are emerging for web-centric use cases, SRV remains the standard for the broad ecosystem of non-HTTP services. Use dig SRV to inspect your records, ensure every target has a corresponding A or AAAA record, and leave gaps between priority values for future flexibility.

    Ready to manage your DNS with confidence?

    DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

    Start free