What Is an SRV Record, and When Do You Need One?

Most DNS records answer a simple question: what's the IP address for this name? But some applications need more than an address. A VoIP phone needs to know which server handles calls for your domain and which port to use. A chat client needs to find your XMPP server. A Windows workstation needs to find a domain controller. A game client needs to know that your Minecraft server runs on a non-standard port. The SRV record was designed for exactly this: it publishes the location of a service, not just a host.

This article explains what an SRV record is, how its fields work, how clients choose between multiple SRV records, the services that rely on them, and how to create and test them. If you're new to record types in general, start with what DNS records are.

What Is an SRV Record?

An SRV record (service record), defined in RFC 2782, maps a combination of a service name, a transport protocol, and a domain to a hostname and port number. It also includes priority and weight values that let you publish multiple servers for failover and load distribution.

Where an A record says "this name is at this IP address," an SRV record says "the SIP service over TCP for example.com is provided by sip1.example.com on port 5060."

That distinction matters because it lets you:

1. Run services on non-standard ports without making users type a port number.
2. Move a service to a different host without changing client configuration.
3. Publish multiple servers with explicit preferences for failover and load balancing.

SRV Record Format

An SRV record has a special naming pattern and four data fields. In a zone file:

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

A real example:

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

Breaking that down:

Part	Example	Meaning
Service	_sip	The symbolic service name, prefixed with an underscore.
Protocol	_tcp	The transport protocol, usually _tcp or _udp.
Name	example.com.	The domain the service belongs to.
TTL	3600	How long resolvers can cache the record.
Priority	10	Lower values are tried first.
Weight	60	Relative share of traffic among records with the same priority.
Port	5060	The TCP or UDP port the service listens on.
Target	sip1.example.com.	The hostname providing the service.

The underscores in the service and protocol labels keep these names from colliding with regular hostnames. Service names are registered with IANA in the Service Name and Transport Protocol Port Number Registry, though applications sometimes use their own.

Rules for the target

• The target must be a hostname with its own A or AAAA record. It can't be an IP address.
• The target must not be a CNAME. RFC 2782 explicitly forbids it. Some clients tolerate it, but many don't.
• A target of . (a single dot) means "this service is decidedly not available at this domain." Clients should stop looking rather than falling back to defaults.

How Clients Use Priority and Weight

Priority and weight are what make SRV records more than a simple pointer. Here's a domain with three SIP servers:

_sip._tcp.example.com.  3600  IN  SRV  10  70  5060  sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10  30  5060  sip2.example.com.
_sip._tcp.example.com.  3600  IN  SRV  20  0   5060  sip-backup.example.com.

sip1.example.com.        3600  IN  A    203.0.113.21
sip2.example.com.        3600  IN  A    203.0.113.22
sip-backup.example.com.  3600  IN  A    198.51.100.50

A compliant client does the following:

1. Group by priority, lowest first. sip1 and sip2 share priority 10, so they're tried before sip-backup at priority 20.
2. Within a priority group, pick by weight. sip1 should get about 70% of connections and sip2 about 30%.
3. Fall back on failure. If both priority-10 servers are unreachable, the client moves to sip-backup.

Weight 0 has a special meaning: it should be selected only rarely when other records in the same priority have positive weights. A record with weight 0 alone in its priority group is simply used.

Here's what that selection algorithm looks like in Python using dnspython:

import random
from itertools import groupby

import dns.resolver


def ordered_srv_targets(name):
    answers = dns.resolver.resolve(name, "SRV")
    records = sorted(answers, key=lambda r: r.priority)
    ordered = []

    for _, group in groupby(records, key=lambda r: r.priority):
        pool = list(group)
        while pool:
            total = sum(r.weight for r in pool)
            if total == 0:
                choice = random.choice(pool)
            else:
                pick = random.uniform(0, total)
                running = 0
                for r in pool:
                    running += r.weight
                    if running >= pick:
                        choice = r
                        break
            ordered.append((str(choice.target).rstrip("."), choice.port))
            pool.remove(choice)

    return ordered


for host, port in ordered_srv_targets("_sip._tcp.example.com"):
    print(f"{host}:{port}")

This returns every target in the order a client should try them: priority groups in ascending order, with a weighted random shuffle inside each group. Install the library with pip install dnspython.

This is also why SRV records are a lightweight form of DNS load balancing — except that the client, not the DNS server, does the balancing.

Common Services That Use SRV Records

SRV records are only useful if the client software looks them up. These are the most common cases where it does:

Service	SRV name	Typical port
SIP (VoIP) over TCP / UDP / TLS	_sip._tcp, _sip._udp, _sips._tcp	5060 / 5061
XMPP client connections	_xmpp-client._tcp	5222
XMPP server-to-server	_xmpp-server._tcp	5269
Active Directory domain controllers	_ldap._tcp.dc._msdcs	389
Kerberos	_kerberos._tcp, _kerberos._udp	88
Email client autoconfiguration (RFC 6186)	_submission._tcp, _imaps._tcp	587 / 993
Outlook Autodiscover fallback	_autodiscover._tcp	443
CalDAV / CardDAV	_caldavs._tcp, _carddavs._tcp	443
Minecraft Java Edition	_minecraft._tcp	25565

Active Directory

Active Directory relies heavily on SRV records. When a Windows machine joins a domain or a user logs in, it looks up records like _ldap._tcp.dc._msdcs.corp.example.com to find domain controllers. These records are registered automatically by domain controllers in AD-integrated DNS. If they're missing or wrong, logins and domain joins fail — one of the most common causes of AD trouble.

VoIP and unified communications

SIP phones and softphones use SRV records to find the registrar and proxy for a domain, so a user can enter alice@example.com rather than a server address and port. Hosted VoIP providers typically give you a set of SRV records to add.

Game servers

Minecraft Java Edition is the best-known example. If your server runs on port 25570 instead of the default 25565, an SRV record lets players connect to play.example.com without typing the port:

_minecraft._tcp.play.example.com.  3600  IN  SRV  0  5  25570  mc1.example.com.
mc1.example.com.                   3600  IN  A    203.0.113.40

The client looks up the SRV record for play.example.com, finds mc1.example.com on port 25570, and connects there.

What doesn't use SRV

Web browsers don't use SRV records for ordinary HTTP and HTTPS. You can't use an SRV record to make example.com load a website on port 8080. For web traffic, the newer HTTPS and SVCB records fill a similar role. Email delivery between servers uses MX records, not SRV.

How to Create an SRV Record

Most DNS dashboards present SRV records as a form with separate fields. A typical setup:

1. Service: _sip (some dashboards want it without the underscore)
2. Protocol: _tcp
3. Name: @ for the root domain, or a subdomain
4. Priority: 10
5. Weight: 60
6. Port: 5060
7. Target: sip1.example.com

Dashboards differ in whether they want the underscores, and whether the name field should include the service and protocol labels. After saving, always confirm the resulting name with dig.

On AWS Route 53, the value is a single string with the four fields separated by spaces:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_sip._tcp.example.com",
        "Type": "SRV",
        "TTL": 3600,
        "ResourceRecords": [
          { "Value": "10 70 5060 sip1.example.com" },
          { "Value": "10 30 5060 sip2.example.com" }
        ]
      }
    }]
  }'

Both SRV records live in one record set, since they share the same name and type.

How to Look Up SRV Records

With dig:

dig SRV _sip._tcp.example.com +short

Output lists priority, weight, port, and target on each line:

10 70 5060 sip1.example.com.
10 30 5060 sip2.example.com.
20 0 5060 sip-backup.example.com.

With nslookup:

nslookup -type=SRV _sip._tcp.example.com

With PowerShell, which is especially handy for checking Active Directory records:

Resolve-DnsName -Name _ldap._tcp.dc._msdcs.corp.example.com -Type SRV

From Node.js:

import { resolveSrv } from "node:dns/promises";

const records = await resolveSrv("_xmpp-client._tcp.example.com");
records.sort((a, b) => a.priority - b.priority);
for (const r of records) {
  console.log(
    `${r.name}:${r.port} (priority ${r.priority}, weight ${r.weight})`,
  );
}

resolveSrv() returns objects with priority, weight, port, and name fields, which you can sort and use to connect.

Common Mistakes and Best Practices

1. Pointing the target at a CNAME. Use a hostname with its own A or AAAA record. CNAME targets violate the spec and break some clients.
2. Using an IP address as the target. SRV targets must be hostnames.
3. Getting the name wrong. Forgetting underscores, swapping the order of service and protocol, or doubling the domain name are the most common errors. Verify with dig SRV.
4. Expecting browsers to honor SRV. They don't for HTTP. Use a reverse proxy, a standard port, or HTTPS records.
5. Forgetting the target's address records. An SRV record pointing to a hostname with no A or AAAA record is useless.
6. Leaving SRV records behind after migrating. Old SRV records pointing to decommissioned servers send clients to dead hosts. Review them whenever you change providers — see how to transfer DNS management to another provider.
7. Misreading weight 0. It means "use rarely," not "disabled." To disable a server, remove its record.

---

SRV Record FAQ

Conclusion

The SRV record solves a problem the A record can't: telling a client not just where a server is, but which port a service runs on and which of several servers to prefer. Priority gives you ordered failover, weight gives you proportional load sharing, and the underscore naming scheme keeps service records cleanly separated from the rest of your zone.

The catch is that SRV only helps when the client software looks for it. Active Directory, SIP, XMPP, email autoconfiguration, and some games do; web browsers don't. Before adding SRV records, confirm the application you're supporting actually uses them, then point them at real hostnames with address records, and verify the result with dig SRV before you tell anyone it's live.

Here are some useful references for going deeper on SRV records:

1. RFC 2782: A DNS RR for specifying the location of services (DNS SRV) — the specification for SRV records and the priority/weight algorithm.
2. RFC 6186: Use of SRV Records for Locating Email Submission/Access Services — how email clients use SRV to find IMAP, POP, and submission servers.
3. IANA: Service Name and Transport Protocol Port Number Registry — the official list of registered service names and ports.
4. Cloudflare Learning Center: What is a DNS SRV record? — a short explainer with examples.
5. Microsoft Learn: Resolve-DnsName — reference for the PowerShell cmdlet used to query SRV and other record types on Windows.