SRV Record Propagation CheckerConfirm service location records are live across independent global DNS networks
- 7 independent networks
- Records + DNS flags
- No ads, no sign-up
Independent networks
7 public DNS networks, queried in parallel
Every test query is answered by these unaffiliated resolvers on separate networks and infrastructure. When they agree, you can trust the result.
- 8.8.8.8
Google Public DNS
Google LLC · North America
- 1.1.1.1
Cloudflare
Cloudflare, Inc. · Global Anycast
- 94.140.14.14
AdGuard DNS
AdGuard Software Ltd. · Europe
- 45.90.28.0
NextDNS
NextDNS, Inc. · Global Anycast
- 185.222.222.222
DNS.SB
xTom / Layer0 · Europe
- 223.5.5.5
Alibaba DNS
Alibaba Cloud · Asia
- 119.29.29.29
DNSPod
Tencent Cloud · Asia
How it works
A test query for flag propagation check, done right
Most checkers query a single resolver or a set of geographically labelled servers behind the same anycast network. isPropagated queries genuinely independent DNS operators and compares both their records and their response flags.
Enter a domain and run the test query
Type any domain, pick a record type (A, AAAA, CNAME, MX, TXT, NS and more), then run a single test query that fans out to every network at once.
We query independent global networks
Instead of asking one resolver, we ask several unaffiliated public DNS networks in parallel — across North America, Europe and Asia — so no single cache can mislead you.
Compare records and DNS flags
Each network returns its answer plus the DNS response flags (AD, CD, RA, RD, TC). We check that both the records and the flags agree before calling a domain propagated.
Read the propagation verdict
A clear consensus score shows how many networks resolved the record and whether their answers match — so you know the moment a change is live everywhere.
What is an SRV record and when does propagation matter?
An SRV (Service) record publishes the location of a specific service — hostname, port, priority, and weight — for a given protocol and domain. SRV records are used by VoIP (SIP), instant messaging (XMPP/Jabber), Microsoft Teams federation, Microsoft 365 Skype for Business, and other protocol-aware applications that discover endpoints via DNS.
Microsoft 365 setup requires several SRV records for Teams and Skype for Business to function. XMPP-based chat platforms need _xmpp._tcp SRV records for server-to-server federation. When you add or change these records, clients and federated servers will discover the new endpoint only after propagation is complete.
SRV record names follow the format _service._protocol.domain — for example, _sip._tls.example.com or _autodiscover._tcp.example.com. Enter the full SRV name in the input field to check propagation.
Reading SRV record results
An SRV record data value is formatted as: priority weight port target. For example, "10 10 443 sipdir.online.lync.com." means priority 10, weight 10, port 443, pointing to sipdir.online.lync.com. When all resolvers return the same priority, weight, port, and target, the SRV record has fully propagated.
Multiple SRV records at the same name define load-balancing and failover behaviour. All records in the set must match across resolvers for the service to work consistently.
FAQ
Common questions about srv record propagation checker
How do I check an SRV record for my domain?
Enter the full SRV record name in the input field. For Microsoft 365 SIP, that is _sip._tls.yourdomain.com. For XMPP, it is _xmpp._tcp.yourdomain.com. Select SRV from the type dropdown and run the test.
What SRV records does Microsoft 365 require?
Microsoft 365 requires several SRV records for Teams/Skype: _sip._tls (port 443 to sipdir.online.lync.com), _sipfederationtls._tcp (port 5061 to sipfed.online.lync.com), and sometimes _autodiscover._tcp. Check Microsoft's current DNS record requirements in the Microsoft 365 admin center, as they can change.
How long does SRV record propagation take?
SRV records propagate on their TTL, just like any other record type. A TTL of 3600 means up to 1 hour for old caches to expire. Microsoft 365 and other platforms can be slow to detect new SRV records even after DNS propagation — allow 15–30 minutes after confirmed propagation before testing the service.