SRV Records Explained: How to Add Them in cPanel

Someone on your team asks you to "just add an SRV record" for Microsoft Teams, a SIP phone system, or a Minecraft server, and the request stalls the moment you open the Zone Editor. SRV records don't look like anything else in your DNS zone - underscores in the name, four numeric fields, no obvious "value" box. Here's what each field actually means and how to add one in cPanel without guessing.

What an SRV record actually does

An SRV (Service) record tells a client application where to find a specific service on your domain - which host to connect to, and on which port. Unlike an A record, which just maps a name to an IP, an SRV record maps a service to a host, a port, and a priority for failover.

You'll run into SRV records most often for:

• Microsoft Teams and Skype for Business federation (_sip._tls, _sipfederationtls._tcp)
• SIP/VoIP phone systems (_sip._udp, _sip._tcp)
• XMPP/Jabber chat servers (_xmpp-client._tcp, _xmpp-server._tcp)
• Matrix homeservers (_matrix._tcp)
• Minecraft servers running on a non-default port (_minecraft._tcp)
• Autodiscover for some hosted email platforms

If a vendor's setup docs say "add this SRV record to your DNS," it's almost always one of the above.

Anatomy of an SRV record

Every SRV record has the same five parts, and cPanel's Zone Editor asks for them individually instead of one text value:

Put together, a full SRV entry reads as: _sip._tcp.example.com. 3600 IN SRV 10 5 5060 sipserver.example.com.

Adding an SRV record in cPanel's Zone Editor

1. Log in to cPanel and open Zone Editor under the Domains section.
2. Click Manage next to the domain the record belongs to.
3. Click Add Record and choose SRV Record from the type dropdown.
4. In the Name field, enter just the service and protocol part - cPanel appends the domain automatically. For Teams federation on example.com, you'd enter _sipfederationtls._tcp, not the full domain.
5. Fill in Priority, Weight, and Port exactly as given by the vendor - don't swap priority and weight, they behave differently.
6. In Target, enter the full hostname the service runs on, with a trailing dot if cPanel's field allows it (e.g. sipdir.online.lync.com.). Most panels add the dot automatically on save - check the record after saving to confirm.
7. Save, then verify with dig SRV _sipfederationtls._tcp.example.com from a terminal.

Common real-world SRV entries

Symptom: record added, but the service still can't find your domain

You saved the SRV record, waited a day, and the client still fails to connect or federate. In practice this comes down to one of five things.

Cause 1: Missing or wrong underscores

The underscore before the service and protocol isn't decoration - it's part of the DNS spec for SRV records, meant to avoid collisions with real hostnames. sip._tcp is a different (and useless) name from _sip._tcp. Copy the exact string the vendor gave you.

Cause 2: Priority and weight swapped

It's an easy typo because both are small integers. A swapped priority and weight usually won't break a single-record setup, but it silently breaks failover order the moment a second target is added later. Match the vendor's documented values field-for-field.

Cause 3: Target host has no working A/AAAA record

An SRV record points to a hostname, not an IP - that hostname still needs to resolve. If the target is a third-party service (like Microsoft's sipdir.online.lync.com), that's on their DNS. If it's your own subdomain, confirm it has a valid A record:

dig A sipserver.example.com

Cause 4: DNS hasn't propagated yet

SRV records follow the same TTL and propagation rules as any other record. If the zone previously had no record at that name, some resolvers cache the "no such record" (NXDOMAIN) response for a while. Give it a few hours, and check directly against your nameserver rather than relying on your ISP's cache:

dig @ns1.yourdomain.com SRV _sip._tcp.example.com

Cause 5: A conflicting or duplicate record already exists

If two SRV records exist at the same name with conflicting ports or targets - often left over from a previous provider - clients may pick the wrong one or fail validation entirely. Open Zone Editor, filter by the service name, and remove anything stale before adding the new record.

Prevention

• Keep a plain-text copy of every SRV record you add, with the vendor's source doc linked, so the next person doesn't have to reverse-engineer it from a support ticket.
• Test with dig immediately after saving, not just after propagation - a wrong record shows up as a wrong record instantly, it doesn't need to wait to be wrong.
• Before migrating hosting or DNS providers, export the full zone file (Zone Editor → Export Zone in cPanel) so SRV records aren't the thing that quietly gets missed in the move.
• If a vendor updates their required SRV values (Microsoft has done this before during platform migrations), re-check the record annually rather than assuming a "set and forget" record stays correct forever.

Verifying the record actually works

dig only tells you the record exists and resolves - it doesn't tell you the receiving service accepts what you sent. Once dig comes back clean, close the loop with the application itself: run Microsoft's Remote Connectivity Analyzer for Teams/Skype federation, connect a test SIP softphone for a VoIP setup, or try joining your own Minecraft server from a network outside your office (some routers don't resolve their own public DNS records correctly, which looks identical to a broken SRV record from the inside). If the app-level test fails but dig looks right, the SRV record usually isn't the problem anymore - check the target service's firewall or listening port instead.

One more thing worth checking before you close the ticket: make sure nothing upstream is filtering the record. If the domain sits behind Cloudflare or another proxy, confirm the SRV record itself is set to DNS only (grey cloud) rather than proxied - Cloudflare's proxy only understands HTTP/HTTPS traffic, and a proxied SRV record for SIP or XMPP simply won't route the way the client expects.