DNS
SRV record generator & checker
Build a correctly shaped SRV record for SIP or Microsoft Teams, then check the live one against it for exactly what a registrar panel tends to mangle.
Free, no accountLive check
Result
Fill in the form and press Check the SRV record. The verdict and the detail appear here.
What this is
This srv record generator writes a correctly shaped record for SIP registration, Microsoft Teams federation or a service you name yourself, and the checker half reads back what is actually published for that same service - catching the handful of ways a registrar panel is known to mangle one on the way in.
An SRV record names the host and port that actually answers one specific service, keyed off the service and protocol folded into the record name itself: RFC 2782 has a client look up "_service._protocol.domain" rather than guessing at a fixed well-known port, which is what lets SIP, XMPP and Microsoft Teams federation all share one domain without colliding on a single port number.
Four values make up the record once that name is settled: priority decides which target a client tries first; weight splits traffic between targets that tie on priority; port is where the target host answers; and target is the host itself, which a correctly published record always ends with a dot, marking it as the complete name rather than one DNS should extend with whatever zone it happens to be sitting in.
How to read the result
A "Built the record" finding is the record this page generated from the fields above it - copy it as-is into a DNS panel, whether the preset picked SIP, Teams, or a custom service typed by hand. Everything after it comes from an actual live lookup of that same service, not from the fields: a pass means what is published is already shaped correctly, and a fail or a warn names exactly which part a panel got wrong and how to fix it.
Most of the broken shapes below come from the same root cause: a panel that asks for priority, weight, port and target in four separate boxes, then writes them back to the zone file joined in the wrong order or with one value spilling into another. The finding always quotes the exact raw line that was read, so it can be checked against whatever the panel currently shows.
Common mistakes
What goes wrong most often, and how to tell.
- Leaving the record's Host box value as the literal "@" in the Target fieldA DNS panel uses "@" in its own Host column to mean the zone apex, but that placeholder is not a hostname, and a target field holding it literally sends every client looking for a host that was never meant to exist.
- Assuming the Teams preset's known numbers apply to any other serviceMicrosoft's own fixed priority, weight, port and target for Teams federation are specific to that one service; carrying the same numbers over to a SIP trunk or a custom service's own SRV record has no basis in anything either vendor documents.
- Treating a passed shape check as proof the service itself is reachableThis page confirms a published record is correctly shaped and points at a real hostname, not that the host actually answers on the stated port right now - a shape check and a working connection are two different questions.
Questions
What people ask about this tool.
- Priority alone decides the order a client tries targets in; weight only comes into play among targets that share the exact same priority, where it is the ratio a client should split its requests between them - a target with no equal-priority sibling can carry any weight at all with no effect.
- Some registrar panels split an SRV record's host and value into a Host box (holding "_service._protocol") and a Value box (holding "priority weight port target"), rather than accepting the whole line at once - the generated record above works either way, since it is written as both pieces joined by a space.
- Not always: most resolvers fall back to appending the record's own zone when a target has no trailing dot, so it frequently still resolves. But that is a fallback, not the fully-qualified name RFC 2782 specifies, and it can land on the wrong host entirely if the zone being appended is not the one the panel actually meant.
- Those are the exact fixed values Microsoft documents for the _sipfederationtls._tcp SRV record every Teams or Skype for Business tenant using direct routing or federation needs, pointing at Microsoft's own sipfed.online.lync.com - unlike a SIP trunk's numbers, which are a provider's own choice, this one has a single correct answer.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- IETF, “RFC 2782: A DNS RR for specifying the location of services (DNS SRV)” read 13 October 2026
- Microsoft, “Plan Direct Routing” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.