ENUM permite que los números normales de teléfono (E.164) sean representados como nombres DNS que terminan en e164.arpa. Un número se puede resolver a unos o más servicios en una orden predefinido.

Por ejemplo, el numero de teléfono +44-116-496-0348 se representa como 8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa después de atravesar las reglas siguientes del RFC: (RFC 3761)

1. Quitar todos los caracteres a excepción de los dígitos. (”+44-116-496-0348” se convierte en “441164960348”)
2. Poner los puntos (”.”) entre cada dígito. (”4.4.1.1.6.4.9.6.0.3.4.8”)
3. Invertir el orden de los dígitos. (”8.4.3.0.6.9.4.6.1.1.4.4”)
4. Añadir la palabra “.e164.arpa” al final. (”8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa”)

Las entradas de NAPTR resultantes denotan los servicios para ese número. Por ejemplo, la configuración de BIND:

$ORIGIN 8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
      NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
      NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

describe que el dominio 8.4.3.0.6.9.4.6.1.1.4.4.e164.arpa puede ser contactado preferiblemente por SIP, en segundo lugar vía H.323, y en tercer lugar por smtp para mensajería.

Escoger que servicio utilizar es trabajo del sistema dinámico de descubrimiento de delegaciones (DDDS). En el ejemplo anterior, la bandera “u” le dice al DDDS que cada una de éstas son reglas terminales. Las reglas transformacionales que no tienen esta bandera presente se pueden utilizar para reescribir la llave producida por esta regla como la nueva llave en las operaciones de búsqueda de DDDS pero no se demuestra aqui un ejemplo de eso. Al momento, la bandera “u” es la única bandera definida.

El campo de servicio de la entrada NAPTR (tal como “E2U+sip”) debe comenzar con “E2U” para prevenir colisiones de nombres. Unos o más servicios de ENUM comenzando con “+” se enumeran. Un servicio de ENUM consiste de un tipo y cero o más subtipos separados por el caracter “:” . Los tipos y los subtipos se limitan a 32 caracteres alfanumericos que representan los protocolos válidos, y los esquemas de URI que pueden ser devueltos.

Las entradas de NAPTR son soportadas nativamente en BIND pero no en djbdns sin un parche que agrega SRV+NAPTR. Alternativamente, los usuarios de djbdns podrían construir una entrada de NAPTR a través de una entradad genérica pero no es fácil manejar entradas en este formato.