An SRV record says which server handles a particular service for a domain, and on which port. It is how a client discovers where to connect without anyone typing a hostname.
You will meet it when setting up mail clients that autodiscover, chat and voice services, and game servers, and the format is unusual enough that it is worth getting right the first time.
How it differs from the records you know
An A record answers "where is this name". An MX record answers "who handles mail". An SRV record answers "who handles this specific service, over this protocol, and on which port".
The port is the distinguishing part. No other record type carries one, which is why SRV is the only way to point a client at a service that does not run where its protocol expects.
The name is three parts
This is where most mistakes happen, because the structure is encoded in the record name rather than in separate fields.
_service._protocol.domain
For example _sip._tls.example.com, or _minecraft._tcp.example.com.
The underscores are required, not stylistic. The service name is defined by whatever you are configuring (you do not invent it) and the protocol is almost always _tcp or _udp.
Get any part wrong and the record is valid DNS that nothing will ever look up.
The value is four fields
In the record's data:
Priority, lower is preferred. Clients try the lowest priority first and only fall back to higher numbers if it fails.
Weight: how to distribute among records at the same priority. Two records at priority 10 with weights 70 and 30 split traffic roughly seven to three.
Port. The port on the target.
Target. The hostname to connect to.
cPanel's Zone Editor gives these as separate fields, which is easier than the raw format. Elsewhere you may have to enter them as one space-separated string in that order.
The target must be a hostname
The rule that catches everyone.
The target has to be a name with an A or AAAA record. It cannot be an IP address, and it cannot be a CNAME.
If you want to point at a specific machine, create an A record for it first, then point the SRV record at that name. Putting an IP directly in the target produces a record that looks correct and never resolves.
Also use the fully qualified name. A bare hostname may be interpreted relative to the zone, which produces a target like mail.example.com.example.com.
Priority and weight in practice
Use priority for failover: a primary server at 10 and a backup at 20 means clients use the primary and fall to the backup only when it does not answer.
Use weight for load sharing between servers that are equally acceptable.
The common mistake is setting different priorities for servers you intended to share load. Different priorities never share. The higher number is a fallback and receives nothing while the lower one works.
Where you will actually need one
Mail client autodiscovery. Some clients look for SRV records to find the mail server automatically, so users do not type server names. This is the most common reason a hosting customer encounters them. Configuring email in Outlook deals with the manual settings that work regardless.
Chat and voice services. Federated protocols use SRV records to find each other, and the service names are specified by the protocol.
Game servers. Several use SRV records so players type a domain in place of a domain and port.
Service directories in larger networks, where clients locate a service without configuration.
Adding one in cPanel
Open the Zone Editor, choose Add Record, and select SRV. It is under the additional record types instead of the common ones.
Enter the full underscored name, then the four values. Confirm the target already resolves before saving; a target with no A record is the most common cause of a record that exists and does not work. Using the Zone Editor explains the interface.
Checking it
dig SRV _sip._tls.example.com +short
You should see the four values and the target. Nothing returned means the name is wrong. A missing underscore, the wrong protocol, or a typo in the service name.
Then verify the target itself resolves:
dig A mail.example.com +short
Both have to succeed. A perfectly formed SRV record pointing at a name that does not resolve fails in a way that looks like the SRV record is wrong, and hours get spent on the wrong half. The DNS troubleshooting guide sets out separating them.
Propagation applies as usual
An SRV record is cached like any other, so a change is not immediate and a mistake is not instantly fixed by correcting it.
Lower the TTL before making changes you expect to iterate on, and raise it once the record is settled. For the timing, see understanding DNS propagation.
Check the record answers before configuring the client
Service records are queried in a specific form and a small mistake in the name produces silence rather than an error. Query it exactly as the client will, including the underscores and the protocol part, and confirm the target host resolves as well. A record pointing at a name with no address is the same as no record from the client's point of view, and the failure appears in the application rather than in DNS. Read the priority and weight too, since a record that works and always selects the wrong target is usually those values rather than the hostname.