What an SRV record is and why it exists

A plain A record only returns an IP address. It knows nothing about ports and cannot spread load across several servers of the same service. The SRV record (Service record, RFC 2782) fills this gap: it stores the server address, the port, and priority parameters together for a specific service — SIP telephony, XMPP chat, an LDAP directory, or Matrix federation.

Thanks to SRV, a client application never needs the user to type in a server port and host manually: the domain alone is enough, and the application queries the SRV record to get everything it needs to connect.

SRV record syntax: priority, weight, port, target

The record name always follows the pattern _service._protocol.domain, and the value has four fields:

_sip._tcp.example.com.    3600 IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com.    3600 IN SRV 20  0 5060 sip2.example.com.
_matrix._tcp.example.com. 3600 IN SRV 10  0 8448 matrix.example.com.

Priority (the first number) — the lower it is, the more important the server: the client tries lower-priority records first. Weight (the second number) spreads load between records of the same priority proportionally to its value. The third field is the service port, the fourth is the full target host name, which must resolve to an A or AAAA record, not a CNAME.

SRV for SIP telephony: a configuration example

To connect an IP-PBX or softphone over SIP, it is enough to point it at the domain with no server address or port — the client finds them on its own through the _sip._tcp and _sip._udp records. This scheme is convenient when a SIP trunk provider changes servers: only the zone gets updated, while phone settings stay untouched.

Other record types that usually live next to SRV in the same zone are covered in the article on A, CNAME, MX, TXT, and NS records.

SRV for a Matrix server: federation without a non-standard port

Matrix federation expects port 8448 by default. The _matrix._tcp.example.com record lets you keep the server on any other port hidden behind a reverse proxy. Starting with Matrix protocol version 1.x, the recommended delegation method is a .well-known/matrix/server file on the main domain, and the SRV record remains a fallback mechanism for servers that do not yet check well-known.

To protect the federation port with a TLS certificate, it also helps to bind the certificate to the DNS zone — see the article on TLSA and DANE.

How to check an SRV record with dig

Querying a specific SRV record looks like this:

dig SRV _matrix._tcp.example.com +short
dig SRV _sip._tcp.example.com +short

The output should show priority, weight, port, and the target name. If there is no answer, either the record was never published, or it lives in a different zone after subdomain delegation — worth checking with the methods from the article on checking a DNS zone with dig.

Common mistakes when configuring SRV

The SRV target points to a CNAME instead of an A or AAAA record — per RFC 2782 this is invalid, and some clients will reject such a record outright.
A missing trailing dot after the domain name in the target field inside the zone file, which changes the meaning of the record.
The port in the SRV record does not match the port actually opened in the firewall.
The record's TTL is too high, so switching a SIP trunk server drags on for hours — set a low TTL in advance, as described in the article on TTL configuration.

Summary: a checklist for SRV records

Before publishing an SRV record, check: the name follows the pattern _service._protocol.domain, the target host resolves to A/AAAA, the port matches the service's open port, priority and weight are set deliberately, and the record itself is visible through dig from an external resolver. This set of checks saves you from long troubleshooting sessions over why a softphone or Matrix client cannot find the server.

SRV DNS Records: Connecting SIP, XMPP, and Matrix