How to set up an SRV record?
An SRV record with us in the DNS can, for example, be as follows:
Example:
| Record Name | RR Type | Target | Priority | TTL |
|---|---|---|---|---|
| _sip._tls | SRV | 1 443 sipdir.online.lync.com | 100 | 3600 |
The record name thus results from the service and the protocol.
The target results from the weighting, the port, and the server, with spaces separated. In the target, there are therefore exactly two spaces.
What an SRV record is and when you need it
An SRV record (Service record) is a DNS record type used to describe how clients should locate a service for a domain. Unlike an A or CNAME record, an SRV record does not just point to a host, it also specifies the port and includes routing behavior such as priority and weight. This allows applications to discover the correct server endpoint automatically without hardcoding addresses.
SRV records are commonly required for services such as VoIP/SIP, XMPP chat, certain Microsoft services, and other applications that support service discovery via DNS. You typically create an SRV record when a vendor or service provider gives you a specific SRV definition and instructs you to publish it in your domain’s DNS zone. The SRV record tells client software: “For this service and protocol, connect to this host and port, and use these values for failover and load distribution.”
If your service provider does not explicitly require an SRV record, do not add one “just in case.” This is especially important for services like hosted email, where standard delivery depends on MX records and adding unnecessary SRV records can confuse client configuration or autodiscovery. Incorrect SRV records can cause clients to connect to the wrong host or fail to connect at all.
SRV record fields explained (priority, weight, port, target)
SRV records contain multiple fields that control how clients choose the correct destination server. Understanding these fields helps you enter the values correctly and interpret vendor instructions.
Priority: Determines failover order. A lower number is preferred. Clients try the lowest priority first and fall back to higher priorities only if the preferred target is unavailable.
Weight: Determines load distribution among records with the same priority. Higher weight usually means a higher probability of being chosen, but behavior can vary by client implementation.
Port: The TCP/UDP port the service listens on. This is critical, an incorrect port will break connectivity even if the target host is correct.
Target: The hostname of the server that provides the service (for example, sip.example.tld).
In the hosting.de DNS editor, these fields are typically entered in the SRV record inputs as follows: the record name reflects the service and protocol, and the target field contains the weight, port, and server in a specific format. Always follow your provider’s exact numeric values for priority/weight/port, because minor deviations can change behavior or prevent the client from locating the service.
How to build the record name correctly (service + protocol)
The SRV record name is built from two labels: the service and the protocol. The standard format is:
_service._protocol
Both labels begin with an underscore. The service identifies what is being located (for example _sip), and the protocol identifies how it is reached (for example _tcp, _udp, or sometimes _tls depending on vendor definitions). In the hosting.de example, a SIP-over-TLS record name is shown as _sip._tls.
Practical rules:
Use exactly the service/protocol labels provided by your vendor. Do not “normalize” them.
Keep the underscores. Omitting them commonly results in the record being ignored by clients.
Enter only the relative name part expected by the DNS zone editor. Do not duplicate the domain name unless the UI explicitly requires it.
If multiple SRV records exist for the same service, ensure each one uses the correct name and that priorities/weights are set intentionally. Incorrect naming is one of the most common reasons SRV “looks correct” in the panel but the application still cannot find the service.
Validation and troubleshooting: confirming SRV resolution and fixing common failures
After saving an SRV record, validate it before assuming the service is correctly configured. SRV issues typically come from formatting mistakes, wrong hostnames, wrong ports, or DNS caching.
Validation workflow:
Confirm the record appears in the DNS zone exactly as intended (name, priority, and the target value format).
Query SRV resolution using a DNS tool (for example, dig or nslookup) from more than one network if possible, because caches can differ.
Verify the target hostname itself resolves to the correct IP address (A/AAAA records must exist for the target).
Common failure causes:
Incorrect spacing in the target field: some editors require a precise format (for example, strict spacing between fields). If the panel specifies two spaces, follow it exactly.
Wrong service/protocol label: _tcp vs _udp (or vendor-specific _tls) must match what the application expects.
Wrong port: even with correct DNS, clients will fail if the service is not listening on that port.
DNS propagation/TTL: changes may take time to appear globally; avoid repeated edits during the propagation window.
If the service still fails after DNS resolves correctly, the next step is to confirm the service is actually reachable on the target host and port (network/firewall/application configuration). DNS only tells clients where to go; it cannot make the service respond.