Un correo que no llega cuesta más que un correo mal escrito. Desde febrero de 2024, Google y Yahoo exigen a los remitentes de volumen una autenticación completa y un registro DMARC; Microsoft siguió en 2025 para Outlook.com. La autenticación ya no es una buena práctica entre otras: es la condición de entrada. Esto es lo que abarcan SPF, DKIM y DMARC, y el orden en que desplegarlos.
Tres mecanismos, tres preguntas distintas
| Mecanismo | Pregunta que responde | Dónde vive |
|---|---|---|
| SPF | ¿Está este servidor autorizado a enviar por este dominio? | Registro DNS TXT |
| DKIM | ¿Se ha alterado el mensaje desde su envío? | Firma en la cabecera + clave pública en DNS |
| DMARC | ¿Qué hacer cuando SPF o DKIM fallan, y quién es informado? | Registro DNS TXT |
La confusión más extendida consiste en creer que estos mecanismos se sustituyen. Se complementan: DMARC solo funciona apoyado en SPF y DKIM, y su interés principal — los informes — no existe sin ellos.
SPF: declarar los servidores autorizados
SPF es un registro TXT en la raíz del dominio que enumera los servidores habilitados para enviar en su nombre. Un sitio autoalojado que delega sus envíos a una plataforma de correo debe incluirla.
; registro TXT en ejemplo.es
"v=spf1 include:spf.brevo.com include:_spf.ovh.net -all"Dos puntos deciden el resultado:
- La terminación.
-all(rechazo estricto) es la opción correcta una vez verificada la lista de remitentes.~all(fallo suave) es una etapa de transición, no un destino. - El límite de diez consultas DNS. Cada
include:desencadena una resolución; a partir de diez, la verificación devuelve un error permanente y SPF deja de proteger. Los registros acumulados herramienta tras herramienta son la causa más frecuente de ese exceso.
Un registro SPF que supera las diez resoluciones DNS ya no protege nada: falla en silencio, y nadie lo advierte antes de una caída de entregabilidad.
DKIM: firmar para probar la integridad
DKIM añade una firma criptográfica a las cabeceras del mensaje. El destinatario recupera la clave pública en el DNS del remitente y verifica que el contenido firmado no ha sido modificado en tránsito.
; clave pública, en un selector dedicado
mail._domainkey.ejemplo.es. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."En la práctica, la clave la genera la plataforma de envío, que facilita el registro a publicar. El punto de vigilancia es el selector: cada servicio usa el suyo, lo que permite que varios remitentes convivan en un mismo dominio sin conflicto. Una rotación de clave por parte del proveedor obliga a republicar el registro — un olvido frecuente al cambiar de plataforma.
DMARC: la política y los informes
DMARC indica a los servidores destinatarios qué hacer cuando la autenticación falla, y adónde enviar los informes. Es también quien impone el alineamiento: el dominio visible en el campo From: debe coincidir con el validado por SPF o DKIM. Un mensaje perfectamente firmado para un dominio ajeno pero que muestra su nombre falla en DMARC — que es precisamente el mecanismo que bloquea la suplantación.
; inicio en observación
_dmarc.ejemplo.es. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
; objetivo tras analizar los informes
_dmarc.ejemplo.es. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; adkim=s; aspf=s"La progresión recomendada
p=none— sin efecto sobre la entrega, pero los informes empiezan a llegar. Contar de dos a cuatro semanas para inventariar todos los remitentes legítimos: herramienta de facturación, CRM, formulario del sitio, plataforma de correo.p=quarantine— los mensajes no autenticados van a no deseados. Activar una vez limpios los informes, eventualmente sobre un porcentaje parcial mediantepct=.p=reject— los mensajes no autenticados se rechazan. Es el objetivo, y lo que los grandes proveedores esperan de los remitentes de volumen.
p=reject en un dominio que envía desde varias herramientas equivale a cortar la entrega de las que se habían olvidado. Los informes agregados existen precisamente para evitarlo.Lo que la autenticación no resuelve
SPF, DKIM y DMARC responden a la pregunta «¿procede este mensaje realmente de este dominio?». No dicen nada de su calidad. Un dominio perfectamente autenticado que envía contenido no solicitado acaba en no deseados como los demás: reputación de la dirección IP, tasa de quejas, tasa de bajas y participación pesan después. La autenticación abre la puerta; no garantiza la acogida.
Dos complementos merecen añadirse a continuación: BIMI, que muestra el logotipo del remitente en los clientes compatibles y exige p=quarantine como mínimo, y un enlace de baja en un clic conforme al RFC 8058, ya exigido a los remitentes de volumen.
Verificar antes de concluir
| Control | Método |
|---|---|
| Registros publicados | dig +short TXT ejemplo.es y dig +short TXT _dmarc.ejemplo.es |
| Número de resoluciones SPF | Un validador SPF en línea; por encima de 10, reducir los include: |
| Alineamiento real | Envío de prueba a una dirección Gmail y «Mostrar original»: las tres líneas deben indicar PASS |
| Cobertura de remitentes | Lectura de los informes agregados DMARC durante dos a cuatro semanas |
Lo que hay que retener
El orden de despliegue no varía: SPF primero, DKIM después, DMARC en observación y luego endurecimiento progresivo de la política. Cada etapa se verifica antes de la siguiente. El atajo — publicar los tres registros el mismo día en p=reject — es la forma más rápida de cortar envíos legítimos sin saber cuáles.
En los dominios que administro, el paso a p=reject reveló sistemáticamente un remitente olvidado: una herramienta de facturación, una notificación de copia de seguridad, un formulario antiguo. Los informes DMARC en p=none no sirven para marcar una casilla, sino para descubrir qué envía en su nombre sin que usted lo sepa. — Simon Janvier
Para profundizar
Los requisitos de los proveedores están documentados en Google Workspace. La especificación DMARC es el RFC 7489.
