# SIP domains > How a SIP domain record routes inbound INVITEs to a workspace, how the leftmost DNS label is matched, and how domains interact with trunks and numbers. A **SIP domain** is the hostname that your carrier, PBX, or softphone puts in the request URI when it sends an INVITE to TeleQuick. Every workspace gets one by default, in the form `.sip.`. The **SIP domains** screen under Admin is where you see that hostname, add your own vanity hostnames alongside it, and check whether each one is verified and accepting traffic. The screen is one implementation rendered in both the contact centre and the voice-AI console, so what you see in either place is the same record set. Reads and writes on this screen go through the control-plane API. The same operations are available to your backend over the control-plane tRPC interface with an API key; the control plane rejects a key that lacks the capability scope for trunk and domain administration. See [Authentication](/concepts/authentication). ## What a SIP domain is and how it differs from a trunk A domain and a trunk answer two different questions about the same call. | | SIP domain | Trunk | | --- | --- | --- | | Answers | "Which workspace is this INVITE for?" | "Which peer is this, and what may it do?" | | Keyed on | The hostname in the request URI | The signalling source (peer identity / source IP) | | Direction | Inbound signalling target | Inbound and outbound | | Cardinality | A workspace may have several | A workspace may have several | A domain is an *addressing* object. It does not by itself authorise a call, carry codec or CLI policy, or decide where a call lands in the dialplan. A trunk is the *authorisation and policy* object. A domain with no matching trunk gives you a reachable hostname that rejects everything it receives. Each row on the screen is a single hostname plus its state: whether it is the workspace's default endpoint or one you added, whether verification has completed, and the transports it currently answers on. Trunks and numbers are managed on their own screens; the domain row links them rather than owning them. ## How an inbound INVITE is matched to a domain Matching is done on the **leftmost DNS label** of the host part of the request URI, not on the full hostname string and not on the To header. For the default endpoint `.sip.`, the leftmost label is the workspace id. An INVITE to `sip:+15550001111@acme-4f2b.sip.` resolves to the workspace whose id is `acme-4f2b`. The remainder of the hostname identifies the TeleQuick SIP edge; it is not tenant-specific. Consequences worth knowing before you configure a carrier: - The label must match a domain record exactly. Case is not significant; anything else is. - A carrier that rewrites the request URI to its own hostname, or that sends the INVITE to a bare IP address, produces **no** leftmost label to match. Those INVITEs fall through to source-IP matching on the trunk instead — see the routing order below. - A vanity hostname you add is matched the same way, on its own leftmost label. Pointing `voice.example.com` at the edge does not make `example.com` match. ## Adding, verifying, and removing a domain The default `.sip.` endpoint exists without any setup and cannot be removed. Additional hostnames go through verification so that a workspace cannot claim a hostname it does not control. 1. **Add** the hostname on the SIP domains screen. It is created in an unverified state and does not yet match inbound INVITEs. 2. **Publish the DNS record** the screen displays for that row, in the zone that owns the hostname. The screen shows the exact name and value to publish; do not guess it, because the value is per-record. 3. **Verify.** The screen re-checks DNS and moves the row to verified once the record resolves. Until then the row stays unverified. DNS propagation is outside TeleQuick's control, so a freshly published record may need another check. 4. **Point your peer at it.** Verification only makes the hostname eligible for matching; the call still needs a trunk that authorises the sender. **Removing** a domain takes its label out of the match set. Any peer still sending INVITEs to that hostname stops being matched, and its calls are rejected. Remove a domain only after the carrier or PBX has been cut over to another hostname. Removal does not delete trunks or release numbers. ## Domains, trunks, and numbers: the routing order An inbound call is resolved in three stages. Each stage can fail independently, which is why a call can be "reaching us" and still be rejected. 1. **Tenant resolution.** The leftmost DNS label of the request-URI host is matched against the workspace's verified domain records. If the INVITE arrived at a bare IP or an unrecognised hostname, this stage produces no tenant and the gateway falls through to stage 2 to identify the sender. 2. **Peer authorisation.** The signalling source is matched against the workspace's trunks — source-IP matching for IP-authenticated trunks, or registration/credential identity for registered peers. The trunk decides whether the INVITE is accepted at all, and supplies the call's policy. If stage 1 resolved a tenant, the trunk must belong to that tenant; a trunk from a different workspace is not a match. 3. **Number routing.** The user part of the request URI is looked up against the numbers (DIDs) provisioned in the workspace to choose the dialplan or agent that handles the call. Stage 1 narrows the search; stage 2 authorises; stage 3 routes. A vanity domain therefore changes *how a peer addresses you*, never *what the call is allowed to do* — that stays on the trunk — and never *where the call lands* — that stays on the number. ## Transport and TLS on port 5060 The screen shows which transports each domain answers on. Port `5060` is the standard SIP signalling port and is what a carrier or PBX will use unless you tell it otherwise; it carries unencrypted SIP over UDP or TCP, so the signalling — including the request URI that drives the matching above — is visible on the wire. For encrypted signalling, use the SIP-over-TLS transport and the TLS port shown for the domain on the screen, and configure your peer with the hostname rather than an IP address: TLS certificate validation is done against the hostname, so an IP-addressed peer cannot verify the edge and, as noted above, also defeats leftmost-label matching. Encrypting signalling with TLS does not encrypt media; media encryption is negotiated separately on the trunk. ## Failure modes: unmatched label, wrong tenant, rejected INVITE | Symptom | Likely cause | Where to look | | --- | --- | --- | | Calls to a newly added hostname are rejected, default endpoint works | Domain row is still unverified | SIP domains screen — check the row state and that the displayed DNS record resolves | | Carrier reports failure, nothing appears against your workspace | No leftmost label matched: the carrier is sending to a bare IP or its own hostname, and no trunk matched the source either | Carrier's request-URI configuration; the trunk's source-IP list | | Hostname matches but every INVITE is rejected | No trunk authorises the sender, or the matching trunk belongs to another workspace | Admin → Trunks — peer identity and source IPs | | INVITE accepted, then fails with no route | Domain and trunk matched; the dialled number is not provisioned or has no dialplan | Numbers / DID routing | | Worked yesterday, fails today, no config change | The domain was removed or the DNS record it verified against was deleted from the zone | SIP domains screen; your DNS zone | When no `CallEvent` reaches the SDK at all, the failure is at stage 1 or 2 and you need the SIP exchange itself. Enable HEPv3 capture on the gateway and inspect the INVITE's request URI and source address directly — see [Telemetry](/platform/telemetry). ## Related - [SIP trunking](/modalities/voice/transport-telephony/sip-trunking) — trunk creation, peer authentication, and the default per-workspace endpoint - [Authentication](/concepts/authentication) — API keys and capability scopes for control-plane calls - [Telemetry](/platform/telemetry) — metrics, CDRs, and SIP packet capture