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

En este capítulo, hemos respondido algunas de las preguntas más frecuentes que nuestros Ingenieros de Éxito del Cliente reciben sobre SPF, DKIM y DMARC: los tres pilares de la autenticación moderna de correo electrónico. A partir de 2026, estos protocolos serán obligatorios por parte de los principales proveedores de buzones para quienes envíen correos electrónicos masivos. ¡Vamos allá!

Utiliza esto para verificar que has cubierto lo esencial. Márcalos en orden; cada paso depende del anterior.

1. Publica un único registro SPF TXT en tu dominio Return-Path
2. Confirma que cada IP emisora legítima esté incluida en el registro
3. Verifica que no has superado el límite de 10 consultas DNS (usa el SPF Checker de Red Sift para comprobarlo)
4. Usa ~all (soft fail), no -all, para que DMARC gestione la aplicación
5. Asegúrate de que el dominio Return-Path esté alineado con tu dominio From: visible

1. Confirma que todos los servicios de envío soporten y firmen activamente con DKIM
2. Utiliza un tamaño de clave de 2048 bits o superior
3. Verifica que el dominio de firma (d=) esté alineado con tu dominio From:
4. Nombrar los selectores de forma clara para identificar cada servicio de envío
5. Rota las claves regularmente y revoca cualquier clave comprometida

1. Publica un registro DMARC TXT; comienza con p=none para recopilar reportes
2. Enlaza rua= a un procesador de reportes (ej. Red Sift OnDMARC) para convertir los datos agregados en información útil
3. Revisa los reportes semanalmente para identificar remitentes desconocidos o mal configurados
4. Cuando todas las fuentes legítimas pasen SPF o DKIM con alineación, avanza a p=quarantine
5. Pasa a p=reject para bloquear completamente los correos falsificados; apunta a 6–8 semanas con la herramienta adecuada

Bonus: Seguridad en el transporte

1. Implementa MTA-STS primero en modo de pruebas, luego pasa a modo enforcement tras revisar los reportes TLS
2. Agrega TLS-RPT para tener visibilidad sobre los fallos de entrega causados por problemas con TLS

SPF (Sender Policy Framework) es un estándar de autenticación de correo electrónico diseñado para combatir la suplantación de direcciones del remitente. Verificando la autenticidad de las identidades MAIL FROM o HELO/EHLO durante la transmisión, SPF compara la dirección IP del servidor de envío con una lista de remitentes autorizados, especificada en un registro TXT dentro del DNS del propietario del dominio. Si la IP emisora está alineada con la lista autorizada, la autenticación SPF tendrá éxito. 

SPF se centra en el "dominio" que aparece en la cabecera del correo electrónico, conocido por nombres como Return-Path, MAIL-FROM, dirección Bounce o Envelope from. Si falta esta cabecera, SPF recurre al hostname “HELO/EHLO” y busca un registro SPF allí.

La cabecera Return-Path es una cabecera técnica que no es visible para el usuario final; salvo que sepa cómo mostrar las cabeceras de un correo en su cliente de correo, no la verá. 

DKIM (DomainKeys Identified Mail) se utiliza para firmar diferentes campos del encabezado y el cuerpo de los mensajes para autenticar el dominio remitente y prevenir la modificación del mensaje durante el tránsito.

DKIM logra esto usando criptografía asimétrica, que consiste en una combinación de claves públicas y privadas. La clave privada es exclusiva del dominio remitente y se utiliza para firmar los correos electrónicos. La clave pública se publica en el DNS del remitente para que cualquier receptor pueda recuperarla.

Cuando se compone un correo, sus cabeceras y cuerpo se firman usando la clave privada del remitente para crear una firma digital, que se envía como un campo de cabecera junto con el correo. En el lado del receptor (si DKIM está habilitado), el servidor recupera la clave pública y verifica si el correo efectivamente fue firmado por el dominio remitente. Si la validación de la firma es exitosa, se prueba que el dominio remitente envió el mensaje y que las cabeceras y el cuerpo no han sido modificados durante la transmisión.

DKIM se centra en la cabecera “DKIM-Signature”.

Como ocurre con SPF, esta cabecera no es visible al usuario final salvo que sepa cómo visualizar las cabeceras del correo recibido.

1. La mayoría de los problemas de autenticación de correo electrónico se deben a los mismos fallos. Si logras estos tres puntos, resolverás el 90% de los dolores de cabeza de entregabilidad y seguridad.
2. Publica un registro DMARC en p=reject Empieza en p=none para recopilar informes, pero no te quedes ahí. Una política solo de monitorización no te protege. Avanza a p=reject una vez que hayas identificado y configurado todos los remitentes legítimos. Así indicas a los servidores receptores que bloqueen los correos que no pasen la autenticación.
3. Asegúrate de que SPF y DKIM estén alineados con tu dominio From: Ambos pueden validar y aun así fallar DMARC si los dominios no coinciden. Comprueba que tu dominio Return-Path (para SPF) y el dominio de firma DKIM (d=) coincidan o sean subdominios de tu dirección From: visible. Aquí es donde la mayoría de las organizaciones quedan atascadas.
4. Monitorea tus informes DMARC semanalmente Los informes DMARC indican exactamente quién envía emails en tu nombre y si pasan la autenticación. Usa una plataforma como Red Sift OnDMARC para convertir XML en datos útiles. Detecta errores de configuración antes de que creen problemas de entregabilidad.

Por qué SPF y DKIM no son suficientes Aunque DKIM puede verificar que un correo no es exactamente el mensaje que se envió, y SPF puede recomendar que el servidor receptor rechace un correo según la IP, ninguno de estos resulta efectivo para prevenir suplantaciones. Por eso DMARC es obligatorio para las organizaciones que envían correos masivos en 2026.

La razón principal es la cabecera que se verifica en cada protocolo.

SPF revisa el registro hallado en el dominio Return-Path y DKIM comprueba la clave encontrada en el dominio d= (en la cabecera DKIM).

Ambos protocolos anteriores pueden configurarse para revisar cualquier dominio.

En un correo electrónico, el dominio principal del remitente es el que está en la cabecera From:; esta cabecera determina el nombre que aparece arriba en los emails (el que verá el usuario final si revisa el remitente del correo).

Dicho esto, tu dominio de correo podría ser suplantado ya que los atacantes pueden poner en From: tu dominio (yourdomain.com) pero en Return-Path y d= su dominio (theirdomain.com). Siempre que los registros SPF y DKIM de theirdomain.com estén correctamente configurados, el correo pasaría ambas pruebas y daría como resultado una suplantación exitosa de tu dominio.

SPF y DKIM tienen finalidades útiles, pero ninguno por sí solo previene la suplantación.

DMARC significa Domain-based Message Authentication, Reporting and Conformance y se basa sobre SPF y DKIM, añadiendo una capa adicional de autenticación y políticas al correo electrónico. DMARC ahora es obligatorio para los principales proveedores de buzones y representa el estándar de la industria para autenticación de correo en 2026.

DMARC hace varias cosas:

1. Toma en cuenta los resultados de SPF y DKIM 
2. Para que DMARC apruebe, se requiere que SPF o DKIM pasen y que el dominio usado en cualquiera de ambos esté alineado con el “From:”. Si quieres saber más sobre Alineación de Identificadores, haz clic aquí.
3. Reporta los resultados de SPF, DKIM y DMARC al dominio encontrado en el From: (remitente)
4. Finalmente, indica a los receptores cómo tratar los correos que fallen 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 rechacen todos los correos enviados en su nombre que no pasen la alineación. Esto detendrá todos los intentos de suplantación siempre que el servidor receptor implemente DMARC correctamente.

DMARC se centra en el dominio hallado en la cabecera From: o Header from, el cual es visible para el usuario final. 

SPF verifica si un correo fue enviado por un remitente autorizado comprobando una lista de IP autorizadas que publicas en tu DNS. El servidor receptor toma el dominio de la cabecera Return-Path y comprueba si existe un registro SPF. Verifica si la IP emisora del correo está incluida en el registro SPF. Si la IP está en el registro SPF, está autorizada para enviar correos. Esto significa que SPF PASÓ. Si la IP no está en el registro, SPF FALLA.

La lógica general es:

• Si la dirección IP emisora está en el registro SPF = SPF APRUEBA
• Si la dirección IP emisora no está en el registro SPF = SPF FALLA

El servidor receptor revisará la cabecera DKIM-Signature, que contiene el selector (s=) y el dominio de firma (d=), etiquetas que se usan para buscar la clave pública. Una vez recuperada, la clave pública valida el mensaje. Si la validación es correcta, DKIM APRUEBA; si no, DKIM FALLA.

La lógica general es:

• Si la validación es correcta = DKIM APRUEBA
• Si la validación no es correcta = DKIM FALLA

El servidor receptor revisará si SPF o DKIM PASAN, después si el dominio Return-Path usado por SPF y/o el dominio d= de DKIM está alineado con el From: y, por último, extraerá la política DMARC publicada en el dominio Found in “From” y cumplirá la política.

La lógica general es:

• Si SPF APRUEBA y está ALINEADO con el dominio “From” = DMARC APRUEBA, o
• Si DKIM APRUEBA y está ALINEADO con el dominio “From” = DMARC APRUEBA
• Si SPF y DKIM FALLAN = DMARC FALLA

DMARC no solo requiere que SPF o DKIM APRUEBEN, también exige que los dominios usados en cualquiera de estos dos estén ALINEADOS con el 

“From”. Solo entonces DMARC APRUEBA.

Alineación estricta significa que el dominio Return-Path o el dominio “d=” deben coincidir EXACTAMENTE con el dominio en From:.

Alineación relajada significa que el dominio Return-Path o el dominio “d=” pueden ser subdominios de la dirección From: (o viceversa).

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

Si DMARC falla, el servidor receptor normalmente sigue la política que hayas especificado en tu registro DMARC.

• Si tu modo es solo de informes (p=none), el correo será aceptado por el servidor receptor y evaluado por otros criterios de filtrado.
• Si tu modo es cuarentena (p=quarantine), el correo se pondrá en cuarentena y habitualmente irá a la carpeta de spam.
• Si tu modo es rechazo (p=reject), el servidor abortará la conexión y el correo nunca llegará al usuario.

Sea cual sea la política, los metadatos del mensaje se registrarán junto al estado de autenticación y se enviarán a tu procesador de informes DMARC. Más información sobre informes DMARC aquí.

1. Asegúrate de que tienes 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 donde Return-Path está vacío.
3. Asegúrate de que existe un solo registro SPF por dominio.
4. Comprueba que la sintaxis del registro SPF es correcta.
5. Asegúrate de que tu dominio Return-Path esté alineado con el dominio From.
6. Asegúrate de que los remitentes autorizados están en el registro SPF.
7. Asegúrate de que los remitentes no autorizados no estén en el registro SPF.
8. No superes el límite de 10 consultas DNS impuesto por SPF. Si lo superas, considera utilizar una función como Dynamic SPF de Red Sift OnDMARC.
9. Asegúrate de no usar mecanismos obsoletos como “ptr” en tu registro SPF.
10. Mantén las cosas simples trabajando con un proveedor DMARC como Red Sift

1. Asegúrate de que tus sistemas de envío soportan DKIM.
2. Verifica que los correos estén firmados con DKIM.
3. Asegúrate de que el dominio de firma esté alineado con el dominio From.
4. Utiliza claves DKIM mayores de 1024 bits (se recomienda 2048 bits)
5. Cuando sea posible, elige selectores DKIM que identifiquen claramente el servicio de envío para distinguirlos.
6. Revoca cualquier clave que se haya visto comprometida.
7. Rota las claves DKIM que gestionas con regularidad.
8. Comprueba que la sintaxis de la clave DKIM es correcta.
9. Debe existir una clave pública para cada clave privada que firme tus emails.

1. Como DMARC depende de SPF y DKIM y de los dominios que usan estos dos protocolos, debes asegurarte de que el dominio Return-Path para SPF coincida exactamente o sea un subdominio del dominio “From”. Lo mismo aplica para el dominio de firma usado por DKIM. Una alineación adecuada es crítica para la entregabilidad en 2026.
2. Comprueba que la sintaxis del registro DMARC es correcta.
3. Asegúrate de que todos tus sistemas están correctamente configurados con SPF y DKIM antes de pasar a una política reject o tus correos se perderán.
4. Usa una plataforma o proveedor externo como Red Sift OnDMARC para recibir informes DMARC, poder interpretarlos y detectar sistemas mal configurados. Las plataformas modernas DMARC en 2026 como OnDMARC permiten alcanzar enforcement en 6-8 semanas gracias a la solución automática de problemas y pruebas en tiempo real.
5. Supervisa el estado de cada fuente de envío y verifica que cualquier cambio en SPF y DKIM sea detectado. Red Sift OnDMARC cuenta con esta función como parte principal del producto.