Autenticación de correo: SPF, DKIM y DMARC

La autenticación de correo es la prueba de identidad de tus mensajes: la forma en que demuestras a Gmail, Outlook o Yahoo que el correo que dice venir de tu dominio viene de verdad de ti. Durante años fue una buena práctica recomendable; hoy es un requisito de entrada. Sin SPF, DKIM y DMARC bien configurados y alineados, tu correo no compite en igualdad de condiciones, y desde finales de 2025 ni siquiera se aplaza con un error temporal: se rechaza de plano. Esta página explica qué hace cada pieza, dónde está el fallo que afecta a casi todos —la alineación— y cómo te llevamos hasta una autenticación completa sin que un solo correo legítimo se quede por el camino.

¿Qué prueba cada registro de autenticación?

Tres registros forman el núcleo, y cada uno responde una pregunta distinta. SPF (Sender Policy Framework) declara, en tu DNS, qué servidores e IPs están autorizados a enviar correo en nombre de tu dominio; el receptor lo consulta como una lista de invitados. DKIM (DomainKeys Identified Mail) añade a cada mensaje una firma criptográfica que el receptor verifica con una clave pública publicada en tu DNS, demostrando que el correo salió de tu dominio y no se alteró por el camino. Y DMARC (Domain-based Message Authentication) ata los dos anteriores: define qué debe hacer el receptor si las comprobaciones fallan y, sobre todo, exige que estén alineadas con el dominio que el destinatario ve. Por encima de los tres, BIMI permite mostrar tu logo verificado en la bandeja cuando todo lo demás está en orden.

¿Por qué un registro nunca basta?

Es tentador pensar que con SPF ya estás cubierto, pero cada registro tapa un hueco que los otros dejan. SPF autoriza servidores, pero no protege el contenido ni sobrevive bien a los reenvíos. DKIM garantiza integridad y origen, pero por sí solo no le dice al receptor qué hacer cuando algo no cuadra. DMARC pone las reglas y exige alineación, pero no puede funcionar si no hay SPF o DKIM que validar debajo. Solo juntos cuentan una historia completa: este correo viene de quien dice, no se ha tocado, y aquí está la política para cuando alguien intente falsificarlo. Por eso los grandes buzones piden los tres a los remitentes de volumen, y por eso configurar uno y olvidar los demás deja una puerta que los filtros detectan enseguida.

SPF en detalle: el límite de las diez consultas

SPF parece simple y esconde una trampa que tumba muchas configuraciones: el límite de diez consultas DNS. Cada «include» que añades —tu ESP, tu CRM, tu pasarela de facturación— consume consultas, y al pasar de diez el registro deja de evaluarse y empieza a fallar, aunque a primera vista parezca correcto. La solución pasa por mantener el registro limpio: consolidar fuentes, eliminar las que ya no usas y, cuando hace falta, aplanar el registro para que quepa bajo el límite. También importa cómo lo cierras: un «-all» rechaza de forma explícita lo no autorizado, mientras que un «~all» lo marca como sospechoso sin bloquearlo. Revisar el SPF va más allá de comprobar que existe: hay que ver que evalúa bien, contar sus consultas y mirar cómo cierra. Es uno de los puntos donde una herramienta sin criterio te da un «verde» engañoso.

DKIM en detalle: claves, selectores y rotación

DKIM tiene más piezas móviles de las que parece. Cada fuente firma con un «selector» —un nombre que apunta a su clave pública en tu DNS—, lo que permite que distintos servicios firmen con tu dominio sin pisarse. La fortaleza de la clave importa: 2048 bits es hoy el estándar sano, y las claves de 1024, aún frecuentes, se consideran débiles. Y las claves no son para siempre: conviene rotarlas con cierta regularidad, lo que exige publicar la nueva antes de retirar la vieja para no cortar la firma. El fallo más caro, ya lo vimos, es firmar con el dominio del proveedor en lugar del tuyo, que rompe la alineación sin romper la firma. Gestionar DKIM bien es llevar el control de qué selector usa cada fuente, con qué clave y desde qué dominio, algo que en una operación con muchos servicios se desordena con facilidad.

¿Qué comprueba de verdad el servidor receptor?

Entender la comprobación ayuda a entender los fallos. Cuando llega tu correo, el receptor mira tres cosas casi a la vez. Verifica SPF contra el dominio del sobre —el return-path—, comprobando si la IP que conecta está autorizada. Verifica la firma DKIM con tu clave pública, confirmando que el mensaje es íntegro y procede de tu dominio. Y aplica DMARC: comprueba que al menos una de las dos anteriores haya pasado y, además, que esté alineada con el dominio visible en el campo «De». Si DMARC pasa, el correo sigue su camino con tu reputación detrás; si falla, el receptor hace lo que tu política le indique. Ese cruce ocurre en milisegundos y decide el destino de cada mensaje.

La alineación, donde casi todos fallan

Si hay un concepto que separa una autenticación que funciona de una que solo lo parece, es la alineación. No basta con que SPF o DKIM «pasen»: el dominio que pasa tiene que coincidir con el que el destinatario ve en el «De». El caso clásico es el de un proveedor externo —tu plataforma de marketing, tu CRM— que firma DKIM con su propio dominio o cuyo return-path es suyo: las comprobaciones pasan, pero contra el dominio del proveedor en vez del tuyo, así que DMARC las trata como fallo. El resultado es un correo que parece autenticado y aun así va a spam. La solución es configurar cada fuente para que firme con tu dominio y use un return-path tuyo, y elegir bien entre alineación relajada —que admite subdominios— y estricta. Es el ajuste que más correos rescata, y el que más se pasa por alto.

Alineación relajada frente a estricta

DMARC permite elegir cuán exigente es la alineación, y la decisión tiene consecuencias prácticas. En modo relajado —el habitual—, basta con que el dominio que pasa SPF o DKIM comparta el dominio organizativo con el «De»; así, un correo enviado desde un subdominio como envios.tudominio.com sigue alineado con tudominio.com. En modo estricto, los dominios deben coincidir de forma exacta, y cualquier diferencia de subdominio rompe la alineación. El estricto protege mejor frente a ciertos abusos, pero es mucho más frágil con las arquitecturas que usan subdominios, que son justo las recomendables. Elegir el modo correcto por registro y por fuente es parte del trabajo fino: demasiado estricto y bloqueas correo legítimo; demasiado laxo y dejas margen al abuso. La mayoría de las operaciones funcionan mejor en relajado, con una arquitectura de subdominios bien pensada debajo.

Remitentes de terceros: el punto débil

Casi ninguna empresa envía todo su correo desde un único sitio, y ahí está el riesgo. La plataforma de marketing, el CRM, el sistema de tickets, la pasarela de facturación, la herramienta de firmas: cada una manda correo con tu dominio, y cada una tiene que autenticarse y alinearse por separado. Es habitual que una de ellas —la que configuró un departamento sin avisar a nadie— firme con el dominio del proveedor o no figure en el SPF, y se convierta en el flujo que rompe tu DMARC. Por eso el inventario de fuentes es el primer paso de cualquier proyecto serio: no puedes alinear lo que no sabes que existe. Cada tercero que envía en tu nombre es una pieza que hay que configurar con tu dominio, no con el suyo, y vigilar cada vez que cambia.

Las trampas que impiden pasar

Algunos errores se repiten en casi todas las configuraciones que revisamos. El doble registro SPF, que provoca un error de validación y tira abajo la autenticación entera. El SPF que supera las diez consultas DNS permitidas y deja de evaluarse correctamente. Las claves DKIM de 1024 bits, hoy débiles, cuando el estándar sano son 2048. La firma DKIM hecha desde el dominio del ESP en lugar del tuyo, que rompe la alineación sin romper la firma. El «include» de SPF que hace pasar el correo con el dominio de un tercero. Y el más extendido de todos: dejar DMARC en p=none «temporalmente» y olvidarlo ahí durante años, monitorizando sin proteger nunca. Ninguno es difícil de corregir; lo difícil es detectarlos sin leer los informes.

# SPF: ¿está dentro del límite de 10 consultas?
$ dig +short TXT ejemplo.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net include:mktomail.com ~all"
# 11 consultas entre los includes — sobre el límite, SPF devuelve permerror

# DKIM: ¿el selector está vivo y la clave es de 2048 bits?
$ dig +short TXT sel1._domainkey.ejemplo.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkq..."   # 2048 bits, resuelve

# DMARC: ¿aplica, o está parado en p=none?
$ dig +short TXT _dmarc.ejemplo.com
"v=DMARC1; p=none; rua=mailto:[email protected]"
# p=none: solo monitoriza — un suplantador todavía pasa como tu dominio

¿Cómo pasa DMARC de la monitorización al enforcement?

DMARC se despliega por etapas, y cada una tiene su función. Empiezas en p=none, que no bloquea nada y solo observa: recoges informes para ver quién envía con tu dominio, legítimo o no. Cuando has autenticado todas tus fuentes reales, subes a p=quarantine, que manda a spam lo que falle, y por fin a p=reject, que lo rechaza de plano con un error 550 y cierra la puerta a la suplantación. La opción pct= permite aplicar la política solo a un porcentaje del tráfico para probar sin riesgo, y rua y ruf definen a dónde llegan los informes. La regla de oro es no saltarse etapas: cada salto se da cuando los datos confirman que ningún correo legítimo se quedará fuera, no antes.

Leer los informes agregados

Los informes RUA son el mapa que hace segura la subida a rechazo, aunque llegan en un XML que no está pensado para leerse a ojo. En ellos aparece cada fuente que envía con tu dominio, cuántos mensajes manda y si pasan SPF y DKIM alineados. Esa visibilidad destapa dos cosas muy valiosas: las fuentes legítimas que habías olvidado —ese servidor que configuró alguien hace años, la herramienta nueva de un departamento— y las fuentes maliciosas que intentan suplantarte. Interpretar esos informes es lo que convierte DMARC de una casilla marcada en una defensa real: te dice exactamente qué autenticar antes de endurecer la política, de modo que el salto a rechazo no deje fuera tu propia facturación ni tus alertas.

ARC y los reenvíos

Hay un escenario que rompe SPF sin que hagas nada mal: el reenvío. Cuando una lista de correo o un buzón reenvía tu mensaje, la IP que lo entrega cambia, y tu SPF —que autorizaba la original— deja de cuadrar. DKIM suele sobrevivir al reenvío porque viaja dentro del mensaje, razón de más para apoyarse en él. Para los casos en que un intermediario modifica el correo, existe ARC (Authenticated Received Chain), que preserva el resultado de autenticación original a lo largo de la cadena de reenvíos, de modo que el receptor final pueda confiar en él. No todos los flujos lo necesitan, pero conocer cómo se comportan tus mensajes al reenviarse evita diagnósticos erróneos: un «fallo» de SPF tras un reenvío rara vez es un problema tuyo que corregir; a menudo es el funcionamiento esperado, que DKIM y ARC compensan.

BIMI y el logo verificado

BIMI es la recompensa visible de hacer bien todo lo anterior: muestra el logotipo verificado de tu marca junto a tus correos en la bandeja de entrada. No es un punto de partida, sino una guinda, porque solo se activa cuando tu DMARC está en cuarentena o rechazo y todas tus fuentes legítimas están autenticadas y alineadas. Requiere publicar un logo en formato SVG y, en los principales proveedores, un certificado de marca verificada (VMC). Su cobertura ya alcanza a la mayoría de los usuarios de correo, y para una marca con volumen comercial el reconocimiento en la bandeja justifica la inversión. Pero el orden importa: BIMI sin una autenticación sólida debajo sencillamente no aparece, así que nunca es lo primero.

Autenticación defensiva para los dominios que no usas

Hay una parte de la autenticación que no tiene que ver con tu correo saliente, sino con proteger lo que no envías. Cada dominio y subdominio que posees pero no usas para enviar es una oportunidad para un suplantador, que puede mandar correo en su nombre sin que nadie lo note. La defensa es publicar en esos dominios un SPF que no autorice a nadie y una política DMARC en rechazo, de modo que cualquier intento de usarlos se bloquee. Es una medida barata y de alto retorno que casi nadie aplica, y que cierra una vía de phishing contra tu marca y tus clientes. Revisar el inventario completo de dominios, no solo el principal, es parte de hacer la autenticación bien.

¿Qué cambia a gran volumen y con varias marcas?

Cuando creces, la autenticación deja de ser un único juego de registros y se vuelve una arquitectura. Los remitentes de volumen separan sus flujos en subdominios dedicados —uno para marketing, otro para transaccional, otro por marca o por país—, cada uno con su SPF, su DKIM y su política de DMARC, heredada o propia. Esa separación no es burocracia: aísla la reputación, de modo que un problema en las campañas no arrastre la entrega de las facturas, y permite gobernar la autenticación sin que un cambio en un flujo rompa otro. Para una empresa con varias marcas o varios dominios, el diseño de esta jerarquía —qué cuelga de qué, qué política aplica a cada nivel— pesa tanto como los registros en sí. Hacerlo bien desde el principio ahorra una reorganización dolorosa más adelante, cuando el volumen ya no perdona los experimentos.

Autenticación y cumplimiento normativo

La autenticación ha salido del terreno de la entregabilidad para entrar también en el del cumplimiento. Marcos de seguridad de pagos como PCI DSS, en su versión más reciente, incorporan requisitos de autenticación de correo para las organizaciones que manejan datos de tarjetas. En el ámbito público, varias directivas de ciberseguridad obligan a organismos enteros a desplegar SPF, DKIM y DMARC en rechazo. La tendencia es clara: lo que empezó como una buena práctica de marketing es cada vez más una obligación de seguridad, porque un dominio sin DMARC en rechazo es una herramienta de phishing esperando a usarse contra tus clientes. Plantear la autenticación también como una medida de seguridad y de cumplimiento, además de entrega, ayuda a justificar el proyecto ante quien controla el presupuesto y eleva la conversación por encima del marketing.

Lo que cambió, y por qué urge

La autenticación dejó de ser opcional en muy poco tiempo. Desde febrero de 2024, Gmail y Yahoo exigen SPF, DKIM y DMARC a los remitentes masivos; desde el 5 de mayo de 2025, Microsoft pide lo mismo a quien envía más de cinco mil correos diarios a Outlook, Hotmail o Live. Y a finales de 2025 Gmail dio el paso más duro: pasó de aplazar el correo no conforme con errores temporales a rechazarlo de forma permanente, sin periodo de gracia. A esto se añade un dato que sorprende a los remitentes pequeños: la falta de autenticación puede hundir la colocación en bandeja de forma drástica incluso a bajo volumen, porque los filtros usan las mismas señales para todos. Lo contamos a fondo en nuestra guía de por qué Gmail rechaza tus correos.

Cuatro mitos que dejan dominios expuestos

Cuatro creencias mantienen a muchos dominios a medio autenticar. La primera, «soy pequeño, esto no va conmigo»: los filtros no preguntan tu tamaño, y la falta de autenticación te penaliza igual. La segunda, «p=reject es peligroso»: lo es si se hace deprisa, pero con la ruta gradual y los informes es la meta segura y deseable. La tercera, «con SPF ya está»: SPF solo deja la mitad del trabajo sin hacer y ni siquiera cubre la alineación. Y la cuarta, «se configura una vez y listo»: cada fuente nueva, cada cambio de proveedor y cada rotación de claves pide revisar que todo sigue alineado. Desmontar estos mitos es a menudo el primer paso de un proyecto de autenticación, porque la creencia equivocada es lo que mantiene el agujero abierto.

Cómo lo implementamos

Nuestro método sigue un arco probado que evita el error de endurecer a ciegas. Empezamos por un inventario completo: documentamos cada sistema que envía con tu dominio, incluido ese servidor olvidado que nadie recuerda haber configurado. Publicamos un SPF limpio, por debajo del límite de consultas, y configuramos DKIM con claves fuertes y alineación correcta para cada fuente. Activamos DMARC en monitorización y analizamos los informes para separar lo legítimo de lo malicioso. Autenticamos las fuentes legítimas que faltan y, solo entonces, subimos la política a cuarentena y a rechazo, validando en cada paso. Si tu correo cae por un código concreto durante el proceso, lo leemos en contexto, como explicamos en nuestra referencia de códigos de rechazo SMTP. El resultado es una autenticación que cumple hoy y se sostiene mañana.

¿Dónde se detienen las herramientas y dónde empezamos?

Hay buenas herramientas que publican registros y leen informes, y las usamos. Pero una herramienta te dice que algo falla; no decide por ti cuándo es seguro subir a rechazo, no interpreta un informe RUA con cientos de fuentes en contexto, ni reconoce que esa IP que aparece firmando es la pasarela legítima de tu departamento financiero. La parte difícil de la autenticación no es publicar un registro, sino el criterio: saber qué fuente es real, qué riesgo asumes en cada paso y cuándo apretar sin romper nada. Esa es la parte que ponemos nosotros, y la razón por la que un proyecto de autenticación rara vez es «pegar un TXT» y mucho más a menudo «poner orden en años de envíos sin gobierno».

Por qué con una consultoría independiente

En la autenticación, el sesgo del proveedor se cuela fácil: tu ESP te dirá que firmes con su dominio porque le simplifica la vida, no porque te convenga a ti. Nosotros no revendemos plataformas ni certificados, así que la recomendación apunta a tu alineación y tu protección, no a la comodidad de un tercero. Trabajamos en la capa técnica del correo a diario, en husos horarios de Europa, Norteamérica y Latinoamérica, y la autenticación encaja con el resto de lo que hacemos: cuando un fallo de alineación es en realidad un síntoma de un problema mayor de entrega, lo vemos, y lo abordamos con una auditoría de entregabilidad o con gestión continua en lugar de tratar solo el síntoma visible.

El punto de partida es una foto honesta y gratuita: la auditoría de 25 puntos revisa tu autenticación —presencia, validez y, sobre todo, alineación—, te dice qué falla y traza el camino hasta dejarte en rechazo sin sobresaltos. Es la forma de empezar con datos en lugar de con suposiciones.