Puntos clave

  • SPF (RFC 7208): Publica la lista de direcciones IP y servicios de envío autorizados a enviar correo usando tu dominio en el remitente del sobre (Return-Path).
  • DKIM (RFC 6376): Usa un par de claves asimétricas para añadir una firma criptográfica a cada mensaje, lo que demuestra que el dominio firmante lo autorizó y que no se alteró en tránsito.
  • DMARC (RFC 7489): Indica a los servidores receptores qué hacer con el correo que no supera la alineación de SPF y DKIM (none, quarantine o reject) y a dónde enviar los informes agregados.
  • Desde febrero de 2024, Gmail y Yahoo exigen a los remitentes masivos (Gmail los define como quienes envían más de 5.000 mensajes al día a cuentas personales de Gmail) autenticarse con SPF y DKIM, publicar un registro DMARC (como mínimo p=none) y alinear el dominio del From con SPF o DKIM.

Cuando un servidor de correo receptor, como Google Workspace, Microsoft 365 o Yahoo Mail, acepta un mensaje de contact@yourcompany.com, su sistema de filtrado ejecuta una serie de comprobaciones técnicas para decidir si el mensaje procede realmente del propietario legítimo de ese dominio o si se trata de un intento de suplantación o phishing.

Si a tu dominio le faltan los registros de autenticación necesarios en el DNS (Domain Name System), el mensaje se considera de alto riesgo. Lo más probable es que acabe en la carpeta de spam o que se rechace directamente a nivel SMTP, algo que tu plataforma de envío registra como un rebote.

1. Los tres mecanismos fundamentales de autenticación del correo

Para entender cómo funcionan en conjunto los sistemas de seguridad del correo, conviene analizar el papel distinto, pero complementario, que cumple cada protocolo:

SPF (Sender Policy Framework)

SPF funciona como una lista de autorizados pública, publicada en tu DNS. El registro declara qué servidores, identificados por dirección IP o mediante un mecanismo include que apunta a un proveedor como Amazon SES, SendGrid o Mailgun, pueden enviar correo en nombre de tu dominio. Los receptores verifican SPF frente al dominio del remitente del sobre (MAIL FROM / Return-Path), no frente a la dirección From visible.

DKIM (DomainKeys Identified Mail)

DKIM verifica la integridad del mensaje. Cuando un mensaje sale del servidor de envío, se genera una firma digital con una clave privada y se añade al mensaje como cabecera DKIM-Signature. El servidor receptor obtiene la clave pública correspondiente de tu DNS y la usa para verificar la firma, lo que confirma que las cabeceras firmadas y el cuerpo no se falsificaron ni se modificaron por el camino.

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

DMARC es la capa que une SPF y DKIM. Exige al servidor receptor comprobar si el dominio de la dirección del remitente visible (el Header From) coincide con el dominio autenticado por SPF o DKIM, una comprobación conocida como alineación. Un mensaje supera DMARC si al menos uno de los dos pasa y está alineado. DMARC también define qué debe hacer el receptor cuando la autenticación falla y ofrece un canal para los informes agregados (RUA).

2. Estructura y sintaxis del registro SPF

Un registro SPF se publica como registro TXT en el dominio usado en el remitente del sobre. Para el correo enviado desde tus propios servidores o desde Google Workspace, suele ser el dominio raíz:

Record Type: TXT
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all

Qué significa cada parte del registro:

  • v=spf1: Declara la versión de SPF en uso. Debe ser el primer término del registro.
  • include:amazonses.com: Autoriza los rangos de IP de envío de Amazon Simple Email Service (SES) a enviar correo para el dominio. Si también usas SendGrid, el equivalente es include:sendgrid.net. Ten en cuenta que, con Amazon SES, SPF solo se alinea para DMARC cuando configuras un subdominio MAIL FROM personalizado (por ejemplo, bounce.yourcompany.com) y publicas este registro en ese subdominio junto con el registro MX que proporciona SES. Con la autenticación de dominio de SendGrid y la seguridad automatizada activadas, SendGrid gestiona el SPF de su subdominio de return-path mediante un CNAME, por lo que no hace falta un include en el dominio raíz.
  • ~all (SoftFail): Indica que el correo de servidores que no figuran en la lista debe tratarse como sospechoso, aunque por lo general se sigue aceptando. Es la opción más habitual, sobre todo mientras sigues inventariando tus fuentes de envío.
  • -all (HardFail): Indica que el correo de fuentes no autorizadas debe tratarse como un fallo definitivo. Los receptores pueden rechazarlo, aunque muchos grandes proveedores de buzones ahora ponderan el resultado de DMARC en lugar de rechazar solo por SPF.
Nota técnica importante: Según el RFC 7208, un dominio debe publicar un único registro SPF; tener varios provoca un error permanente (permerror). La evaluación también está limitada a 10 consultas DNS (se cuentan include, a, mx, ptr, exists y redirect, incluidas las consultas anidadas). Si varios servicios envían desde el mismo dominio (por ejemplo, Google Workspace y Amazon SES), combínalos en un solo registro: v=spf1 include:_spf.google.com include:amazonses.com ~all.

3. Configuración de DKIM

La configuración de DKIM suele implicar generar un par de claves RSA; las claves de 2048 bits son el mínimo recomendado hoy en día. Cuando conectas un proveedor de envío a través de eMailBase:

  1. El proveedor genera los registros DNS de sus selectores DKIM. Easy DKIM de Amazon SES emite tres registros CNAME con el formato <token>._domainkey.yourcompany.com; SendGrid emite dos registros CNAME de DKIM (s1._domainkey y s2._domainkey) más uno para su subdominio de return-path; Mailgun suele proporcionar un registro TXT que contiene la clave pública.
  2. Inicia sesión en el panel de control de tu proveedor de DNS y crea cada registro exactamente como se emitió.
  3. eMailBase consulta el DNS automáticamente y confirma la activación en cuanto los registros se han propagado.

4. Cómo implantar la aplicación de DMARC de forma segura

Publicar una política DMARC estricta desde el primer día puede provocar el rechazo de correo legítimo si alguna fuente de envío aún no está totalmente cubierta por SPF o DKIM. El registro DMARC se publica como registro TXT en _dmarc.yourcompany.com, y la implantación estándar tiene tres fases:

Fase Sintaxis de la política Objetivo operativo
Fase 1: Monitorización v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com Recopilar informes agregados e identificar todas las fuentes de envío legítimas sin afectar a la entrega.
Fase 2: Cuarentena v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com Aplicar la política de cuarentena (normalmente, entrega en spam) al 25 % de los mensajes que fallan y aumentar el porcentaje a medida que los informes confirmen que el correo legítimo pasa. El soporte de pct varía según el receptor, y la revisión DMARCbis del estándar lo elimina.
Fase 3: Rechazo v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com Indicar a los receptores que rechacen todo el correo que no supere DMARC, bloqueando el uso no autorizado de tu dominio.

5. Verificación y solución de problemas de tus registros DNS

Una vez publicados los registros, puedes comprobarlos con herramientas estándar de línea de comandos:

# Check the SPF record
dig +short TXT yourcompany.com

# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com

# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com

En un espacio de trabajo de eMailBase, estas comprobaciones se ejecutan automáticamente a través del DNS & Deliverability Manager, que señala los conflictos de sintaxis y los registros que faltan en cuanto aparecen.

Más información sobre el envío responsable en la Política antispam de eMailBase.