Laboratorio de autenticación de correo: SPF, DKIM y DMARC
Lleva una empresa ficticia de DMARC p=none a p=reject sin rebotar correo legítimo: búsquedas SPF, rotación DKIM, informes agregados, BIMI y MTA-STS.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Todo el mundo sabe que debería llegar a DMARC p=reject. La mayoría de los equipos se atasca en p=none por miedo a bloquear sus propias facturas y nóminas. Aquí gestionas el despliegue completo para un minorista ficticio: 6 dominios, un CRM, un ESP, un helpdesk, un proveedor de nóminas que nadie apuntó y una adquisición que se cerró esta mañana. Trabajas 23 tickets y 43 decisiones en seis rondas: corriges SPF por encima del límite de 10 búsquedas, publicas y rotas claves DKIM, lees resúmenes de informes agregados y el XML en bruto para encontrar remitentes legítimos que fallan la alineación, y subes DMARC de p=none a p=reject. La última ronda cubre las reglas de remitentes masivos de Google y Yahoo de 2024, los requisitos previos de BIMI y MTA-STS con TLS-RPT. Un compañero reacciona a cada decisión y te avisa sin rodeos cuando una haría rebotar correo legítimo, y el informe final exporta tus registros DNS y el plan de despliegue en Markdown. Es un laboratorio Pro.
- Empieza por el inventario y los dominios aparcados, y luego pasa a la ingeniería de SPF.
- En cada ticket, lee los registros DNS, las cabeceras o los datos del informe y toma de una a tres decisiones.
- Publica y rota claves DKIM, lee los informes agregados y sube DMARC por etapas hasta p=reject.
- Revisa el informe final y exporta tus registros DNS y el plan de despliegue en Markdown. Un enlace con ?seed= repite la misma partida.
Preguntas frecuentes
¿Qué es el laboratorio de autenticación de correo?
Un laboratorio de formación en el navegador en el que llevas una empresa ficticia de DMARC p=none a p=reject sin perder correo legítimo. Tiene 23 tickets en seis rondas: inventario y dominios aparcados, ingeniería de SPF, claves y selectores DKIM, lectura de informes agregados, el despliegue de DMARC y una ronda final sobre un dominio adquirido, las reglas de remitentes masivos de Google y Yahoo, BIMI y MTA-STS. Cada ticket muestra registros DNS, cabeceras o datos de informes y te pide de una a tres decisiones.
¿Cómo decide DMARC si un mensaje pasa?
Según el RFC 7489, DMARC pasa cuando SPF o DKIM pasan para un dominio que está alineado con el dominio From visible. SPF autentica el remitente del sobre (Return-Path), no el From. DKIM autentica el dominio firmante d=. La alineación relajada, la predeterminada, exige el mismo dominio organizativo; la alineación estricta exige coincidencia exacta. Un resultado SPF o DKIM válido para el propio dominio de un proveedor no cuenta.
¿Qué es el límite de 10 búsquedas de SPF?
El RFC 7208 limita la evaluación de SPF a 10 términos que consultan DNS: include, a, mx, ptr, exists y el modificador redirect. ip4, ip6 y all no cuentan. Superarlo devuelve permerror, que DMARC trata como SPF no superado. Las soluciones habituales son quitar los include de proveedores que usan su propio Return-Path, quitar a y mx cuando esos hosts no envían correo y llevar a los proveedores a sus propios subdominios. Aplanar los include en rangos IP solo funciona con automatización, porque los proveedores cambian de direcciones.
¿SPF debe terminar en ~all o en -all?
Para DMARC apenas hay diferencia: fail y softfail cuentan ambos como SPF no superado. La diferencia está en los receptores que actúan solo sobre SPF. Algunos rechazan en tiempo de SMTP ante -all antes de comprobar DKIM, lo que puede rebotar correo reenviado que habría pasado DMARC gracias a su firma (RFC 7489, sección 10.1). Muchos equipos publican ~all y dejan que DMARC haga cumplir la política. Los dominios aparcados que nunca envían deberían publicar v=spf1 -all.
¿Qué longitud debe tener una clave DKIM y cómo se rota?
El RFC 8301 exige a los firmantes claves RSA de al menos 1024 bits, recomienda al menos 2048 y retira rsa-sha1. Una clave de 2048 bits es más larga que una cadena TXT de 255 caracteres, así que se publica como varias cadenas en un mismo registro. Para rotarla, publica un selector nuevo, cambia la firma a él, mantén publicada la clave pública antigua unos días mientras se vacía el correo en cola, revócala después con una etiqueta p= vacía (RFC 6376) y elimínala más adelante.
¿Cómo paso de p=none a p=reject con seguridad?
Añade una dirección rua y recoge de dos a cuatro semanas de informes agregados. Úsalos para encontrar cada fuente legítima que falla la alineación y corrige cada una con DKIM personalizado o un Return-Path personalizado. Después publica p=quarantine con un pct bajo, súbelo por etapas mientras vigilas los informes y pasa a p=reject. Según el RFC 7489, los mensajes que fallan y que pct no muestrea reciben la siguiente política menos estricta. Mantén rua activado de forma permanente, porque aparecen proveedores nuevos sin aviso.
¿Qué dicen los requisitos de remitentes masivos de Google y Yahoo?
Desde febrero de 2024, Google y Yahoo exigen a todos los remitentes autenticarse con SPF o DKIM. Los remitentes masivos (Google: cerca de 5.000 mensajes o más al día a cuentas personales de Gmail) deben usar SPF y DKIM, publicar un registro DMARC con al menos p=none, alinear el dominio From con SPF o DKIM, ofrecer la baja con un clic (RFC 8058) en el correo de marketing y atender las bajas en un plazo de dos días, y mantener bajas las tasas de spam (Google: por debajo del 0,3 % en Postmaster Tools). También se exigen DNS directo e inverso válidos para las IP de envío y TLS.
¿Cuáles son los requisitos previos de BIMI y qué hace MTA-STS?
BIMI muestra el logotipo de una marca solo cuando DMARC está en modo de aplicación (p=quarantine o p=reject con pct=100), con un registro BIMI en default._bimi, un logotipo SVG Tiny Portable/Secure y, para Gmail, un certificado de marca (VMC o CMC). MTA-STS (RFC 8461) hace algo distinto: protege el correo que llega a tu dominio indicando a los servidores emisores que usen TLS con un certificado válido hacia tus hosts MX publicados. Despliégalo en modo testing junto con los informes TLS-RPT (RFC 8460) antes de pasar a enforce.
¿Cubre DMARCbis?
Solo donde cambia el consejo. DMARCbis es la revisión del IETF destinada a sustituir al RFC 7489. Sus borradores eliminan pct en favor de un indicador de pruebas t= y añaden np= para subdominios inexistentes. El laboratorio enseña el comportamiento del RFC 7489, que es el que implementan hoy los receptores, y señala dónde difiere DMARCbis. Comprueba el estado actual de DMARCbis antes de basarte en él.
¿Algo de esto es real?
No. Todos los dominios usan el dominio de nivel superior reservado .example, todas las direcciones IP son de los rangos de documentación del RFC 5737 y la empresa, los proveedores y las personas son inventados. El laboratorio modela las decisiones de SPF, DKIM y DMARC; no envía correo ni consulta DNS reales.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba; después necesitas Pro.