SRV Record Setup Guide Configure Service Records the Right Way

SRV records are one of the most misunderstood and incorrectly configured record types in DNS. Unlike an A record or CNAME where you just point a name at an address, an SRV record encodes a service name, protocol, priority, weight, port, and target hostname all in a single entry. Get any one of those fields wrong and your SIP phones stay silent, your XMPP server refuses connections, or your Microsoft Teams direct routing falls flat. This guide cuts through the confusion and walks you through exactly what each field means, how to build valid SRV records, and how to verify that what you published is actually working.

What Is an SRV Record and Why Does It Exist

The SRV record was defined in RFC 2782 to solve a specific problem: how does a client find out which host and port to connect to for a given service without hard-coding that information into the application? Before SRV records, every application had to ship with default port assumptions, or administrators had to manually configure each client. SRV records move that discovery logic into DNS, where it belongs.

A DNS client that understands SRV simply queries _servicename._protocol.domain and gets back one or more answers, each containing a priority, weight, port, and target. The client connects to the highest-priority target on the specified port. If that host is down, it fails over to the next one. It is a built-in load balancing and failover mechanism without any additional infrastructure.

Common use cases include:

• SIP / VoIP — _sip._tcp and _sip._udp for IP phone provisioning
• XMPP / Jabber — _xmpp-client._tcp and _xmpp-server._tcp
• Microsoft Teams Direct Routing and Skype for Business — multiple SRV entries under _sipfederationtls._tcp
• Minecraft — _minecraft._tcp so players can use a domain name without specifying a port
• IMAP / SMTP autodiscovery — _imaps._tcp and _submission._tcp for email client autoconfiguration
• Kerberos — _kerberos._tcp used by Active Directory environments

Understanding the SRV Record Format

Before touching any control panel, you need to understand the four data fields every SRV record carries. A fully written-out SRV record looks like this in zone file syntax:

Breaking that down field by field:

• Name — _sip._tcp.example.com. The underscore prefix on the service and protocol is mandatory. The service name and protocol must match exactly what the application expects. Common protocols are _tcp and _udp.
• TTL — 3600 seconds (one hour). How long resolvers cache this record. Use a lower TTL like 300 during testing.
• Priority — 10. Lower numbers are preferred. Identical to MX record priority logic. Range is 0–65535.
• Weight — 20. Used to distribute load among records with the same priority. Higher weight means more traffic. If you only have one server, set this to 0.
• Port — 5060. The TCP or UDP port the service is actually listening on. This is the most commonly wrong field.
• Target — sip1.example.com.. Must be a fully qualified domain name (FQDN) pointing to an A or AAAA record. You cannot use an IP address here, and you cannot use a CNAME. The trailing dot is required in raw zone syntax but most DNS control panels add it automatically.

Step-by-Step SRV Record Creation in Popular DNS Providers

Cloudflare

1. Log into your Cloudflare dashboard and select your domain.
2. Click DNS in the left sidebar, then Add record.
3. Set Type to SRV.
4. In the Name field enter the service and protocol portion only, for example _sip._tcp. Cloudflare appends the domain automatically.
5. Set Priority, Weight, and Port in their respective fields.
6. Set Target to the FQDN of your server, for example sip1.example.com.
7. Leave TTL on Auto or set it to 300 while testing.
8. Click Save.

Note: Cloudflare does not proxy SRV records. The orange cloud is irrelevant here. The record is always DNS-only regardless of proxy status.

cPanel / WHM (most shared hosting)

1. Log into cPanel and open Zone Editor.
2. Click Manage next to your domain.
3. Click Add Record and choose Add SRV Record.
4. Fill in Priority, Weight, Port, and Service (e.g. _sip), Protocol (e.g. _tcp), and Target.
5. Click Add Record.

GoDaddy

1. Go to My Products, find your domain, click DNS.
2. Scroll to the records table and click Add.
3. Select SRV from the type dropdown.
4. In the Name field enter the full label: _sip._tcp.
5. Set Priority, Weight, Port, and Target.
6. Click Save.

Route 53 (AWS)

1. Open the Route 53 console and select your hosted zone.
2. Click Create record.
3. Set Record name to _sip._tcp (leave the domain suffix as-is).
4. Set Record type to SRV.
5. In the Value field, enter the record data in the format priority weight port target on a single line, for example: 10 20 5060 sip1.example.com.
6. Click Create records.

Route 53 accepts multiple SRV values in the same record set. Just put each one on a new line in the Value box.

Real-World SRV Record Examples

SIP for VoIP (Hosted PBX)

XMPP Client and Server Federation

Microsoft Teams Direct Routing

Minecraft Server

Weighted Load Balancing Across Two Servers

Both records share priority 10, so the client load-balances between them. With weight 70 vs 30, approximately 70 percent of connections go to sip1. If you bump sip2's priority to 20, it becomes a pure standby failover.

How to Verify Your SRV Record Is Working

Never trust the control panel confirmation screen alone. Always query the live DNS to confirm the record is published and syntactically correct. Use our DNS Lookup tool and select record type SRV, or run these commands from your own terminal.

On Linux or macOS:

On Windows:

A healthy response looks like this:

The ADDITIONAL SECTION containing the A record for the target is called glue. Some resolvers include it, some do not. Either way, the client will do a follow-up A record query for the target hostname. Make sure that A record exists and resolves correctly.

Common SRV Record Mistakes and How to Fix Them

Using an IP Address as the Target

The SRV spec explicitly prohibits IP addresses in the target field. If you put 203.0.113.50 as the target, most clients will silently fail or throw a malformed record error. The target must be a hostname. Create an A record for that hostname first, then reference it in the SRV target.

Missing Underscores

A record named sip.tcp.example.com is not the same as _sip._tcp.example.com. Applications query the underscore-prefixed version. Without underscores, the record will never be found. Some DNS control panels auto-prefix the underscore, others require you to type it manually.

Wrong Protocol

SIP uses both UDP and TCP, and some clients prefer one over the other. If your phones register on UDP but you only published a _sip._tcp record, UDP clients will fall through to default port behavior. Publish both _tcp and _udp variants unless you know with certainty your clients use only one.

Target Points to a CNAME

RFC 2782 states the target of an SRV record must not be an alias. If pbx.example.com is actually a CNAME pointing somewhere else, many resolvers and SIP stacks will reject it. Always point SRV targets at hostnames backed by A or AAAA records directly.

TTL Too High During Rollout

If you are migrating a phone system or changing port assignments, a high TTL means clients will use the old values for hours. Set TTL to 300 (5 minutes) at least 24 hours before making changes, make the change, then raise TTL again once everything is confirmed working.

Firewall Blocking the Port in the SRV Record

The SRV record tells clients which port to use, but if a firewall is blocking that port, the connection still fails. Verify with:

If the connection is refused or times out, the DNS is fine but the network path is broken. Check both the server-side firewall and any upstream ACLs.

Priority and Weight Strategy

A single SRV record with weight 0 is perfectly valid and by far the most common setup. Weight only matters when you have multiple records at the same priority level. The RFC specifies a weighted random selection algorithm: assign each same-priority record a slot proportional to its weight, then pick randomly. So weights of 70 and 30 mean roughly 70/30 distribution, not strict round-robin.

For a primary and failover architecture use different priorities:

• Primary server: Priority 10, Weight 0
• Failover server: Priority 20, Weight 0

Clients must try all records at priority 10 before moving to priority 20. This is deterministic failover, not load balancing.

Preventing Future Problems

• Document every SRV record in a change log or internal wiki entry with the application it serves, the port, and the reason for the configuration.
• Set up monitoring on the actual port listed in the SRV record, not just HTTP/HTTPS. Tools like Nagios, Zabbix, or UptimeRobot can check arbitrary TCP ports.
• When decommissioning a service, remove the SRV record at the same time you shut down the server. Orphaned SRV records pointing at dead hosts cause confusing failures months later.
• Test SRV lookup from inside and outside your network. Split-horizon DNS setups can serve different answers internally and externally, causing hard-to-diagnose issues for remote users.

SRV records are not complicated once you internalize the format. The most important habit is to verify with a live DNS query after every change, confirm the target A record resolves, and confirm the port is reachable before signing off on the configuration.