Most DNS records point a name to an address or another name. The SRV record does something more specific and more powerful: it tells applications not just where a service lives, but which exact port to connect to. If you have set up VoIP calling, a chat protocol, a Microsoft 365 service, or even a game server, you may have encountered an SRV record — and understanding it makes these configurations far less confusing.

This guide explains what an SRV (service) record is, how it differs from familiar records like A, CNAME, and MX, the anatomy of its several components, and the real-world services that rely on it. You will also learn how to add one and the naming conventions that make SRV records look unusual at first glance. It is a specialist record, but a genuinely useful one to understand.

What an SRV record is

An SRV (Service) record is a DNS record that specifies both the hostname and the port number for a particular service running on your domain. Where an A record simply maps a domain to an IP address, an SRV record goes further, telling client applications the exact server target and network port needed to reach a specific application or protocol.

This matters because many services do not run on the standard web ports; they use their own specific ports. An SRV record lets a client automatically discover where a service is and which port to use, rather than requiring users to configure those details manually. It is DNS-based service discovery.

So the SRV record answers a more detailed question than most records. Instead of just “what address is this name?”, it answers “for this specific service and protocol, which server and port should I connect to?” — which is exactly what applications like VoIP clients and chat programs need to know.

How it differs from A, CNAME, and MX

The SRV record’s defining feature is that it includes a port, which no other common record does. An A record maps a name to an IPv4 address; a CNAME aliases one name to another; an MX record routes email to a mail server. None of them specify a port — they assume the standard port for their purpose.

The SRV record adds that missing dimension. It says not only which host handles a service but on which port the service listens, plus the protocol involved. This makes it ideal for services that run on non-standard ports or that benefit from automatic discovery by client software.

In a sense, the SRV record is a more detailed cousin of the MX record. Just as MX tells mail where to go, SRV tells a specific application where and how to connect — but with the added precision of a port and protocol, and for a much wider range of services than just email.

The anatomy of an SRV record

SRV records have more components than most, which is why they look complex at first. Each part has a clear role:

• Service: the symbolic name of the service, written with a leading underscore, such as _sip for VoIP or _xmpp for chat.
• Protocol: the transport protocol the service uses, usually _tcp or _udp.
• Priority: a number setting the preference order for target hosts, where lower means higher priority — just like MX records.
• Weight: a value used for load balancing between servers that share the same priority, distributing connections among them.
• Port: the specific network port on which the service runs — the piece unique to SRV records.
• Target: the actual hostname of the server providing the service (which must resolve via an A/AAAA record).

Together these fields fully describe how to reach a service: which service and protocol, in what order and balance across servers, and on exactly which host and port. Your service provider gives you the precise values to enter, so you do not have to invent them.

Common uses for SRV records

SRV records power a range of real-world services, most of them involving communication or specialised applications. VoIP and internet telephony use them heavily — the _sip service record tells VoIP clients where and how to connect for calls.

Chat and messaging protocols like XMPP use SRV records (_xmpp) so client apps can automatically find the right server and port. Business platforms rely on them too: services such as Microsoft 365 and Teams use SRV records as part of their configuration, which is why setting up those services often involves adding a specific SRV record to your DNS.

Other uses include autodiscover features that let client software configure themselves automatically, and even some game servers (such as Minecraft) that use SRV records to point players to a server on a custom port without them needing to type it. In each case, the SRV record’s port-awareness is what makes the automatic connection possible.

An example, plainly explained

Suppose you are setting up a VoIP service. The provider might give you an SRV record with the service _sip, the protocol _tcp, a priority like 10, a weight like 5, a port such as 5060, and a target hostname pointing to their server. Read together, that record says: “For SIP over TCP, connect to this host on port 5060, at this priority and weight.”

A VoIP client on your domain then looks up that SRV record and automatically knows exactly where and how to establish the connection — no manual entry of server addresses or ports by the user. The record encodes all the connection details in one place.

This is the pattern for every SRV use: the provider supplies the exact service name, protocol, priority, weight, port, and target, and you enter them as an SRV record. The client software does the rest, using those values to connect to the right service on the right port automatically.

How to add an SRV record

Adding an SRV record follows the standard DNS process, with more fields to fill in. Log in to your DNS provider, open the DNS or zone editor, add a new record, and choose the type SRV. You will then see fields for the service, protocol, priority, weight, port, and target.

Enter each value exactly as your service provider specifies. The service and protocol usually start with underscores (like _sip and _tcp), the priority and weight are numbers, the port is the service’s port number, and the target is the provided hostname. Because there are several fields, precision is especially important here.

Save the record and allow time for propagation. Once it is live, client applications for that service can discover and connect automatically. As with MX records, make sure the target is a proper hostname (resolving via an A/AAAA record), not a CNAME, so the service connects reliably.

If a service that relies on an SRV record does not connect, re-check the fields most prone to error: the service and protocol labels (including their leading underscores), the port number, and the target hostname. A single wrong value — an omitted underscore, a transposed port, or a mistyped target — will stop the automatic discovery from working. Because SRV records carry more fields than most, entering them exactly as your provider specifies is the single most important habit for a smooth setup.

FAQs

What is an SRV record?

An SRV (Service) record is a DNS record that specifies both the hostname and the port number for a specific service on a domain. Unlike an A record, which only gives an address, an SRV record tells client applications the exact server and port — plus protocol — needed to reach a service, enabling automatic connection for things like VoIP and chat.

What does an SRV record contain?

An SRV record has several parts: the service (like _sip), the protocol (usually _tcp or _udp), a priority (order preference, lower first), a weight (load balancing among equal priorities), the port (the service’s network port), and the target (the server’s hostname). Together they fully describe how a client should connect to the service.

How is an SRV record different from an A record?

An A record maps a domain to an IPv4 address only — it has no port. An SRV record specifies the hostname and the exact port (and protocol) for a specific service, allowing applications to discover where and how to connect. This makes SRV records suited to services on non-standard ports, while A records simply resolve a name to an address.

What are SRV records used for?

Common uses include VoIP and internet telephony (_sip), chat protocols like XMPP (_xmpp), business platforms such as Microsoft 365 and Teams, autodiscover features that configure client software automatically, and some game servers like Minecraft that run on custom ports. In each case, the SRV record’s port-awareness enables automatic, correct connections.

How do I add an SRV record?

Log in to your DNS provider, open the DNS or zone editor, add a record of type SRV, and fill in the service, protocol, priority, weight, port, and target exactly as your provider specifies. The service and protocol usually start with underscores. Save and allow propagation. Ensure the target is a real hostname, not a CNAME.

What format does an SRV record use?

An SRV record combines a service name and protocol (often written with leading underscores, like _sip._tcp), followed by priority, weight, port, and target hostname values. The underscored naming convention identifies the specific service and transport protocol, which is why SRV records look different from the simpler A or CNAME records at first glance.

The bottom line

An SRV (Service) record is a specialist DNS record that specifies not just where a service lives but exactly which port and protocol to use to reach it — going a step beyond the A record’s simple name-to-address mapping. Its defining feature is that port awareness, which makes it perfect for services that run on non-standard ports or that benefit from automatic discovery by client software. Its several components — service, protocol, priority, weight, port, and target — together encode everything an application needs to connect correctly.

In the real world, SRV records power VoIP and SIP telephony, chat protocols like XMPP, business platforms such as Microsoft 365 and Teams, autodiscover features, and even game servers on custom ports. You rarely invent the values yourself; your service provider supplies the exact service, protocol, priority, weight, port, and target, and you enter them as an SRV record, keeping the target a real hostname rather than a CNAME. Add it accurately, let it propagate, and client applications can find and connect to your service automatically — which is exactly what the SRV record was designed to make possible.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. An SRV record specifies the hostname and port for a specific service (VoIP, chat, MS 365, game servers), with service, protocol, priority, weight, port, and target fields. Enter provider values exactly; target must be a hostname.