Service location records
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsAn SRV (Service) record advertises the hostname and port for a specific service — such as SIP, XMPP, LDAP or Microsoft autodiscover — along with priority and weight for load balancing. Unlike an A record, it tells clients not just where a service lives but on which port, so applications can locate services without hardcoded configuration. Query them using the _service._proto.domain form.
An SRV record is named with a distinctive pattern: _service._proto.domain, for example _sip._tcp.example.com. The underscores prevent clashes with ordinary hostnames. The record's data holds four values: priority, weight, port and target. Priority works like MX — lower numbers are tried first. Weight distributes load among targets at the same priority, with higher weights getting proportionally more traffic. Port is the TCP or UDP port the service listens on, and target is the hostname providing it, which must have its own A or AAAA record.
IPeek returns each SRV record's priority, weight, port and target host for the service name you queried. Read priority first: clients use the lowest-priority targets before falling back to higher ones. Among equal priorities, weight decides the share of traffic each target receives. Confirm the port matches the service you expect — 5060 for SIP, 389 for LDAP, 443 for many autodiscover setups. Check that each target resolves to a valid host. An empty result means the service is not advertised under that name on the domain.
SRV records matter whenever clients must discover a service automatically rather than rely on fixed settings. Microsoft Teams, Skype for Business and SIP providers use them to locate voice and presence servers. XMPP chat, LDAP directory lookups, Minecraft servers and Kerberos all depend on SRV discovery. The big advantage is flexibility: move a service to a new host or port, or spread it across several servers, and clients follow the SRV records without reconfiguration. If a service requires a specific _service._proto name, publish a matching SRV record or clients will not find it.
This pattern names an SRV record by the service and protocol it describes. _service is the service label (like _sip or _ldap), _proto is the transport (_tcp or _udp), and domain is your domain. For example, _sip._tcp.example.com advertises SIP over TCP. The leading underscores keep these labels from colliding with normal hostnames.
Priority and weight control which target a client chooses. Priority works like MX records: clients try the lowest-priority targets first and fall back to higher numbers. Among targets sharing a priority, weight sets the proportion of traffic each receives, so a higher weight draws more connections. Together they enable both failover and load balancing.
An A record maps a hostname to an IP address, while an SRV record additionally specifies the port and adds priority and weight for a named service. SRV lets clients discover both where and on which port a service runs, plus how to balance load, which a plain A record cannot express. SRV targets still rely on A records to resolve.
SIP and VoIP systems, XMPP chat, LDAP and Active Directory, Kerberos, Microsoft Teams and Skype for Business, and even Minecraft servers commonly use SRV records. Any protocol that benefits from automatic service discovery without hardcoded host and port settings is a candidate. The client must be written to query the relevant _service._proto name.
An empty SRV result usually means no record is published under that exact _service._proto.domain name. Check the service label, protocol and domain are spelled correctly, including the underscores. The service may use a different name than expected, or the record may simply not exist. Confirm the precise name the client application requires.