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

En este capítulo, respondemos algunas de las preguntas más comunes que nuestros Customer Success Engineers 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 obligatorios para los remitentes de correo masivo por parte de los principales proveedores de bandeja de entrada. ¡Vamos allá!

Utiliza esta lista para asegurarte de que cubres lo esencial. Márcalos en orden, ya que cada paso se basa en el anterior.

1. Publica un único registro SPF TXT en tu dominio Return-Path
2. Confirma que todas las IP de envío legítimas están incluidas en el registro
3. Comprueba que no has superado el límite de 10 búsquedas DNS (usa el SPF Checker de Red Sift para verificarlo)
4. Usa ~all (soft fail), no -all, para que DMARC gestione la aplicación de políticas
5. Asegúrate de que el dominio Return-Path se alinea con tu dominio visible From:

1. Confirma que todos los servicios de envío soportan y firman activamente con DKIM
2. Utiliza un tamaño de clave de 2048 bits o superior
3. Verifica que el dominio de firma (d=) se alinea con tu dominio From:
4. Nombra claramente los selectores para identificar cada servicio de envío
5. Rota las claves regularmente y revoca aquellas que hayan sido comprometidas

1. Publica un registro DMARC TXT: comienza en p=none para recopilar informes
2. Dirige rua= a un procesador de informes (por ejemplo, Red Sift OnDMARC) para hacer que los datos agregados sean útiles
3. Revisa los informes semanalmente para identificar remitentes desconocidos o mal configurados
4. Una vez que todas las fuentes legítimas pasen SPF o DKIM con alineación, avanza a p=quarantine
5. Pásate a p=reject para bloquear completamente los correos falsificados: el objetivo es lograrlo en 6–8 semanas con las herramientas adecuadas

Extra: Seguridad del transporte

1. Implementa MTA-STS primero en modo de prueba y luego pasa a aplicarlo tras revisar los informes TLS
2. Añade TLS-RPT para obtener visibilidad sobre fallos de entrega causados por problemas TLS

Configurar SPF y DKIM no garantiza que todas las fuentes de envío estén autenticadas. Algunos huecos comunes hacen que correos legítimos fallen silenciosamente, a menudo sin generar un error evidente:

• Subdominios sin protección. Un subdominio sin su propio registro SPF o DKIM puede ser suplantado aunque el dominio principal esté protegido.
• Remitentes de terceros. Plataformas de marketing, herramientas CRM y sistemas de soporte suelen enviar en tu nombre usando su propia infraestructura, cada una necesita su propia verificación de autenticación.
• Desfase en los registros DNS. Cambios en la infraestructura, como un nuevo proveedor de correo o una herramienta retirada, dejan registros SPF o selectores DKIM obsoletos que pueden hacer fallar a remitentes legítimos.
• Reenvío defectuoso. Las firmas DKIM pueden invalidarse si el mensaje pasa por un servicio de reenvío que reescribe encabezados o modifica el cuerpo.
• Manejo inconsistente en clientes. No todos los clientes de correo (móvil/escritorio) evalúan igual la autenticación, así que un mensaje puede tener diferente destino según donde se abra.
• Arrastre de reputación. Los fallos de autenticación se acumulan. Un dominio que falla continuamente construye una mala reputación como remitente, lo que reduce la entregabilidad incluso de mensajes que sí pasan.

Detecta estos problemas antes de que se traduzcan en mensajes perdidos: haz un inventario completo de todos los dominios y subdominios que envían correo en tu nombre y revisa el estado SPF, DKIM y DMARC de cada uno.

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. Verifica la autenticidad de las identidades MAIL FROM o HELO/EHLO durante la transmisión, comparando la dirección IP del servidor de envío frente a una lista de remitentes autorizados especificada en un registro TXT en el DNS del propietario del dominio. Si la dirección IP coincide con la lista autorizada, la autenticación SPF tiene éxito. 

SPF se enfoca en el "dominio" que aparece en el encabezado del email, conocido como Return-Path, MAIL-FROM, dirección de rebote o Envelope from. Si ese encabezado falta, SPF usa el host “HELO/EHLO” y comprueba allí si existe un registro SPF.

El encabezado Return-Path es técnico y no es visible para el usuario final, salvo que sepa mostrar los encabezados en su cliente de correo. 

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

Esto se logra usando criptografía asimétrica, es decir, una combinación de claves pública y privada. 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 cualquiera que reciba mensajes pueda recuperarla.

Cuando se redacta un correo, sus encabezados y cuerpo se firman con la clave privada del remitente, generando una firma digital que se envía como un campo adicional en el mensaje. En el lado receptor (si DKIM está activo), el servidor recupera la clave pública y verifica si el correo fue firmado por el dominio remitente. Si la firma se valida correctamente, se prueba que el dominio remitente envió el mensaje y que los encabezados/cuerpo no han sido modificados.

DKIM se enfoca 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 recibido.

1. La mayoría de los problemas de autenticación de correo electrónico se deben a los mismos errores. Si aciertas en 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. Esto indica a los servidores receptores que bloqueen correos que no pasen la autenticación.
3. Asegúrate de que SPF y DKIM se alinean con tu dominio From: SPF y DKIM pueden pasar y aún así fallar DMARC si los dominios no coinciden. Asegúrate de que el dominio Return-Path (para SPF) y tu dominio de firma DKIM (d=) coinciden o son subdominios de tu dirección visible From:. Aquí es donde más organizaciones se traban.
4. Monitoriza tus informes DMARC semanalmente Los informes DMARC te indican exactamente quién está enviando correos en tu nombre y si pasan la autenticación. Utiliza una plataforma como Red Sift OnDMARC para transformar el XML sin procesar en datos accionables. Detecta errores antes de que sean problemas de entregabilidad.

Por qué SPF y DKIM no son suficientes. Aunque DKIM puede verificar que un correo no se ha modificado exactamente y SPF puede recomendar rechazar correos según la IP, ninguno es eficaz para evitar la suplantación. Por eso DMARC será obligatorio para organizaciones que envíen correos masivos en 2026.

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

SPF consulta el registro encontrado en el dominio del encabezado return-path y DKIM revisa la clave del dominio d= (contenido en el encabezado DKIM).

Ambos protocolos pueden configurarse para revisar cualquier dominio.

En un correo, el principal dominio del remitente es el dominio del encabezado From:, ese es el que ve el usuario final cuando revisa el remitente.

Dicho esto, tu dominio podría ser suplantado si un atacante utiliza From: tudominio.com, pero hace que return-path y d= sean sudominio.com. Mientras existan SPF y DKIM válidos en sudominio.com, el correo pasaría ambos controles, resultando en una suplantación exitosa...

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

DMARC significa Autenticación, Informes y Conformidad de Mensajes Basados en Dominio (Domain-based Message Authentication, Reporting and Conformance) y se basa en SPF y DKIM, ofreciendo una capa adicional de autenticación y aplicación de políticas.DMARC ya es exigido por los principales proveedores de correo y será el estándar del sector en 2026.

DMARC realiza varias funciones:

1. Tiene en cuenta los resultados de SPF y DKIM 
2. Para que DMARC lo apruebe, requiere que pasen SPF o DKIM y que el dominio usado por cualquiera de ellos se alinee con el del From:. Si quieres aprender más sobre la Alineación de Identificadores, haz clic aquí.
3. Envía informes de resultados SPF, DKIM y DMARC al dominio del From: (es decir, el remitente).
4. Por último, indica a los receptores cómo tratar los correos que no superan DMARC especificando la política en DNS.

Al establecer la política DMARC en p=reject, una organización puede recomendar a los servidores receptores que descarten cualquier correo enviado en su nombre que no supere la verificación de alineación. Esto detendrá intentos de suplantación donde el server receptor implemente correctamente DMARC.

DMARC se fija en el dominio que figura en el encabezado From: o Header from, que sí es visible para el usuario final. 

SPF verifica si un correo fue enviado por un remitente autorizado comprobando una lista de direcciones IP que publicas en tu DNS. El servidor receptor toma el dominio del encabezado Return-Path y revisa si existe un registro SPF. Busca en el registro SPF si la IP del email está dentro. Si está, SPF APRUEBA. Si la IP no está, SPF RECHAZA.

La lógica general es:

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

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

La lógica general es:

• Si la validación es exitosa = DKIM APRUEBA
• Si la validación falla = DKIM RECHAZA

El servidor receptor verifica si pasaron SPF o DKIM y luego revisa si el dominio Return-Path de SPF y/o el d= de DKIM se alinean con From:, y finalmente extrae la política DMARC publicada en el dominio del From: y la aplica.

La lógica general es:

• Si SPF APRUEBA y se ALINEA con el From: = DMARC APRUEBA, o
• Si DKIM APRUEBA y se ALINEA con el From: = DMARC APRUEBA
• Si SPF y DKIM RECHAZAN = DMARC RECHAZA

DMARC requiere no solo que SPF o DKIM pasen, sino que los dominios utilizados por cualquiera de los dos se ALINEEN con el dominio 

del From:. Solo así DMARC APRUEBA.

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

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

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

Si DMARC falla, el servidor receptor normalmente seguirá la política que especificaste en tu registro DMARC.

• Si estás en modo solo informes (p=none), el correo será aceptado y examinado por otros filtros.
• Si usas modo cuarentena (p=quarantine), el correo se pondrá en cuarentena y normalmente irá a la carpeta de spam del destinatario.
• Si estás en modo rechazo (p=reject), el servidor receptor abortará la conexión y el correo nunca llegará al usuario final.

Independientemente de la política, los metadatos del correo se guardarán junto con el estado de la autenticación y se enviarán a tu procesador de informes DMARC. Aprende más sobre los informes DMARC aquí.

Configurar SPF y DKIM bien en teoría no garantiza que funcionen realmente en cada dominio, subdominio o fuente de envío. Antes de buscar soluciones puntuales, ten claro el estado real de tu autenticación.

Haz una lista de cada dominio y subdominio que envía emails en tu nombre, incluyendo los de plataformas de marketing, CRM y soporte. Para cada uno, anota el estado SPF, DKIM y DMARC.

Analiza tasas de rebote, quejas de spam y fallos de entrega entre tus principales proveedores de envío. Cruza estos datos con herramientas de reputación de dominio como Google Postmaster Tools para identificar brechas de autenticación que te están penalizando en la bandeja de entrada.

Para cada dominio, valora el impacto de negocio si es suplantado. Un dominio solo para uso interno tiene distinto riesgo que el de tus facturas a clientes. Priorizá arreglos por el impacto, no por la facilidad de solución.

Haz esta evaluación cada trimestre. Nuevas fuentes de envío y cambios de infraestructura son la causa más común para problemas en una configuración que antes estaba limpia.

Algunas organizaciones creen que una autenticación de correo completa solo es posible con gastos de empresa. Pero en realidad, el coste depende de la complejidad, no del tamaño de la protección.

Cinco factores determinan el rango: volumen de envío, complejidad de infraestructura (cuántos dominios, subdominios y servicios de terceros utilizas), experiencia interna, exigencias de cumplimiento y cuánta integración personalizada requieren tus sistemas.

Algunos escenarios disparan el coste de errores de autenticación muy por encima del de corregirlos:

• Fusiones y adquisiciones. Integrar infraestructuras de correo en varios dominios y sistemas antiguos crea brechas que los atacantes aprovechan durante la transición.
• Industrias reguladas. Salud y finanzas tienen requisitos legales estrictos sobre seguridad del correo. Un proveedor médico sin autenticación en sus mensajes corre el riesgo de violar HIPAA y multas millonarias.
• Objetivos de alto valor. Empresas con datos sensibles o grandes movimientos de dinero son blanco de fraudes de correo corporativo. Un fabricante perdió 2,3 millones de dólares cuando atacantes suplantaron su dominio y desviaron una transferencia.
• Operaciones globales. Múltiples regiones, idiomas y regulaciones multiplican las fuentes de envío que requieren autenticación consistente.

En 2023, según datos del FBI, las pérdidas globales por ataques de suplantación de dominio superaron los 18 millones de dólares.

1. Asegúrate de tener un registro SPF en tu dominio Return-Path.
2. Asegúrate de tener registro SPF en tu dominio HELO/EHLO por si el Return-Path está vacío en los rebotes.
3. Comprueba que solo exista un registro SPF por dominio.
4. Verifica que la sintaxis del registro SPF sea correcta.
5. Asegúrate de que tu dominio Return-Path se alinea con el dominio From.
6. Confirma que tus remitentes autorizados estén en el registro SPF.
7. Asegúrate de que remitentes no autorizados no aparezcan en tu registro SPF.
8. No superes el límite de 10 búsquedas DNS impuesto por SPF. Si lo has hecho, considera usar una función como Dynamic SPF de Red Sift’s OnDMARC.
9. No uses mecanismos SPF obsoletos como "ptr" en tu registro SPF.
10. Mantén todo simple trabajando con un proveedor DMARC como Red Sift

1. Confirma que los sistemas de envío soportan DKIM.
2. Confirma que los correos estén firmados con DKIM.
3. Verifica que el dominio de firma se alinea con el From:.
4. Usa claves DKIM de más de 1024 bits (mejor aún 2048 bits)
5. Siempre que sea posible, usa selectores DKIM que permitan identificar el servicio emisor y diferenciarlos.
6. Revoca cualquier clave que se haya visto comprometida.
7. Rota regularmente las claves DKIM bajo tu gestión.
8. Verifica que la sintaxis de las claves DKIM sea correcta.
9. Asegúrate de que exista una clave pública por cada clave privada correspondiente que firme tus correos.

1. Como DMARC depende de SPF y DKIM y sus dominios, asegúrate de que el Return-Path de SPF sea igual o subdominio del dominio From:. Lo mismo con el dominio de firma DKIM. Una configuración adecuada de alineación es vital para la entregabilidad en 2026.
2. Confirma que la sintaxis del registro DMARC sea correcta.
3. Asegúrate de tener todos tus sistemas bien configurados con SPF y DKIM antes de pasar a una política de rechazo, ya que podrías perder correos legítimos.
4. Utiliza un sistema o proveedor externo como Red Sift OnDMARC para recibir informes DMARC y analizar errores o sistemas mal configurados. Las plataformas modernas de DMARC en 2026, como OnDMARC, permiten alcanzar políticas de enforcement en 6-8 semanas mediante troubleshooting automático y pruebas en tiempo real.
5. Monitoriza el estado de cada fuente de envío y asegúrate de detectar cualquier cambio en SPF y DKIM. Red Sift OnDMARC ofrece esto como función principal de su producto.