El glosario de email que todo desarrollador necesita guardar

El email existe desde los años 70 y se nota. La terminología es un lío de acrónimos, conceptos superpuestos y specs escritas por comités. Si alguna vez te has quedado mirando un mensaje de bounce preguntándote qué significa "550 5.7.1", o has googleado "SPF vs DKIM" por tercera vez en el año, esta página es para ti.

Esto es una referencia. Guárdala. Vuelve cuando la necesites.

Autenticación

SPF (Sender Policy Framework)

Un registro DNS TXT que lista qué direcciones IP y servidores están permitidos a enviar email en nombre de tu dominio. Cuando un servidor receptor recibe un mensaje diciendo ser de yourdomain.com, revisa el registro SPF para ver si el servidor emisor está autorizado.

El registro vive en tu dominio raíz y se ve así:

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Cada directiva include: autoriza los servidores de correo de un servicio. El ~all al final significa "soft-fail de cualquier cosa no listada" (trátalo como sospechoso pero no rechaces). Usa -all para un fallo duro una vez que confíes en que todo está configurado.

SPF tiene un límite estricto de 10 lookups DNS. Excederlo y el registro entero se vuelve inválido. Esto pilla desprevenidos a los equipos cuando usan múltiples herramientas SaaS que cada una agrega sus propias directivas include:.

Relacionado: Cómo configurar SPF, DKIM y DMARC

DKIM (DomainKeys Identified Mail)

Un mecanismo de firma criptográfica. Tu servidor de envío firma cada email saliente con una clave privada. El servidor receptor busca la clave pública correspondiente en tu DNS (publicada como un registro TXT en selector._domainkey.yourdomain.com) y verifica la firma.

Si la firma es válida, se confirman dos cosas: el mensaje vino de tu infraestructura y no fue modificado en tránsito.

Las claves DKIM deben ser de 2048 bits como mínimo. Algunas configuraciones antiguas aún usan claves de 1024 bits, pero los receptores están empezando a marcarlas como débiles.

Cuando agregas un dominio en Sendkit, las claves DKIM se generan automáticamente y son alojadas vía registros CNAME. Esto permite a Sendkit rotar claves en un cronograma sin que toques el DNS.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

La capa de política que une SPF y DKIM. Un registro DMARC le dice a los servidores receptores qué hacer cuando la autenticación falla, y a dónde enviar informes sobre los resultados de autenticación.

v=DMARC1; p=none; rua=mailto:[email protected]

El parámetro p= establece la política:

• p=none -- solo monitorear, sin acción en los fallos. Empieza aquí.
• p=quarantine -- envía los mensajes que fallan a spam.
• p=reject -- rechaza directamente los mensajes que fallan. Este es el objetivo.

El parámetro rua= le dice a los receptores dónde enviar informes agregados (archivos XML mostrando lo que pasó y lo que falló). Estos informes son la única forma de saber si tu autenticación está funcionando antes de endurecer la política.

DMARC también verifica la alineación: el dominio en el header From: debe coincidir con el dominio que pasó SPF o DKIM. Esta es la parte que la mayoría pasa por alto. Un mensaje puede pasar SPF pero aún fallar DMARC si los dominios no se alinean.

BIMI (Brand Indicators for Message Identification)

Un registro DNS que te permite mostrar el logo de tu marca junto a tus emails en bandejas de entrada compatibles. Gmail, Apple Mail y Yahoo lo soportan. BIMI requiere una política DMARC válida de p=quarantine o p=reject y un Verified Mark Certificate (VMC) de una autoridad certificadora.

No mejora la entregabilidad directamente, pero sí aumenta la confianza y el reconocimiento en la bandeja de entrada.

ARC (Authenticated Received Chain)

Un protocolo que preserva los resultados de autenticación cuando los mensajes son reenviados. Las listas de correo y los servicios de reenvío rompen SPF y a veces DKIM. ARC añade headers en cada salto para que el servidor receptor final pueda rastrear la cadena de autenticación de vuelta al remitente original.

Si ejecutas un servicio de reenvío, agregar headers ARC evita que tus mensajes reenviados fallen DMARC en el destino.

Registros DNS

Registro MX (Mail Exchange)

Le dice al mundo qué servidores aceptan email para tu dominio. Cuando alguien envía un mensaje a [email protected], su servidor de correo consulta DNS para registros MX para encontrar dónde entregarlo.

Los registros MX tienen un valor de prioridad. Números más bajos significan mayor prioridad. Si el servidor primario está caído, el remitente intenta con el siguiente.

yourdomain.com.  MX  10  mx1.sendkit.dev.
yourdomain.com.  MX  20  mx2.sendkit.dev.

Sin registros MX significa que nadie puede recibir email en tu dominio. Esto también es lo que verifica la validación de email -- si un dominio no tiene registros MX, cualquier dirección en ese dominio no es entregable.

Registro TXT

Un tipo de registro DNS genérico que contiene datos de texto. Los registros SPF, DKIM y DMARC se almacenan como registros TXT. El servidor receptor sabe cuál es cuál por el prefijo (v=spf1, v=DKIM1, v=DMARC1).

Solo puedes tener un registro TXT SPF por dominio. Dos registros SPF en el mismo dominio hacen que ambos sean inválidos.

Registro PTR (Pointer)

El inverso de un registro A. En vez de mapear un dominio a una dirección IP, un registro PTR mapea una dirección IP de vuelta a un dominio. Los servidores de correo usan lookups DNS inversos para verificar que una IP emisora tiene un registro PTR válido que coincide con el dominio emisor.

Registros PTR faltantes o no coincidentes son una bandera roja para los filtros de spam. Si envías desde una IP dedicada, asegúrate de que el registro PTR esté configurado.

Registro A

Mapea un nombre de dominio a una dirección IPv4. Aunque no es específico de email, el registro A de tu dominio importa porque algunos servidores de correo recurren a él cuando no existen registros MX. Un registro AAAA es lo mismo para IPv6.

Registro CNAME

Un alias que apunta un dominio a otro. Sendkit usa registros CNAME para DKIM para que no tengas que pegar claves públicas en bruto en registros TXT. El CNAME apunta tu sendkit._domainkey.yourdomain.com al DNS de Sendkit, donde la clave real se aloja y se rota automáticamente.

Entregabilidad

Reputación del remitente

Un puntaje de confianza que los proveedores de email (Gmail, Outlook, Yahoo) asignan a tu dominio y dirección IP de envío. Se basa en tasas de bounces, quejas de spam, métricas de engagement y si golpeas spam traps.

Alta reputación significa que tus emails llegan a la bandeja de entrada. Baja reputación significa carpeta de spam o rechazo directo. Una vez dañada, la reputación toma semanas en reconstruirse.

Tasa de bounces

El porcentaje de emails enviados que fallaron al entregar. Hay dos tipos:

• Hard bounce -- fallo permanente. La dirección no existe, el dominio es inválido o el servidor rechazó el mensaje permanentemente. Los hard bounces dañan más la reputación del remitente.
• Soft bounce -- fallo temporal. El buzón del destinatario está lleno, el servidor está caído o el mensaje es demasiado grande. Los soft bounces usualmente se resuelven al reintentar.

Mantén tu tasa de bounces por debajo del 2%. Cualquier cosa por encima del 5% y estás en problemas con la mayoría de proveedores.

Spam trap

Una dirección de email diseñada específicamente para atrapar a remitentes con mala higiene de listas. Hay dos tipos:

• Pristine traps -- direcciones que nunca fueron usadas por una persona real. Existen solo para atrapar scrapers y compradores de listas de email.
• Recycled traps -- direcciones viejas que fueron abandonadas y luego reutilizadas por el proveedor como trampas. Golpearlas significa que no estás limpiando tu lista.

Enviar a spam traps hunde tu reputación rápido. La única defensa es una validación de email adecuada y limpieza regular de listas.

IP warming

El proceso de aumentar gradualmente el volumen de email desde una nueva dirección IP o dominio. Los ISPs sospechan de remitentes nuevos lanzando alto volumen desde el día uno. El warming construye confianza mostrando comportamiento de envío consistente y con pocas quejas durante semanas.

Un cronograma típico de warm-up empieza con unos pocos cientos de emails por día y duplica cada pocos días hasta que alcanzas tu volumen objetivo. Sáltalo y probablemente serás throttled o bloqueado.

Lista de supresión

Una lista de direcciones de email a las que nunca deberías enviar. Esto incluye direcciones que hicieron hard bounce, presentaron quejas de spam o se dieron de baja. Sendkit gestiona las listas de supresión automáticamente -- los bounces y quejas son suprimidos sin que escribas código.

Ignorar la supresión es una de las formas más rápidas de destruir la entregabilidad.

Feedback loop (FBL)

Un mecanismo donde los ISPs notifican a los remitentes cuando los destinatarios marcan su email como spam. Cuando un usuario hace clic en "Reportar como spam" en Gmail u Outlook, el ISP envía un informe de vuelta al remitente (si está registrado para el FBL).

Deberías procesar estos informes e inmediatamente suprimir la dirección que se queja. Seguir enviando a personas que se quejaron es una forma garantizada de dañar tu reputación.

SMTP y protocolo

SMTP (Simple Mail Transfer Protocol)

El protocolo usado para enviar email entre servidores. Existe desde 1982 (RFC 821, actualizado por RFC 5321). SMTP usa una serie de comandos de texto (HELO, MAIL FROM, RCPT TO, DATA) para transferir mensajes.

El SMTP moderno usa cifrado TLS. El puerto 587 con STARTTLS es el estándar para submission. El puerto 465 usa TLS implícito. El puerto 25 es para relay servidor-a-servidor y suele ser bloqueado por los ISPs para conexiones de consumidor.

El SMTP relay de Sendkit acepta conexiones en los puertos 587 y 465 y funciona como reemplazo directo de cualquier proveedor SMTP.

Envelope sender (Return-Path)

La dirección de email usada durante el handshake SMTP (el comando MAIL FROM). Esto es diferente del header From: que ve el destinatario. Las notificaciones de bounce van a la dirección del envelope sender, razón por la cual también se le llama return-path o dirección de bounce.

La distinción importa para la alineación DMARC. SPF verifica el dominio del envelope sender, no el dominio del header From:.

Handshake SMTP

La conversación de ida y vuelta entre dos servidores de correo al entregar un mensaje:

1. EHLO/HELO -- el servidor emisor se identifica.
2. MAIL FROM -- especifica el envelope sender.
3. RCPT TO -- especifica el destinatario.
4. DATA -- el contenido real del mensaje (headers + cuerpo).
5. QUIT -- cierra la conexión.

Los servicios de validación de email realizan un handshake parcial (hasta RCPT TO) para verificar si un buzón existe sin enviar realmente un mensaje.

TLS (Transport Layer Security)

Cifrado para datos en tránsito. Cuando dos servidores de correo se comunican por TLS, el contenido del mensaje está cifrado entre ellos. Esto no significa que el mensaje esté cifrado de extremo a extremo (los servidores mismos aún pueden leerlo), pero evita escuchas en el cable.

STARTTLS actualiza una conexión existente de texto plano a cifrada. El TLS implícito (puerto 465) empieza cifrado desde el principio.

MIME (Multipurpose Internet Mail Extensions)

El estándar que permite al email llevar más que texto plano. MIME define cómo codificar adjuntos, contenido HTML, imágenes inline y conjuntos de caracteres. Cuando envías un email con versiones HTML y de texto plano, MIME maneja la estructura multipart.

Anatomía del mensaje

Header From

La dirección de email mostrada al destinatario. Esto es lo que las personas ven en su bandeja de entrada. Es establecido por el remitente y técnicamente puede ser cualquier cosa, lo cual es exactamente por qué existen SPF, DKIM y DMARC -- para verificar que es legítimo.

Header Reply-To

Un header opcional que le dice a los clientes de email dónde enviar las respuestas. Si no está configurado, las respuestas van a la dirección From:. Útil cuando envías desde [email protected] pero quieres que las respuestas vayan a [email protected].

Message-ID

Un identificador único asignado a cada email. Se ve como <[email protected]>. Los Message-IDs se usan para hilar conversaciones y para rastrear el estado de entrega entre sistemas.

Headers de email

Metadatos adjuntos a cada mensaje de email. Los headers incluyen información de enrutamiento (Received), resultados de autenticación (Authentication-Results), tipo de contenido (Content-Type) y más. Cuando depuras problemas de entregabilidad, los headers sin procesar son el primer lugar a mirar.

La mayoría de los clientes de email te permiten ver los headers sin procesar. Busca Authentication-Results para verificar el estado de SPF, DKIM y DMARC.

Conceptos de envío

Email transaccional

Mensajes disparados por una acción del usuario: resets de contraseña, confirmaciones de pedido, códigos de login, recibos de factura. Estos son esperados por el destinatario y típicamente tienen altas tasas de apertura. Necesitan llegar rápido y de forma fiable.

El email API de Sendkit está construido para email transaccional -- envía vía REST API o SMTP con entrega rastreada a través de webhooks.

Email de marketing (email masivo)

Mensajes enviados a una lista de suscriptores: newsletters, promociones, anuncios de productos. A diferencia del email transaccional, los destinatarios no solicitaron explícitamente cada mensaje individual. El email de marketing requiere consentimiento apropiado (opt-in) y debe incluir un enlace para darse de baja.

Webhook

Un callback HTTP que notifica a tu aplicación cuando algo sucede. En el contexto del email, los webhooks te dicen cuando un mensaje es entregado, abierto, clicado, rebotado o marcado como spam. En vez de hacer polling de una API por el estado, el proveedor de email empuja eventos a tu endpoint en tiempo real.

Validación de email

El proceso de verificar si una dirección de email es entregable antes de enviarle. Un stack de validación adecuado incluye verificaciones de sintaxis, lookups DNS/MX, detección de email desechable y verificación de buzón SMTP.

La API de validación de email de Sendkit ejecuta todas estas verificaciones en una sola solicitud. Validar en el punto de captura evita que direcciones malas entren a tu base de datos en primer lugar.

Relacionado: Cómo validar direcciones de email antes de enviar

IP dedicada vs IP compartida

Una IP compartida es usada por múltiples remitentes en el mismo proveedor de email. Tu reputación es parcialmente influenciada por el comportamiento de otros remitentes en esa IP. Buena para remitentes de bajo volumen.

Una IP dedicada te es asignada exclusivamente. Tu reputación es completamente tuya. Mejor para remitentes de alto volumen (100K+ emails/mes) que mantienen listas limpias. Requiere warming de IP antes de usarse.

Cumplimiento

CAN-SPAM

Ley de EE.UU. que rige el email comercial. Requisitos: incluir tu dirección física, proveer un mecanismo claro para darse de baja, honrar las solicitudes de opt-out dentro de 10 días hábiles, no usar líneas de asunto engañosas. Aplica al email de marketing, no al transaccional.

GDPR (General Data Protection Regulation)

Regulación de la UE que rige cómo se recopilan, almacenan y procesan los datos personales (incluyendo direcciones de email). Requiere consentimiento explícito para email de marketing, el derecho al olvido y portabilidad de datos. Las violaciones conllevan multas de hasta el 4% de los ingresos globales.

LGPD (Lei Geral de Protecao de Dados)

Ley de protección de datos de Brasil, similar al GDPR. Requiere una base legal para procesar datos personales, consentimiento para comunicaciones de marketing y da a los individuos el derecho a acceder y eliminar sus datos.

Opt-in / double opt-in

Single opt-in significa que un usuario provee su dirección de email y es añadido inmediatamente a tu lista. Double opt-in (opt-in confirmado) envía primero un email de confirmación -- el usuario debe hacer clic en un enlace para verificar su dirección antes de ser añadido.

El double opt-in produce listas más limpias y protege contra errores tipográficos y signups falsos. Es requerido por ley en algunas jurisdicciones (Alemania, por ejemplo) y altamente recomendado en todas partes.

Códigos de estado comunes

Cuando un email falla al entregarse, el mensaje de bounce incluye un código de estado SMTP. Aquí están los que verás más:

• 250 -- éxito. El mensaje fue aceptado.
• 421 -- servicio no disponible. Intenta de nuevo más tarde (temporal).
• 450 -- buzón no disponible. Usualmente temporal (buzón lleno, servidor ocupado).
• 451 -- error local en el procesamiento. Intenta de nuevo más tarde.
• 452 -- almacenamiento insuficiente. El servidor se quedó sin espacio.
• 550 -- buzón no encontrado. La dirección no existe (hard bounce).
• 551 -- usuario no local. El servidor no maneja correo para esta dirección.
• 552 -- mensaje demasiado grande. Reduce el tamaño del adjunto o el contenido.
• 553 -- nombre de buzón no permitido. Usualmente un problema de sintaxis.
• 554 -- transacción fallida. Rechazo genérico, a menudo relacionado con spam.

El código de tres dígitos a veces va seguido de un código de estado mejorado como 5.7.1 (entrega no autorizada) que da contexto más específico.

Cerrando

La terminología de email está dispersa en décadas de RFCs, documentación de proveedores y conocimiento tribal. Este glosario cubre los términos que realmente encontrarás al configurar infraestructura de email, depurar entregabilidad o construir aplicaciones que envían correo.

Si algo falta, probablemente merece su propio artículo. Revisa el blog de Sendkit para análisis profundos de temas específicos, o la documentación para detalles de implementación.