SRV records
The service-locator record: structure, where helpdesk techs meet them (Teams, SIP, autodiscover), and the format mistakes that break vendor onboardings.
SRV records aren’t routine work the way A and MX are. They show up in specific vendor setups (Teams, SIP, autodiscover), the format is fiddly, and the panels at most DNS hosts don’t always make it easy. When a vendor’s setup wizard tells you to add an SRV and you make a small format mistake, the service fails to discover and the client says the migration to Teams isn’t working.
The SRV structure
_service._protocol.name. TTL IN SRV priority weight port target.| Piece | What it is |
|---|---|
_service | Service name, prefixed with underscore (_sip, _xmpp-server, _sipfederationtls, _autodiscover) |
_protocol | _tcp or _udp, prefixed with underscore |
name | Domain the service is for (example.com.) |
priority | Like MX: lower = preferred |
weight | Load balancing among same-priority records |
port | Port number the service runs on |
target | Hostname providing the service (must have A/AAAA, never a CNAME) |
Example:
_sip._tls.example.com. 3600 IN SRV 100 1 443 sipdir.online.lync.com.SIP-over-TLS for example.com is provided at sipdir.online.lync.com on port 443, with priority 100 and weight 1.
The panel at most DNS hosts splits the fields. Read each panel field label carefully; some want the underscore-prefixed _service literally, others add the underscore for you.
Where you’ll actually meet SRV
The cases where you add an SRV are limited but specific:
- Microsoft 365 / Teams / Skype federation. The M365 setup wizard provides SRV records for SIP and federation discovery (
_sip._tls,_sipfederationtls._tcp). - SIP / VoIP. Hosted VoIP providers publish SIP-domain records via SRV. The client’s phone system discovers the SIP server by querying
_sip._udp.example.comor_sip._tcp. - Mail autodiscover for non-Microsoft providers. Fastmail, Apple iCloud, and similar publish autodiscover via SRV records (
_caldavs._tcp,_imaps._tcp). M365 uses aCNAME autodiscover.example.com → autodiscover.outlook.comapproach instead.
You won’t write SRV records from scratch. The vendor’s wizard tells you exactly what to publish.
What this is NOT
- “SRV is just like MX.” Similar priority semantics; different structure (adds weight, port, service.protocol naming). Same “target must be a hostname with A/AAAA, not CNAME or IP” rule applies.
- “All vendors use SRV.” Some do (Teams, SIP). M365 mail uses CNAMEs for autodiscover. The vendor’s documentation tells you what to publish.
- “SRV at the apex.” The format requires
_service._protocol.name. You’re publishing at_sip._tls.example.com, not at the apex itself.