Can an SRV record's target point to a CNAME?

No. RFC 2782 is explicit: the Target must be a hostname that has an A or AAAA record, and it must not be a CNAME alias. This trips people up constantly because CNAMEs work fine as targets for most other purposes, so it feels like it should work here too. It doesn't, and the failure is quiet — the SRV lookup returns your record, the client follows the Target, gets a CNAME instead of an address, and depending on how strict the client is, either does an extra resolution step it wasn't supposed to or gives up. Some DNS providers will even reject an SRV record whose Target is a name they know is a CNAME. Point the Target at a name with a real A/AAAA record. If you need the flexibility a CNAME would give you, put the CNAME's final address on the target name directly.

What does a Target of just a single dot ( . ) mean?

It means the service is decidedly not available at this domain. RFC 2782 defines a Target of "." as an explicit, machine-readable 'this service does not run here' — which is different from simply having no SRV record at all. A missing record leaves a client to guess or fall back; a "." target tells it authoritatively to stop looking. You'd use it to shut off a service for a whole domain without depending on every client to interpret an absence the way you intended.

Why isn't my SRV record doing anything for my website?

Because web browsers don't use SRV records for HTTP. SRV is a protocol-level mechanism, and a service has to be written to look one up before it means anything. Mail clients doing Autodiscover, SIP and XMPP clients, Active Directory domain members, Minecraft's Java client, and similar protocol-aware software query SRV. A browser typing in a URL does not — it goes straight to A/AAAA (and, increasingly, HTTPS/SVCB records). If you added an SRV record hoping to redirect or load-balance a normal website, that's the wrong tool; the record is valid but nothing is asking for it.

SRV Record Setup: Priority, Weight, Port, Target

What an SRV Record Actually Does

Most DNS records answer “where is this name?” An A record hands back an IPv4 address; an MX record hands back a mail host. An SRV record answers a sharper question: “where — including which port, in what priority, at what share of the load — does this specific service live for this domain?” That extra detail is the whole point. An A record can tell a client the address of example.com, but it can’t tell an XMPP client that chat runs on host xmpp1.example.com at port 5222, with a backup on xmpp2 it should only use if the first is down. SRV can.

Defined in RFC 2782 (February 2000, replacing the experimental RFC 2052), the record packs four values into one answer. Get all four right and protocol-aware clients — mail Autodiscover, SIP, XMPP, Active Directory, Minecraft, and more — find your service without anyone hardcoding a hostname and port. Get one wrong and the failure is usually silent, which is why this is worth setting up carefully the first time.

The Name Is Half the Record

Before the four values, there’s the owner name, and it has a rigid shape:

_service._proto.name.

Both _service and _proto start with an underscore — deliberately, so these labels can never collide with a real hostname (no ordinary host is named _sip). _proto is almost always _tcp or _udp. So a SIP-over-TLS record for example.com is owned by _sip._tls.example.com, and an XMPP client-connection record is owned by _xmpp-client._tcp.example.com.

Miss an underscore, use the wrong protocol label, or attach the record to the bare domain instead of the _service._proto prefix, and clients querying the correct name get NXDOMAIN. The record can be perfectly formed and still invisible because it’s sitting at the wrong name.

The Four Fields

After IN SRV, in order:

_sip._tls.example.com. 3600 IN SRV 10 60 443 sipdir.example.com.
                                    │  │   │   └─ Target
                                    │  │   └───── Port
                                    │  └───────── Weight
                                    └──────────── Priority

Priority works exactly like MX preference: lower is tried first. A client must contact the reachable target with the lowest priority number before touching anything higher. This is your primary/backup control — put the main host at 10, the failover at 20, and clients only fall to 20 when everything at 10 is unreachable.
Weight distributes load among targets that share the same priority. Two hosts both at priority 10 with weights 60 and 40 get roughly 60% and 40% of clients. Weight is meaningless across different priorities — it only breaks ties. (Per RFC 2782, records with weight 0 still get a small, defined chance of selection; they aren’t switched off.)
Port is the actual TCP/UDP port the service listens on. This is SRV’s superpower — you’re not locked into a protocol’s default port. Note it’s a separate field: the port does not go on the Target as host:443. That’s a common malformed-record mistake.
Target is the hostname running the service — and it must resolve via A/AAAA, not a CNAME (see the FAQ). A lone . here is the special “service not available here” signal.

Common Ways SRV Setup Goes Wrong

A CNAME target. The single most frequent mistake. It sometimes half-works and sometimes fails outright depending on the client, which makes it maddening to debug. Target must be an A/AAAA name.
The port jammed onto the target. sipdir.example.com:443 in the Target field is invalid. Port is its own field.
Missing underscores or wrong protocol. sip._tcp instead of _sip._tcp, or _tcp where the service actually wants _tls/_udp. The client asks for the exact name; a near-miss is a total miss.
Expecting it to affect a website. Browsers don’t query SRV for HTTP. If your goal is web traffic, SRV isn’t the mechanism.
Trailing-dot confusion in the Target. In a zone file, an unqualified Target gets the zone origin appended. Write the fully qualified Target with its trailing dot, or you’ll end up pointing at sipdir.example.com.example.com.

Diagnose with DechoNet

DNS Lookup queries the exact _service._proto.name and shows the priority, weight, port, and target the record actually returns — so you can confirm the record exists at the right name and that its four fields carry the values you think you set. It also shows whether the Target resolves to an address, which is how you catch a CNAME target before a client does.

Verification Checklist

Confirm the record’s owner name is _service._proto.domain with both underscores and the correct protocol label (_tcp, _udp, or _tls).
Confirm the Target resolves to an A or AAAA record, not a CNAME.
Confirm the Port field holds the real service port, and that it is not also appended to the Target.
Check that Priority reflects your intended primary/backup order (lower = tried first).
If you’re load-balancing, confirm the balanced targets share the same Priority and that their Weights add up the way you expect.
After a change, remember the old record’s TTL — clients may keep using the previous answer until it expires.

When SRV Isn’t the Problem

If the record checks out but the service still can’t be reached, the SRV record has done its job and the fault is downstream: the Target host is down, the Port is closed or firewalled, or the service isn’t actually listening where the record says. At that point stop editing DNS and confirm the target host answers on that port directly — the record was only ever a signpost, not the service.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.