If you've ever tried to hook up a VoIP phone system, get Microsoft Teams federation working, or point a Minecraft server to a friendlier hostname, you've probably run into a record type that doesn't get nearly as much attention as A or CNAME: the SRV record. Most cPanel users never touch one in their life. Then one day a vendor's setup guide says "add this SRV record" and the Zone Editor screen suddenly has five fields instead of the usual two, and none of them look familiar.
This one's short and practical: what SRV records actually do, why the app on the other end keeps saying it can't find the service, and how to add the record correctly in cPanel without guessing at the syntax.
What an SRV Record Actually Does
A normal A or CNAME record just says "this hostname points to this server." An SRV (Service) record goes a step further — it tells a client application which host and port to connect to for a specific service, and lets you set priority and weight so you can load-balance or fail over between multiple servers.
That's why VoIP providers, XMPP/chat platforms, Microsoft 365/Teams, and game servers rely on them: the client software is coded to look up an SRV record automatically before it even asks you for a server address. If the record is missing or wrong, the app just fails silently or throws a generic "service not found" error — it never tells you it was expecting DNS to hand it a hostname and port.
Symptom: "Service Not Found" or Federation Fails
You'll usually see one of these:
- A VoIP desk phone or softphone can't register, or drops calls intermittently because it's trying the wrong port.
- Microsoft Teams/Skype for Business federation check fails with "we couldn't verify your domain's SRV records."
- A Minecraft server works fine on
play.example.com:25577but players typing justplay.example.comget "connection refused." - An XMPP chat client can connect to some contacts but times out on others.
In every case, the underlying cause is the same: the client did a DNS lookup for a record like _sip._tcp.example.com and either got nothing back, or got a record pointing at the wrong host, port, or priority.
Cause: SRV Syntax Is Unforgiving
SRV records have a specific naming pattern most people get wrong on the first try: _service._protocol.domain. The underscores aren't optional decoration — they're part of the spec, and a lot of DNS editors will silently save a record with the wrong format without warning you it won't resolve the way the vendor's software expects.
The other common mistake is not understanding that an SRV record still needs a valid A or CNAME record for its target host — the SRV record points at a hostname, and that hostname then needs to resolve to an IP on its own. Skip that step and the SRV lookup succeeds but the actual connection still fails.
Fix: Adding an SRV Record in cPanel's Zone Editor
Here's the process end to end:
- Log in to cPanel and open Domains → Zone Editor.
- Click Manage next to the domain you're adding the record to.
- Click Add Record and choose SRV Record from the type list.
- Fill in the fields your vendor gave you. A typical SIP example looks like this:
| Field | Example value | What it means |
|---|---|---|
| Name | _sip._tcp | Service and protocol — cPanel appends your domain automatically |
| Priority | 10 | Lower number = tried first when multiple SRV records exist |
| Weight | 60 | Splits traffic between records that share the same priority |
| Port | 5060 | The TCP/UDP port the service actually listens on |
| Target | sipserver.example.com | Hostname that must have its own A record — never a bare IP |
Click Add Record to save it, then give it a few minutes before testing — SRV records follow the same propagation rules as any other DNS record.
To confirm it actually saved and resolves correctly, run this from your own terminal (not from inside cPanel):
dig SRV _sip._tcp.example.comYou should see an ANSWER section listing the priority, weight, port, and target exactly as you entered them. If the ANSWER section is empty, the record either hasn't propagated yet or was saved with the wrong name format — go back and double-check the underscores.
Common SRV Record Mistakes That Break Things
- Forgetting the underscores —
sip.tcpinstead of_sip._tcplooks almost identical but won't be found by any client doing a proper SRV lookup. - Pointing the target at an IP address — SRV targets must be hostnames. If you only have an IP, create an A record first, then point the SRV target at that hostname.
- Wrong protocol suffix — mixing up
_tcpand_udpfor services that specifically require one or the other (SIP, for example, often needs both, as two separate records). - Testing too soon — checking the record five minutes after saving it, on a device that already cached the old (missing) answer. Flush local DNS cache or test from a different network before assuming it's still broken.
Prevention: Document What You Add and Why
SRV records are usually added once, for a single vendor integration, and then forgotten about for years. When that vendor's setup docs disappear or the person who configured it moves on, nobody remembers why _xmpp-client._tcp exists in the zone file — and it either gets left alone forever or accidentally deleted during a "DNS cleanup."
Keep a short note (a shared doc, a comment in your infra wiki, whatever your team actually reads) listing every non-obvious DNS record you add and which service depends on it. It takes two minutes and saves someone a very confusing afternoon later. If you're moving hosts or migrating DNS providers, export your full zone file first — SRV records are exactly the kind of entry that gets missed in a manual re-creation.
Frequently Asked Questions
Can I add an SRV record without cPanel access, directly at my registrar?
Yes, if your domain's nameservers point to your registrar's DNS instead of SkyServer's. If SkyServer hosts your DNS (the usual setup), the Zone Editor in cPanel is the right place — adding it at the registrar would have no effect since that DNS isn't being queried.
Why does my SRV record show up in Zone Editor but the vendor still says it can't find it?
Almost always a propagation delay or a caching resolver holding the old (empty) answer. Query a public resolver directly with dig SRV _service._proto.example.com @8.8.8.8 to bypass your local cache and confirm what the internet actually sees.
Do I need one SRV record per protocol, or can one record cover TCP and UDP?
One record per protocol. If a service needs both TCP and UDP (SIP is the classic example), you add two separate SRV records — one with _tcp and one with _udp — even if they point at the same target and port.
What priority and weight values should I use if the vendor doesn't specify?
Priority 10 and weight 10 work fine for a single-server setup — the actual numbers only matter once you have more than one SRV record for the same service and want to control which one gets tried first or how traffic splits between them.
Will adding an SRV record affect my existing website or email?
No. SRV records are only queried by software specifically looking for that named service — they don't interact with your A, MX, or CNAME records and won't change how your site or mail behaves.
