Technical reference · June 2026
ENUM Interface
Query specification for num-iD identify and verify products over ENUM.
This document contains proprietary and confidential information belonging to num-iD. Unless specifically authorized, no portion of this document may be copied, saved, or shared in any format, whether physical, electronic, or mechanical, including but not limited to photocopying, recording, or storing in a retrieval system, without prior written consent from num-iD.
No part of this document should be interpreted as an offer to provide goods or services unless explicitly mentioned. All transactions are governed by contract.
1. Overview
This document provides details on the ENUM query interface for num-iD's identify and verify products.
The service is primarily designed to enhance customers' Voice & SMS routing and support applications requiring accurate number validation.
Customers can query the identify and verify services through num-iD's Global Points of Presence (PoPs). Along with ENUM, the service also supports HTTP/S query protocols. num-iD offers multiple product options, enabling users to retrieve information about the routing, ownership and status of E.164 telephone numbers.
2. Service Access
2.1. IP Access and Endpoint URLs
The ENUM query service is accessible through num-iD PoPs over the public Internet. Queries are accepted over UDP and TCP on port 53 and resolved against the following apex:
enum.num-id.com
The IP address (or addresses) of each PoP is provided at provisioning time. Customers can select from any or all available num-iD PoPs to reduce query latency and improve resilience. The full list of PoPs can be obtained by contacting num-iD Sales or Support. Clients who have registered fixed source IPs with num-iD are permitted to use any of the PoPs.
2.2. Authorization for Queries
Customer queries over ENUM are authenticated exclusively by source IP address:
- Registered IP Authorization: num-iD registers the customer's source IP addresses, and only queries from these authorized IPs are permitted. No API key, user/password or token is transmitted in the query.
User/password and token-based authorization are not applicable to ENUM, as the DNS protocol does not provide a mechanism to carry credentials. Customers who require credential-based authorization should use the HTTP/S interface instead.
At provisioning time num-iD will request the public IP address (or addresses) from which your platform will send queries. Any change to your source addresses must be notified in advance to num-iD support, otherwise queries will be rejected.
2.3. Preferred Authentication Method
Because ENUM relies exclusively on registered source IPs, the following recommendations apply:
- Registered Fixed IPs: Customers must utilize fixed IP addresses registered with the num-iD system.
- IP Management: Support requests can be made to add or remove source IP addresses as needed.
- Resilience: Customers are encouraged to direct queries to every PoP for optimal redundancy and resilience.
- NAT considerations: Where customer traffic egresses through NAT, the public IP of the NAT gateway must be registered, not the internal IPs of the individual query sources.
- Cross-protocol accounts: A single customer account can be authorized for both ENUM (by source IP) and HTTP/S (by IP, user/password or token). Queries are billed against the same account.
Additionally, customers can configure multiple access types based on the service, origin point, and specific use case. num-iD will assist in determining the most appropriate setup if needed.
3. DNS Response Codes
The system will return one of the following DNS responses based on the customer's query. Note that a query which resolves — regardless of whether the number is valid, allocated or reachable — returns NOERROR with a NAPTR record; the reason is carried in the rc field of the response, not in the DNS status.
| Code | Description | Body content |
|---|---|---|
| NOERROR | The requested number information has been retrieved successfully. | NAPTR record with the various fields and their corresponding values. See section 5 for examples per query type. |
| REFUSED | Access is denied. Source IP is not authorized for the requested service. | No answer section. |
| NXDOMAIN | The request is not valid. Malformed query, invalid number format or unknown product domain. | No answer section. |
| SERVFAIL | An error occurred on the server. Retry is appropriate. | No answer section. |
Responses carry a TTL of 60 seconds. Successful queries return a single NAPTR record of the form:
{query}. 60 NAPTR 100 10 "u" "E2U+pstn:tel" "!^.*$!{fields}!" . Where {fields} is a semicolon-separated list beginning with the tel: URI, followed by the response parameters described in section 5.
4. Selecting products
The ENUM query interface offers a range of products and options. Each product may have its own set of commercial terms and service features, and may return different responses for the same E.164 telephone number. num-iD also offers customized responses based on specific customer needs, which may include adjustments to data sources, response fields or service logic. While standard products are available, customizations are possible to better align with customer requirements. Details on the standard query types can be found later in this document.
Customers can select the desired query type by including a product subdomain as part of the ENUM query in the following format:
{reversed-number}.<service>.enum.num-id.com Please note that customers must be authorized to use each specific service type. The service identifier for each available service type is listed below.
| ENUM domain queried | Product selected |
|---|---|
{reversed-number}.nri.enum.num-id.com | NRI — Numbering Range Information |
{reversed-number}.mnp.enum.num-id.com | MNP — Mobile Number Portability |
{reversed-number}.hlr.enum.num-id.com | HLR — Home Location Register (live status) |
The E.164 number is converted to ENUM format following RFC 6116:
- Remove all non-digit characters, including any leading
+ - Reverse the order of the digits
- Separate each digit with a dot
- Append the product subdomain
For example, the number +351923XXXXXX queried against MNP becomes X.X.X.X.X.X.3.2.9.1.5.3.mnp.enum.num-id.com.
4.1. Release codes
Release codes offer extra details about how a query was processed within the num-iD system. These codes can explain failure reasons or provide other general information. A full list of the current reason codes is available in the document titled 'Response parameters and values'.
For some MNP destinations, num-iD relies on third-party providers to conduct remote queries. Should the third-party provider fail to deliver a response, num-iD will either return a 'Supplier Timeout' reason code (if reason codes are enabled) or issue a NOERROR response with no routing information beyond tel: and rc.
npdi flag. A specific release code will be included if the customer has this option enabled.
5. Query types and example responses
The following sections outline the different query services accessible through the num-iD ENUM interface. Detailed explanations of the fields returned for each query type are available in the document titled 'Response parameters and values'.
5.1. Numbering Range Information (NRI)
The NRI query utilizes the num-iD Numbering Range Information database, regularly updated with data from regulators, industry bodies, traffic tests and customer feedback.
The NRI query checks that the telephone number (tel:) is:
- Correctly formatted (E.164 standard)
- Within the valid length for its range
- Part of a range officially allocated to a service provider by a national regulator (Operator of Record,
cn)
Primarily used for basic number validation (e.g., customer sign-ups, OBR validation, B-number fraud checks), the NRI also supports routing where number portability is not required.
NRI verifies that a telephone number (TN) falls within an officially assigned number range, but does not confirm whether the TN is actively assigned to a subscriber.
Below is an example of an NRI query made to a valid number. For invalid numbers, a corresponding reason code will be provided, indicating why the NRI query was unsuccessful.
dig @enum.num-id.com X.X.X.7.2.9.5.0.6.4.3.nri.enum.num-id.com NAPTR ;; ANSWER SECTION: X.X.X.7.2.9.5.0.6.4.3.nri.enum.num-id.com. 60 IN NAPTR 100 10 "u" "E2U+pstn:tel" "!^.*$!tel:+34605927XXX;cic=87240051;cc=ES;cn=ORANGE%20ESPAGNE%2C%20S.A.UNIPERSONAL%20%2803%29;nt=mobile;mcc=214;mnc=03;rc=1-00!" .
5.2. Mobile Number Portability (MNP)
The MNP product delivers details about the current Service Provider responsible for the queried phone number, while considering Number Portability. It gathers Number Portability data from multiple sources.
Whether or not the number has been ported, or the country supports Number Portability, the MNP product will still generate a routing result. For numbers that haven't been ported or belong to countries without portability, ownership information is derived from Numbering Range Information.
Before resolving the MNP query, the number is validated through the NRI database. If the number is found to be invalid, a reason code will be provided explaining the failure.
MNP is commonly used to optimize the routing of SMS and voice calls, as identifying the network serving the B-number in advance can lead to cost savings and improved quality in traffic termination.
The example below demonstrates a successful MNP query and its corresponding response.
dig @enum.num-id.com X.X.X.X.X.X.3.2.9.1.5.3.mnp.enum.num-id.com NAPTR ;; ANSWER SECTION: X.X.X.X.X.X.3.2.9.1.5.3.mnp.enum.num-id.com. 60 IN NAPTR 100 10 "u" "E2U+pstn:tel" "!^.*$!tel:+351923******;npdi;npi;cic=86200081;cc=PT;cn=VODAFONE%20PORTUGAL%20-%20COMUNICACOES%20PESSOAIS%20%2801%29;nt=mobile;mcc=268;mnc=01;rc=1-00!" .
The presence of npdi indicates a portability dip was performed; the presence of npi indicates the number is currently ported. cn, mcc and mnc identify the network currently serving the number.
If the MNP query is unable to return routing information, an appropriate reason code will be provided, explaining the cause of the failure. For customers with the 'Fallback to NRI' option enabled, routing information derived from NRI data will be returned instead. In this case, the npdi flag will be absent, and a relevant reason code will also be included.
5.3. Home Location Register (HLR)
The HLR product provides real-time information about the current Service Provider and the live status of the queried mobile number. It uses live network sources (e.g., HLR or MNO APIs), so it can indicate whether the number is valid and reachable at the time of the query.
Whether or not the number has been ported, the HLR product returns a routing result based on live sources. For numbers or destinations where a live response is not available, ownership and routing can be derived from Numbering Range Information (NRI) when the customer has this fallback enabled.
Before resolving the HLR query, the number is validated against NRI. If the number is invalid, a release code will be returned explaining the failure. When a live response is successful, the service also returns the number status field (ns), e.g. success, unknown subscriber or absent subscriber.
HLR is commonly used to optimize SMS and voice routing and to validate destinations in real time, improving deliverability and reducing costs by avoiding traffic to unreachable numbers.
The example below demonstrates a successful HLR query and its corresponding response.
dig @enum.num-id.com X.X.X.X.X.X.3.2.9.1.5.3.hlr.enum.num-id.com NAPTR ;; ANSWER SECTION: X.X.X.X.X.X.3.2.9.1.5.3.hlr.enum.num-id.com. 60 IN NAPTR 100 10 "u" "E2U+pstn:tel" "!^.*$!tel:+351923******;npdi;cc=PT;nt=mobile;mcc=268;mnc=01;nv=000;ns=000;rc=1-00!" .
ns=000 — the subscriber is active and reachable. The full set of live-status values is:
| Value | Meaning |
|---|---|
000 | Subscriber active and reachable |
001 | Unknown subscriber — the number is not known to the network |
002 | Absent subscriber — number allocated but handset off or out of coverage |
003 | Other temporary status |
004 | Query could not be completed — no subscriber information obtained |
ns=002 indicates the number exists and is allocated; it is not an inactive number. ns=004 means no result was obtained and should not be interpreted as either active or inactive.
If the HLR query cannot return live routing/status information, an appropriate release code will explain the cause. For customers with the 'Fallback to NRI' option enabled, routing information derived from NRI will be returned instead; in that case, npdi will be absent and the response will not include a live status.
ns and nv values are three-digit strings and must be handled as strings — converting them to integers will discard leading zeros and produce incorrect comparisons. The cn field is URL-encoded per RFC 3986 — spaces appear as %20, commas as %2C, parentheses as %28 and %29.