Run a lookup
How it works
Use the full service name
Service, protocol and domain, in that order: _autodiscover._tcp.example.com. Both underscores are required.
Query SRV over DoH
One lookup per name, run in your browser against public resolvers.
Read the four fields
Priority, weight, port and target are split into their own columns so you can see the routing at a glance.
Check the target resolves
An SRV pointing at a hostname with no A record is published but useless — follow it up with an A or AAAA lookup.
How to read the four numbers
Priority works like MX preference: lower wins. Clients try the lowest priority available and only fall back to higher numbers when those targets fail. Weight breaks ties within the same priority, distributing load proportionally — two targets at the same priority with weights 70 and 30 should see roughly that split. Port is the TCP or UDP port the service listens on, which is the whole point of SRV: unlike an MX record, it can direct clients to a non-standard port. Target is the hostname to connect to, and it must be a real hostname with an address record, never an IP and never a CNAME.
Where you actually meet SRV in email work
Mostly on Microsoft 365 migrations. Autodiscover — the mechanism that lets a mail client configure itself from an email address alone — is normally a CNAME, but the SRV form at _autodiscover._tcp is used when the CNAME name is already occupied. When client autoconfiguration breaks after a migration and the CNAME looks correct, a stale SRV record is a common culprit, because clients query it as part of the same discovery sequence and an old record can win.
Teams, Skype for Business and any SIP or XMPP deployment use SRV heavily too. For pure cold email infrastructure you will rarely publish one, but knowing how to read them saves time whenever a domain has a real mail estate behind it as well as a sending setup.
The mistakes that produce an empty result
The name is the usual problem. Both underscores are mandatory, the protocol must be _tcp or _udp, and many DNS panels append the zone automatically — so typing the fully qualified name into a field that already adds the domain produces _sip._tcp.example.com.example.com, which resolves to nothing. If a lookup here comes back empty and you are certain the record exists, that duplication is the first thing to check.
Frequently asked questions
Why does my SRV lookup return nothing?
Nine times out of ten the name is wrong. Both underscores are required, the protocol must be _tcp or _udp, and if your DNS panel appends the zone automatically you may have created a doubled name. Check what is published rather than what you intended to publish.
Can an SRV target be a CNAME?
It should not be. The specification requires the target to be a hostname with an address record. Pointing it at a CNAME works with some clients and fails with others, which produces exactly the kind of intermittent fault that is painful to track down.
What is the difference between priority and weight?
Priority selects which group of targets is tried first, lowest number winning. Weight only matters between targets that share the same priority, and distributes traffic proportionally among them. Priority is failover, weight is load balancing.
Do I need SRV records for cold email?
No. A sending domain needs MX, SPF, DKIM and DMARC. SRV becomes relevant when the domain also carries a real mail estate — Microsoft 365 autodiscover, Teams or a SIP deployment — and most often when troubleshooting a client that will not configure itself.
Can I use SRV to change the port mail is delivered on?
Not for SMTP delivery between servers, which uses MX and port 25 by convention. SRV can direct clients to non-standard ports for submission and retrieval, which is where _submission._tcp and similar names come in, but receiving servers will not consult it.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.