Guía Red Sift de configuración de protocolos de correo electrónico

En este capítulo respondemos a algunas de las preguntas más comunes que nuestros Ingenieros de Éxito del Cliente reciben sobre SPF, DKIM y DMARC, los tres pilares de la autenticación de correo electrónico moderna. A partir de 2026, estos protocolos serán requeridos por los principales proveedores de bandeja de entrada para los remitentes masivos. ¡Vamos a ello!

SPF (Sender Policy Framework) es un estándar de autenticación de correo electrónico desarrollado para combatir la suplantación de direcciones del remitente. Al verificar la autenticidad de las identidades MAIL FROM o HELO/EHLO durante la transmisión, SPF compara la dirección IP del servidor remitente con una lista de remitentes autorizados especificada en un registro TXT dentro del DNS del propietario del dominio. Si la dirección IP remitente coincide con la lista autorizada, la autenticación SPF es exitosa. 

SPF se enfoca en el "dominio" que se encuentra en el encabezado del correo electrónico, conocido con varios nombres como Return-Path, MAIL-FROM, dirección de rebote o Envelope from. Si este encabezado falta, SPF recurre al nombre de host “HELO/EHLO” y busca ahí un registro SPF.

El encabezado Return-Path es un encabezado técnico que no es visible para el usuario final; a menos que sepa cómo mostrar los encabezados de un correo en su cliente de correo electrónico, no lo verá. 

DKIM (DomainKeys Identified Mail) se utiliza para firmar diferentes campos del encabezado y los cuerpos de los mensajes para autenticar el dominio remitente y evitar que el mensaje se modifique durante el tránsito.

Esto se logra mediante criptografía asimétrica, que consiste en una combinación de claves públicas y privadas. La clave privada es exclusiva del dominio del remitente y se utiliza para firmar los correos. La clave pública se publica en el DNS del remitente para que pueda ser recuperada por cualquier persona que reciba mensajes de ese remitente.

Cuando se compone un correo electrónico, sus encabezados y cuerpo se firman usando la clave privada del remitente para crear una firma digital, la cual se envía también como un campo de encabezado junto con el correo. En el lado receptor (si DKIM está habilitado), el servidor recupera la clave pública y verifica si el correo realmente fue firmado por el dominio remitente. Si la validación de la firma es exitosa, se demuestra que el dominio remitente envió el mensaje y que los encabezados y el cuerpo no se modificaron durante la transmisión.

DKIM se centra en el encabezado “DKIM-Signature”.

Al igual que con SPF, este encabezado no es visible para el usuario final, a menos que sepa cómo mostrar los encabezados del correo electrónico recibido.

1. La mayoría de los problemas de autenticación de correo electrónico se deben a los mismos errores. Si aciertas con estos tres puntos, solucionarás el 90% de los dolores de cabeza de entregabilidad y seguridad.
2. Publica un registro DMARC en p=reject Comienza en p=none para recopilar informes, pero no te quedes ahí. Una política solo de monitorización no te protege. Cambia a p=reject cuando hayas identificado y configurado a todos tus remitentes legítimos. Esto indica a los servidores receptores que bloqueen los correos electrónicos que no pasen la autenticación.
3. Asegúrate de que SPF y DKIM se alinean con tu dominio From: Tanto SPF como DKIM pueden pasar y aun así fallar DMARC si los dominios no coinciden. Verifica que el dominio Return-Path (para SPF) y el dominio de firma de DKIM (d=) coincidan o sean subdominios de tu dirección From: visible. Aquí es donde la mayoría de las organizaciones tienen problemas.
4. Monitorea tus informes DMARC semanalmente Los informes DMARC te dicen exactamente quién está enviando correo en tu nombre y si está pasando la autenticación. Usa una plataforma como Red Sift OnDMARC para convertir XML crudo en datos accionables. Identifica configuraciones erróneas antes de que se conviertan en problemas de entregabilidad.

Por qué SPF y DKIM no son suficientes: Aunque DKIM puede verificar que el correo no haya sido alterado y SPF puede recomendar a un servidor receptor que rechace un correo en función de la IP, ninguno de los dos es efectivo para prevenir la suplantación. Por esto mismo, DMARC se vuelve obligatorio para organizaciones que envían correos masivos en 2026.

La razón principal es el encabezado que se verifica en cada protocolo.

SPF verifica el registro encontrado en el dominio del encabezado return-path, y DKIM verifica la clave encontrada en el dominio d= (dentro del encabezado DKIM).

Ambos protocolos anteriores pueden configurarse para verificar cualquier dominio.

En un correo, el dominio principal del remitente es el que se encuentra en el encabezado From:, es decir, el que aparece como gran nombre en la parte superior de los correos, la dirección visible para el destinatario.

Dicho esto, tu dominio de correo podría ser suplantado, ya que los atacantes pueden poner en From: yourdomain.com y en return-path y d= su propio dominio. Si los registros SPF y DKIM de su dominio están correctamente configurados, el correo pasarán tanto SPF como DKIM y lograrán suplantar el dominio.

SPF y DKIM tienen su utilidad, pero ninguno por sí solo previene la imitación.

DMARC significa Domain-based Message Authentication, Reporting and Conformance y se basa en SPF y DKIM, aportando una capa adicional de autenticación y aplicación de políticas. DMARC es ahora requisito de los principales proveedores de correo y representa el estándar de la industria para la autenticación de correos en 2026.

DMARC hace varias cosas:

1. Tiene en cuenta los resultados de SPF y DKIM
2. Para que DMARC pase, requiere que SPF o DKIM pasen y que el dominio utilizado por al menos uno también se alinee con el dominio en la dirección From:. Si quieres saber más sobre la alineación de identificadores, haz clic aquí.
3. Reporta los resultados de SPF, DKIM y DMARC de vuelta al dominio que aparece en la dirección From: (es decir, el remitente).
4. Por último, indica a los servidores receptores cómo tratar los correos que no pasan la validación DMARC, especificando una política en DNS.

Al establecer la política DMARC en p=reject, una organización puede recomendar a los servidores receptores que bloqueen los correos enviados en su nombre que no pasen la comprobación de alineación. Esto detendrá cualquier intento de imitación siempre que el servidor receptor implemente correctamente DMARC.

DMARC se enfoca en el dominio que aparece en el encabezado From: o Header from, el cual es visible para el usuario final. 

SPF verifica si un correo fue enviado por un remitente autorizado revisando una lista de direcciones IP autorizadas que publicas en tu DNS. El servidor receptor toma el dominio del encabezado Return-Path y busca un registro SPF existente. Revisa si la dirección IP remitente está incluida en el registro SPF. Si la dirección IP está en el registro SPF, significa que está autorizada para enviar correos: SPF APRUEBA. Si no está, SPF FALLA.

La lógica general es:

• Si la IP remitente está en el registro SPF = SPF APRUEBA
• Si la IP remitente no está en el registro SPF = SPF FALLA

El servidor receptor revisa el encabezado DKIM-Signature, que contiene el selector (s=) y el dominio de firma (d=), etiquetas que se utilizan para buscar la clave pública. Una vez recuperada, se usa la clave pública para validar el mensaje. Si la validación es exitosa, DKIM APRUEBA; si es fallida, DKIM FALLA.

La lógica general es:

• Si la validación es exitosa = DKIM APRUEBA
• Si la validación es fallida = DKIM FALLA

El servidor receptor comprobará si SPF o DKIM APROBARON; después, revisará si el dominio Return-Path usado por SPF y/o el dominio d= usado por DKIM se alinean con el dominio From:; por último, extraerá la política DMARC publicada por el dominio de la “From” address y aplicará dicha política.

La lógica general es:

• Si SPF APRUEBA y SE ALINEA con el dominio “From” = DMARC APRUEBA, o
• Si DKIM APRUEBA y SE ALINEA con el dominio “From” = DMARC APRUEBA
• Si tanto SPF como DKIM FALLAN = DMARC FALLA

DMARC no solo requiere que SPF o DKIM APRUEBEN, sino que también exige que los dominios usados por cualquiera de los dos SE ALINEEN con el dominio de la 

dirección “From”. Solo así DMARC aprobará.

Alineación estricta significa que el dominio Return-Path o el dominio de firma “d=” deben coincidir exactamente con el dominio de la dirección “From”.

Alineación relajada significa que Return-Path o el dominio d= pueden ser un subdominio de la dirección “From” y viceversa.

Si quieres saber más sobre alineación de identificadores, haz clic aquí.

Si DMARC falla, el servidor receptor generalmente aplicará la política que hayas especificado en tu registro DMARC.

• Si estás en modo solo informe (p=none), el correo será aceptado y pasará por otros filtros.
• Si estás en modo cuarentena (p=quarantine), el correo será puesto en cuarentena y normalmente enviado a la carpeta de spam.
• Si estás en modo rechazo (p=reject), el servidor receptor cortará la conexión con el servidor remitente y el correo nunca llegará al destinatario.

Independientemente de la política, los metadatos del correo serán registrados junto con el estado de los resultados de autenticación y enviados a tu procesador de informes DMARC. Descubre más sobre los informes DMARC aquí.

1. Asegúrate de tener un registro SPF en tu dominio Return-Path.
2. Asegúrate de tener un registro SPF en tu dominio HELO/EHLO en caso de rebotes cuando Return-Path esté vacío.
3. Asegúrate de que solo haya un registro SPF por dominio.
4. Asegúrate de que la sintaxis del registro SPF sea correcta.
5. Asegúrate de que tu dominio Return-Path se alinea con el dominio From.
6. Asegúrate de que tus remitentes autorizados estén en el registro SPF.
7. Asegúrate de que los remitentes no autorizados no estén en tu registro SPF.
8. Asegúrate de no superar el límite de 10 búsquedas DNS impuesto por SPF. Si lo excedes, considera usar una función como Dynamic SPF de Red Sift’s OnDMARC.
9. Asegúrate de no usar mecanismos obsoletos en el registro SPF, como el mecanismo “ptr”.

1. Asegúrate de que los sistemas de envío que utilizas son compatibles con DKIM.
2. Asegúrate de que los correos estén firmados con DKIM.
3. Asegúrate de que el dominio de firma se alinea con el dominio “From”.
4. Asegúrate de usar una clave DKIM superior a 1024 bits (se recomienda una de 2048 bits)
5. Procura que los selectores DKIM que utilices identifiquen claramente el servicio de envío para poder distinguirlos.
6. Revoca cualquier clave que haya sido comprometida.
7. Rota regularmente las claves DKIM que administres.
8. Verifica que la sintaxis de las claves DKIM sea correcta.
9. Asegúrate de que existe una clave pública para cada clave privada que firma tus correos.

1. Como DMARC se basa tanto en SPF como en DKIM y los dominios que usan estos protocolos, asegúrate de que el dominio Return-Path para SPF sea idéntico o subdominio del dominio “From”. Lo mismo aplica para el dominio de firma usado por DKIM. Una correcta configuración de alineación será clave en la entregabilidad de correos en 2026.
2. Que la sintaxis del registro DMARC sea la correcta.
3. Configura todos tus sistemas correctamente con SPF y DKIM antes de pasar a una política de rechazo; de lo contrario, tus correos se perderán.
4. Emplea un sistema o proveedor externo como Red Sift OnDMARC para recibir los informes DMARC, interpretar esos informes y descubrir sistemas mal configurados. Las plataformas DMARC modernas en 2026, como OnDMARC, permiten alcanzar la aplicación total en 6-8 semanas gracias a su resolución automática y pruebas en tiempo real.
5. Monitorea el estado de cada una de tus fuentes de envío y verifica que cualquier cambio en SPF o DKIM sea detectado. Red Sift OnDMARC incorpora esta función en su producto.