Revisión de SPF, DKIM y DMARC
Tres registros DNS le dicen al resto del mundo qué correo viene realmente de tu dominio. Esta revisión los lee como lo hace un servidor receptor y traduce cada término que encuentra.
El remitente de un correo electrónico no prueba nada
El correo electrónico se diseñó como un sobre de papel. El remitente escribe la dirección de devolución y nadie la comprueba. Un servidor de cualquier país puede enviar un mensaje cuya línea From muestre tu dominio. Tres añadidos posteriores cierran esa brecha, y los tres viven en la zona DNS de tu dominio como registros TXT.
- SPF, en el propio dominio
- Una lista de los servidores autorizados a enviar en nombre del dominio. El receptor compara la dirección IP que se conecta con la lista.
- DKIM, en
selector._domainkey - Una clave pública. El servicio de envío firma cada mensaje con la clave privada correspondiente, de modo que el receptor puede saber que nadie alteró el mensaje y qué dominio responde por él.
- DMARC, en
_dmarc - Tu instrucción para el correo que no pasa ninguna de las dos pruebas con el nombre de tu dominio: entregarlo, enviarlo a spam o rechazarlo. También nombra un buzón para los informes diarios.
Desde febrero de 2024, Gmail y Yahoo rechazan el correo masivo de dominios que carecen de estos registros, y Microsoft los siguió en 2025 con Outlook.com.
Qué mira la revisión
Empieza por tus registros MX, para reconocer al proveedor del buzón (Google Workspace, Microsoft 365, Proton Mail, Fastmail y otros ocho). A partir de ahí sabe qué include de SPF y qué selectores DKIM esperar.
| Registro | Se marca como fallo | Se marca como aviso |
|---|---|---|
| SPF | Ningún registro en un dominio que tiene servidores de correo; dos registros; más de 10 consultas DNS; un include que no tiene SPF propio o que vuelve sobre sí mismo; un término mal escrito; +all; más de dos consultas que no devuelven nada | De 8 a 10 consultas; ?all o ausencia de all; ptr; términos colocados después de all; tu proveedor de buzón ausente de la lista |
| DKIM | Una clave publicada que no se puede usar: RSA de menos de 1024 bits, valor de p= dañado, algoritmo desconocido | Ninguna clave con ninguno de los nombres probados; una clave de 1024 bits; el indicador de prueba t=y |
| DMARC | Ningún registro; dos registros; ningún p= válido; una dirección de informes o un valor de etiqueta mal formados | p=none; pct por debajo de 100; sp=none bajo una política más estricta; informes enviados a otro dominio que no ha aceptado recibirlos |
Las consultas se cuentan a través de cada include anidado, y ahí es donde normalmente se rompe el límite de 10 sin que nadie lo note. Para un subdominio, la búsqueda de DMARC sube hasta el dominio principal y aplica su valor de sp=. El veredicto global es el peor de los tres resultados. Tres registros opcionales (MTA-STS, TLS-RPT, BIMI) solo se indican como publicados o no.
Un dominio cuyo SPF completo es v=spf1 -all se trata como uno que no envía nada. Que falte la clave DKIM es normal ahí, y el DMARC sugerido es p=reject.
Cómo encontrar tu selector DKIM
Las claves DKIM no tienen una dirección fija. Cada servicio de envío elige una etiqueta, llamada selector, y el DNS no ofrece forma de listarlas. La revisión prueba unas tres docenas de nombres habituales, como google, selector1, k1 y s1. Así que “no se encontró ninguna clave” a menudo solo significa que la tuya tiene otro nombre.
- Envía un mensaje desde tu dominio a un buzón que puedas abrir.
- Muestra su código fuente completo: “Mostrar original” en Gmail, “Ver origen del mensaje” en Outlook, “Ver > Mensaje > Todos los encabezados” en Apple Mail.
- Busca la línea que empieza por
DKIM-Signature:y lee dos etiquetas.d=es el dominio firmante ys=es el selector.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta2024; …
Aquí escribirías mta2024 en la casilla del selector. Si d= muestra el nombre de tu plataforma de boletines y no tu dominio, el mensaje está firmado, pero no por ti, y esa firma no cuenta para DMARC. Nuestro decodificador de cabeceras de correo lee esas líneas por ti.
Cómo reparar en un orden seguro
Haz una lista de todo lo que envía como tu dominio: buzones, plataforma de boletines, tienda en línea, servicio de atención al cliente, el formulario de contacto del sitio web. Pon cada uno en un único registro SPF. Después activa DKIM en cada servicio que lo ofrezca, ya que DKIM sobrevive al reenvío y SPF no.
Publica DMARC con p=none y una dirección rua=, y lee los informes durante unas semanas con el lector de informes DMARC. Cuando todas las fuentes legítimas pasen, cambia a quarantine y después a reject. El generador de registros escribe ambos registros.
Esta revisión lee el DNS y nunca ve ninguno de tus mensajes. No puede confirmar que un servicio firme de verdad con la clave que encontró, ni que el dominio firmante coincida con tu dirección From. Para eso necesitas las cabeceras de un mensaje entregado.
Preguntas frecuentes
¿Por qué mis correos van a spam si SPF, DKIM y DMARC pasan todos?
La autenticación demuestra quién envió el mensaje. No dice si la gente lo quiere. Los filtros también ponderan la tasa de quejas, la reputación de la dirección IP y del dominio de envío, los enlaces del mensaje y cómo reaccionaron los destinatarios a correos anteriores. Empieza por una consulta de listas de bloqueo.
¿Puede un dominio tener dos registros SPF?
No. Dos registros TXT que empiezan por v=spf1 producen un error permanente y los receptores actúan como si no tuvieras ninguno. Únelos en un solo v=spf1 con todos los términos include: e ip4: y un único all al final.
¿Qué significa “SPF PermError: too many DNS lookups”?
Recorrer tu registro requirió más de 10 consultas DNS. Cada include, a, mx, exists y redirect cuesta una, y los include dentro de un include también cuentan. Quita los servicios que ya no uses, o sustituye a y mx por direcciones ip4: fijas, que no cuestan nada.
¿SPF debe terminar en ~all o en -all?
Con DMARC en marcha, sirven los dos, porque DMARC decide qué pasa con un mensaje que falla. ~all es la opción más segura mientras aún estás descubriendo remitentes. No uses nunca +all, que autoriza a todos los servidores de internet.
¿Basta p=none para Gmail y Yahoo?
Sí, sus reglas para remitentes masivos aceptan p=none. Lo único que te da son informes, y el correo falsificado se sigue entregando. La protección empieza en quarantine.
¿Necesito DMARC en un dominio que nunca envía correo?
Ahí es donde es más fácil y más útil, porque un dominio aparcado es un disfraz cómodo para el phishing. Publica v=spf1 -all en el dominio y v=DMARC1; p=reject; en _dmarc.