Dirección de correo electrónico

Una dirección de correo electrónico identifica un buzón de correo electrónico al que se envían los mensajes. Si bien los primeros sistemas de mensajería utilizaban una variedad de formatos para las direcciones, hoy en día, las direcciones de correo electrónico siguen un conjunto de reglas específicas estandarizadas originalmente por el Grupo de trabajo de ingeniería de Internet (IETF) en la década de 1980 y actualizadas por RFC  5322 y 6854. El término dirección de correo electrónico en este artículo se refiere solo a addr-spec en la Sección 3.4 de RFC 5322. El RFC define address de manera más amplia como un buzón de correo o un grupo . Un valor de buzón de correo puede ser un name-addr , que contiene un display-name y addr-spec , o el más común addr-spec solo.

Una dirección de correo electrónico, como [email protected] , se compone de una parte local, el símbolo @, y un dominio , que puede ser un nombre de dominio o una dirección IP entre corchetes. Aunque el estándar requiere que la parte local distinga entre mayúsculas y minúsculas, ^[1] también insta a que los hosts receptores entreguen los mensajes de manera independiente de las mayúsculas y minúsculas, ^[2] por ejemplo, que el sistema de correo en el dominio example.com trate a John.Smith como equivalente a john.smith ; algunos sistemas de correo incluso los tratan como equivalentes a johnsmith . ^[3] Los sistemas de correo a menudo limitan la elección del nombre de los usuarios a un subconjunto de los caracteres técnicamente permitidos; con la introducción de nombres de dominio internacionalizados , se están realizando esfuerzos para permitir caracteres que no sean ASCII en las direcciones de correo electrónico.

Debido a la ubicuidad del correo electrónico en el mundo actual, las direcciones de correo electrónico se utilizan a menudo como nombres de usuario habituales en muchos sitios web y servicios que proporcionan un perfil o cuenta de usuario. ^[4] Por ejemplo, si un usuario desea iniciar sesión en su perfil de videojuegos Xbox Live , utilizaría su cuenta de Microsoft en forma de dirección de correo electrónico como ID de nombre de usuario, aunque el servicio en este caso no sea el correo electrónico.

Una dirección de correo electrónico consta de dos partes: una parte local (a veces un nombre de usuario, pero no siempre) y un dominio; si el dominio es un nombre de dominio en lugar de una dirección IP, el cliente SMTP utiliza el nombre de dominio para buscar la dirección IP del intercambio de correo. El formato general de una dirección de correo electrónico es parte local @ dominio , por ejemplo, jsmith@[192.168.1.2], [email protected] . El cliente SMTP transmite el mensaje al intercambio de correo, que puede reenviarlo a otro intercambio de correo hasta que finalmente llega al host del sistema de correo del destinatario.

La transmisión de correo electrónico desde el ordenador del autor y entre servidores de correo en Internet utiliza el Protocolo simple de transferencia de correo (SMTP), definido en RFC  5321 y 5322, y extensiones como RFC  6531. Los buzones de correo pueden ser accedidos y administrados por aplicaciones en ordenadores personales, dispositivos móviles o sitios de correo web , utilizando el protocolo SMTP y el Protocolo de oficina postal (POP) o el Protocolo de acceso a mensajes de Internet (IMAP).

Al transmitir mensajes de correo electrónico , los agentes de usuario de correo (MUA) y los agentes de transferencia de correo (MTA) utilizan el sistema de nombres de dominio (DNS) para buscar un registro de recursos (RR) para el dominio del destinatario. Un registro de recursos de intercambiador de correo ( registro MX ) contiene el nombre del servidor de correo del destinatario. En ausencia de un registro MX, un registro de dirección ( A o AAAA ) especifica directamente el host de correo.

La parte local de una dirección de correo electrónico no tiene importancia para los sistemas de retransmisión de correo intermedios que no sean el host del buzón final. Los remitentes de correo electrónico y los sistemas de retransmisión intermedios no deben asumir que no distingue entre mayúsculas y minúsculas, ya que el host del buzón final puede tratarla como tal o no. Un solo buzón puede recibir correo para varias direcciones de correo electrónico, si el administrador lo configura. Por el contrario, una sola dirección de correo electrónico puede ser el alias de una lista de distribución para muchos buzones. Los alias de correo electrónico , las listas de correo electrónico , las subdirecciones y las direcciones de captura general , estas últimas siendo buzones que reciben mensajes independientemente de la parte local, son patrones comunes para lograr una variedad de objetivos de entrega.

Las direcciones que se encuentran en los campos de encabezado de un mensaje de correo electrónico no son utilizadas directamente por los intercambios de correo para entregar el mensaje. Un mensaje de correo electrónico también contiene un sobre de mensaje que contiene la información para el enrutamiento del correo. Si bien las direcciones de sobre y de encabezado pueden ser iguales, las direcciones de correo electrónico falsificadas (también llamadas direcciones de correo electrónico falsificadas ) se ven a menudo en spam , phishing y muchas otras estafas basadas en Internet. Esto ha dado lugar a varias iniciativas que tienen como objetivo hacer que estas falsificaciones de correos electrónicos fraudulentos sean más fáciles de detectar.

El formato de una dirección de correo electrónico es parte-local@dominio , donde la parte local puede tener hasta 64 octetos de longitud y el dominio puede tener un máximo de 255 octetos. ^[5] Las definiciones formales se encuentran en RFC 5322 (secciones 3.2.3 y 3.4.1) y RFC 5321, con una forma más legible dada en el informativo RFC 3696 (escrito por J. Klensin, el autor de RFC 5321) y las erratas asociadas.

Una dirección de correo electrónico también puede tener asociado un "nombre para mostrar" (Display Name) para el destinatario, que precede a la especificación de la dirección, ahora rodeada por corchetes angulares, por ejemplo: John Smith <[email protected]> . ^[6] Los spammers de correo electrónico y los phishers a menudo utilizarán la "suplantación de nombre para mostrar" para engañar a sus víctimas, utilizando un nombre para mostrar falso o una dirección de correo electrónico diferente como nombre para mostrar. ^[7]

Las formas anteriores de direcciones de correo electrónico para redes distintas de Internet incluían otras notaciones, como la requerida por X.400 y la notación UUCP bang path , en la que la dirección se proporcionaba en forma de una secuencia de computadoras a través de las cuales se debía transmitir el mensaje. Esta notación se usó ampliamente durante varios años, pero fue reemplazada por los estándares de Internet promulgados por el Grupo de Trabajo de Ingeniería de Internet (IETF).

La parte local de la dirección de correo electrónico puede no estar entre comillas o puede estar entre comillas.

Si no está entre comillas, puede utilizar cualquiera de estos caracteres ASCII :

• letras latinas mayúsculas y minúsculas Ato Zy atoz
• dígitos 0a9
• personajes imprimibles!#$%&'*+-/=?^_`{|}~
• punto ., siempre que no sea el primer ni el último carácter y siempre que no aparezca consecutivamente (por ejemplo, [email protected]no está permitido). ^[8]

Si se cita, puede contener espacio, tabulación horizontal (HT), cualquier gráfico ASCII excepto barra invertida y comillas y un par entre comillas que consiste en una barra invertida seguida de HT, espacio o cualquier gráfico ASCII; también puede dividirse entre líneas en cualquier lugar donde aparezca HT o espacio. A diferencia de las partes locales sin comillas, se permiten las direcciones ".John.Doe"@example.com, "John.Doe."@example.comy ."John..Doe"@example.com

La longitud total máxima de la parte local de una dirección de correo electrónico es de 64 octetos. ^[9]

• Se permiten espacios y caracteres especiales "(),:;<>@[\]con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo siguiente, y en esa cadena entre comillas, cualquier barra invertida o comilla doble debe estar precedida una vez por una barra invertida);
• Se permiten comentarios con paréntesis en cada extremo de la parte local; por ejemplo, john.smith(comment)@example.comy (comment)[email protected]son ambos equivalentes a [email protected].

Además de los caracteres ASCII anteriores, los caracteres internacionales superiores a U+007F, codificados como UTF-8 , están permitidos por RFC 6531 cuando EHLO especifica SMTPUTF8 , aunque incluso los sistemas de correo que admiten SMTPUTF8 y 8BITMIME pueden restringir qué caracteres usar al asignar partes locales.

Una parte local es una cadena de puntos o una cadena entre comillas; no puede ser una combinación. Sin embargo, las cadenas y caracteres entre comillas no se utilizan comúnmente. ^{[ cita requerida ]} RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar definir buzones en los que la parte local requiera (o utilice) el formato de cadena entre comillas".

La parte local postmasterse trata de manera especial: no distingue entre mayúsculas y minúsculas y debe reenviarse al administrador de correo electrónico del dominio. Técnicamente, todas las demás partes locales distinguen entre mayúsculas y minúsculas, por lo tanto [email protected], [email protected]especifican buzones de correo diferentes; sin embargo, muchas organizaciones tratan las letras mayúsculas y minúsculas como equivalentes. De hecho, RFC 5321 advierte que "un host que espera recibir correo DEBE evitar definir buzones de correo en los que... la parte local distingue entre mayúsculas y minúsculas".

A pesar de la amplia gama de caracteres especiales que son técnicamente válidos, las organizaciones, los servicios de correo, los servidores de correo y los clientes de correo en la práctica a menudo no los aceptan todos. Por ejemplo, Windows Live Hotmail solo permite la creación de direcciones de correo electrónico utilizando caracteres alfanuméricos, punto ( .), guión bajo ( _) y guión ( -). ^[10] El consejo habitual es evitar el uso de algunos caracteres especiales para evitar el riesgo de que los correos electrónicos sean rechazados. ^[11]

Según RFC 5321 2.3.11 Mailbox and Address, "la parte local DEBE ser interpretada y semánticamente asignada únicamente por el host especificado en el dominio de la dirección". Esto significa que no se pueden hacer suposiciones sobre el significado de la parte local de otro servidor de correo. Depende completamente de la configuración del servidor de correo.

La interpretación de la parte local depende de las convenciones y políticas implementadas en el servidor de correo. Por ejemplo, la distinción entre mayúsculas y minúsculas puede distinguir buzones de correo que difieren solo en la capitalización de los caracteres de la parte local, aunque esto no es muy común. ^[12] Por ejemplo, Gmail ignora todos los puntos en la parte local de una dirección @gmail.com a los efectos de determinar la identidad de la cuenta. ^[13]

Algunos servicios de correo admiten una etiqueta incluida en la parte local, de modo que la dirección sea un alias de un prefijo de la parte local. Normalmente, los caracteres que siguen a un signo más y, con menos frecuencia, los que siguen a un signo menos, por lo que fred+bah@domain y fred+foo@domain pueden terminar en la misma bandeja de entrada que fred+@domain o incluso como fred@domain. Por ejemplo, la dirección [email protected] denota la misma dirección de entrega que [email protected] . RFC  5233 ^[14] se refiere a esta convención como subdireccionamiento , pero también se conoce como direccionamiento plus , direccionamiento etiquetado o extensiones de correo . Esto puede ser útil para etiquetar correos electrónicos para su clasificación y para el control del correo no deseado. ^[15]

Las direcciones de este formato, que utilizan varios separadores entre el nombre base y la etiqueta, son compatibles con varios servicios de correo electrónico, incluidos Andrew Project (más), ^[16] Runbox (más), ^[17] Gmail (más), ^[15] Rackspace (más), Yahoo! Mail Plus (guión), ^[18] iCloud de Apple (más), Outlook.com (más), ^[19] Mailfence (más), ^[20] Proton Mail (más), ^[21] Fastmail (más y direccionamiento de subdominio), ^[22] postale.io (más), ^[23] Pobox (más), ^[24] MeMail (más), ^[25] y MTA como MMDF (igual), Qmail y Courier Mail Server (guión). ^{[26] [27]} Postfix y Exim permiten configurar un separador arbitrario del conjunto de caracteres legales. ^{[28] [29]}

El texto de la etiqueta se puede utilizar para aplicar filtros, ^[26] o para crear direcciones de correo electrónico de un solo uso o desechables . ^[30]

La parte del nombre de dominio de una dirección de correo electrónico debe cumplir con pautas estrictas: debe cumplir con los requisitos de un nombre de host , una lista de etiquetas DNS separadas por puntos , cada etiqueta está limitada a una longitud de 63 caracteres y consta de: ^{[8] : §2}

• Letras latinas mayúsculas y minúsculas Ato Zy ato z;
• Dígitos 0hasta 9, siempre que los nombres de dominio de nivel superior no sean totalmente numéricos;
• Guión -, siempre que no sea el primer ni el último carácter.

Esta regla se conoce como la regla LDH (letras, dígitos, guiones). Además, el dominio puede ser una dirección IP literal, rodeada de corchetes [], como jsmith@[192.168.2.1]o jsmith@[IPv6:2001:db8::1], aunque esto rara vez se ve excepto en correos electrónicos no deseados . Los nombres de dominio internacionalizados (que están codificados para cumplir con los requisitos de un nombre de host ) permiten la presentación de dominios que no sean ASCII. En los sistemas de correo que cumplen con RFC 6531 y RFC 6532, una dirección de correo electrónico puede estar codificada como UTF-8 , tanto una parte local como un nombre de dominio.

Los comentarios están permitidos tanto en el dominio como en la parte local; por ejemplo, john.smith@(comment)example.comy [email protected](comment)son equivalentes a [email protected].

La RFC  2606 especifica que ciertos dominios, por ejemplo aquellos destinados a documentación y pruebas, no deben poder resolverse y que, como resultado, el correo dirigido a buzones de correo en ellos y sus subdominios no debe poder entregarse. Cabe destacar, en el caso del correo electrónico, example , invalid , example.com , example.net y example.org .

• [email protected]
• [email protected]
• [email protected](el caso siempre se ignora después del @ y generalmente antes)
• [email protected](parte local de una letra)
• [email protected]
• [email protected](puede ser enrutado a [email protected]la bandeja de entrada dependiendo del servidor de correo)
• name/[email protected](las barras son un carácter imprimible y están permitidas)
• admin@example(nombre de dominio local sin TLD , aunque ICANN desaconseja enfáticamente las direcciones de correo electrónico sin punto ^[31] )
• [email protected](ver la Lista de dominios de nivel superior de Internet )
• " "@example.org(espacio entre las comillas)
• "john..doe"@example.org(entre comillas dobles)
• [email protected](ruta de host bangificada utilizada para los correos uucp)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(incluye caracteres que no sean letras Y múltiples arrobas , siendo la primera entre comillas dobles)
• user%[email protected](% ruta de correo escapada a [email protected] vía ejemplo.org)
• [email protected](parte local que termina con un carácter no alfanumérico de la lista de caracteres imprimibles permitidos)
• postmaster@[123.123.123.123](Se permiten direcciones IP en lugar de dominios cuando están entre corchetes, pero se desaconsejan enfáticamente)
• postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](IPv6 utiliza una sintaxis diferente)
• _test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](comienza con guión bajo, sintaxis diferente)

• I❤️[email protected]( Los emojis solo están permitidos con SMTPUTF8)

• abc.example.com(sin caracter @)
• a@b@[email protected](solo se permite una @ fuera de las comillas)
• a"b(c)d,e:f;g<h>i[j\k][email protected](ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)
• just"not"[email protected](las cadenas entre comillas deben estar separadas por puntos o ser el único elemento que compone la parte local)
• this is"not\[email protected](los espacios, las comillas y las barras invertidas solo pueden existir dentro de cadenas entre comillas y precedidas por una barra invertida)
• this\ still\"not\\[email protected](incluso si se escapan (precedidos por una barra invertida), los espacios, las comillas y las barras invertidas deben estar contenidos entre comillas)
• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com(la parte local tiene más de 64 caracteres)
• i.like.underscores@but_they_are_not_allowed_in_this_part(no se permite el guión bajo en la parte del dominio)

Esta sección necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo agregando citas de fuentes confiables en esta sección. El material sin fuentes puede ser cuestionado y eliminado. ( Julio de 2019 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Las direcciones de correo electrónico se suelen solicitar como entrada a un sitio web para validar la existencia del usuario. Existen otros métodos de validación, como la validación del número de teléfono móvil, la validación del correo postal y la validación del fax.

En general, se reconoce que una dirección de correo electrónico tiene dos partes unidas por un signo arroba ( @ ), aunque las especificaciones técnicas detalladas en RFC 822 y RFC posteriores son más extensas. ^[32]

Las direcciones de correo electrónico verificadas y sintácticamente correctas no garantizan que exista un buzón de correo electrónico . Por lo tanto, muchos servidores de correo utilizan otras técnicas y comprueban la existencia del buzón de correo en sistemas relevantes, como el Sistema de nombres de dominio del dominio, o utilizan la verificación por devolución de llamada para comprobar si el buzón de correo existe. La verificación por devolución de llamada es una solución imperfecta, ya que puede estar deshabilitada para evitar un ataque de recolección de directorios , o las devoluciones de llamada pueden ser reportadas como spam y dar lugar a la inclusión en una lista de DNSBL .

Se pueden utilizar varias técnicas de validación para validar la dirección de correo electrónico de un usuario. Por ejemplo, ^[33]

• Enlaces de verificación: La validación de direcciones de correo electrónico se realiza a menudo para la creación de cuentas en sitios web mediante el envío de un correo electrónico a la dirección de correo electrónico proporcionada por el usuario con un hipervínculo temporal especial. Al recibirlo, el usuario abre el enlace y activa inmediatamente la cuenta. Las direcciones de correo electrónico también son útiles como medio para enviar mensajes desde un sitio web, por ejemplo, mensajes de usuario, acciones de usuario, a la bandeja de entrada del correo electrónico.
• Estándares formales e informales: RFC 3696 proporciona consejos específicos para validar identificadores de Internet, incluidas las direcciones de correo electrónico. Algunos sitios web, en cambio, intentan evaluar la validez de las direcciones de correo electrónico mediante estándares arbitrarios, como por ejemplo rechazando direcciones que contengan caracteres válidos, como + y / , o imponiendo limitaciones de longitud arbitrarias. La internacionalización de direcciones de correo electrónico permite una gama de caracteres mucho mayor que la que permiten muchos algoritmos de validación actuales, como todos los caracteres Unicode superiores a U+0080, codificados como UTF-8 .
• Herramientas algorítmicas: los sitios web de gran tamaño, los remitentes de correo masivo y los spammers requieren herramientas eficientes para validar las direcciones de correo electrónico. Dichas herramientas dependen de algoritmos heurísticos y modelos estadísticos . ^[34]
• Reputación del remitente: la reputación de un remitente de correo electrónico puede utilizarse para intentar verificar si el remitente es confiable o un posible spammer. Los factores que pueden incorporarse a una evaluación de la reputación del remitente incluyen la calidad del contacto anterior con el remitente o el contenido proporcionado por él, y los niveles de interacción con la dirección IP o la dirección de correo electrónico del remitente.
• Verificación basada en navegador: los formularios HTML5 implementados en muchos navegadores permiten que el navegador gestione la validación de direcciones de correo electrónico. ^[35]

Algunas empresas ofrecen servicios para validar una dirección de correo electrónico, a menudo utilizando una interfaz de programación de aplicaciones , pero no hay garantía de que proporcione resultados precisos.

El IETF dirige un grupo de trabajo técnico y de estándares dedicado a cuestiones de internacionalización de direcciones de correo electrónico, denominado Email Address Internationalization (EAI, también conocido como IMA, Internationalized Mail Address). ^[36] Este grupo produjo los RFC  6530, 6531, 6532 y 6533, y continúa trabajando en otros RFC relacionados con EAI.

El grupo de trabajo EAI de la IETF publicó el RFC 6530 "Descripción general y marco para el correo electrónico internacionalizado", que permitió el uso de caracteres no ASCII tanto en las partes locales como en el dominio de una dirección de correo electrónico. El RFC 6530 prevé el correo electrónico basado en la codificación UTF-8 , que permite el repertorio completo de Unicode . El RFC 6531 proporciona un mecanismo para que los servidores SMTP negocien la transmisión del contenido SMTPUTF8 .

Los conceptos básicos de EAI implican el intercambio de correo en UTF-8. Aunque la propuesta original incluía un mecanismo de degradación para los sistemas heredados, esto ya no se ha incluido. ^[37] Los servidores locales son responsables de la parte local de la dirección, mientras que el dominio estaría restringido por las reglas de los nombres de dominio internacionalizados , aunque seguiría transmitiéndose en UTF-8. El servidor de correo también es responsable de cualquier mecanismo de mapeo entre el formato IMA y cualquier alias ASCII.

EAI permite a los usuarios disponer de una dirección localizada en un conjunto de caracteres o una escritura de un idioma nativo, así como en formato ASCII para comunicarse con sistemas heredados o para un uso independiente de la escritura. Las aplicaciones que reconocen nombres de dominio y direcciones de correo internacionalizados deben tener funciones para convertir estas representaciones.

Se espera una demanda significativa de este tipo de direcciones en China, Japón, Rusia y otros mercados que tienen grandes bases de usuarios en un sistema de escritura no basado en el latín.

Por ejemplo, además del dominio de nivel superior .in , el gobierno de la India en 2011 ^[38] obtuvo la aprobación para ".bharat", (de Bhārat Gaṇarājya ), escrito en siete escrituras diferentes ^{[39] [40]} para su uso por hablantes de gujrati, maratí, bengalí, tamil, telugu, punjabi y urdu. La empresa india XgenPlus.com afirma ser el primer proveedor de buzones de correo EAI del mundo, ^[41] y el gobierno de Rajastán ahora proporciona una cuenta de correo electrónico gratuita en el dominio राजस्थान.भारत para cada ciudadano del estado. ^[42] Una importante empresa de medios de comunicación, Rajasthan Patrika, lanzó su dominio IDN पत्रिका.भारत con correo electrónico contactable.

Las direcciones de ejemplo que se muestran a continuación no se pueden manejar en servidores basados ​​en RFC  5321 sin una extensión, pero sí se pueden manejar con la extensión UTF8SMTP de RFC  6530 y 6531. Los servidores que cumplan con esto podrán manejarlas:

• Alfabeto latino con diacríticos : élé[email protected]
• Alfabeto griego : δοκιμή@παράδειγμα.δοκιμή
• Caracteres chinos tradicionales : 我買@屋企.香港
• Caracteres japoneses : 二ノ宮@黒川.日本
• Caracteres cirílicos : медведь@с-балалайкой.рф
• Personajes devanagari : संपर्क@डाटामेल.भारत

• Técnicas antispam
• Cliente de correo electrónico
• Buzón de correo electrónico
• Autenticación de correo electrónico
• Dirección de correo electrónico que no sea de Internet
• Correo electrónico internacional

• RFC  821 Protocolo simple de transferencia de correo (obsoleto por las RFC 2821 y 5321)
• RFC  822 Estándar para el formato de mensajes de texto de Internet ARPA (obsoleto por RFC 2822) (Fe de erratas)
• RFC  1035 Nombres de dominio, implementación y especificación (Fe de erratas)
• RFC  1123 Requisitos para hosts de Internet, aplicaciones y soporte (actualizado por RFC 2821, RFC 5321) (Fe de erratas)
• RFC  2142 Nombres de buzones de correo para servicios, roles y funciones comunes (Erratas)
• RFC  2821 Protocolo simple de transferencia de correo (obsoleto por RFC 821, actualizado por RFC 1123, obsoleto por RFC 5321) (Fe de erratas)
• RFC  2822 Formato de mensajes de Internet (obsoleto por RFC 822, obsoleto por RFC 5322) (Fe de erratas)
• RFC  3696 Técnicas de aplicación para la comprobación y transformación de nombres (Errata)
• Arquitectura de direccionamiento IP versión 6 de RFC  4291 (actualizada por RFC 5952) (Errata)
• RFC  5321 Protocolo simple de transferencia de correo (RFC 2821 obsoleto, actualizaciones RFC 1123) (Erratas)
• RFC  5322 Formato de mensajes de Internet (obsoleto por RFC 2822, actualizado por RFC 6854) (Fe de erratas)
• RFC  5598 Arquitectura del correo de Internet
• RFC  5952 Recomendación para la representación de texto de direcciones IPv6 (actualiza RFC 4291) (Fe de erratas)
• RFC  6530: descripción general y marco para el correo electrónico internacionalizado (queda obsoleto RFC 4952, 5504 y 5825)
• RFC  6531 Extensión SMTP para correo electrónico internacionalizado (obsoleta RFC 5336)
• RFC  6854 Actualización del formato de mensajes de Internet para permitir la sintaxis de grupo en los campos de encabezado "De:" y "Remitente:" (actualiza RFC 5322)

• Validar dirección de correo electrónico en Wikilibros
• Mejores prácticas en Wikilibros
• Medios relacionados con Dirección de correo electrónico en Wikimedia Commons