Verificador de SPF, DKIM y DMARC

SPF, DKIM y DMARC son los tres registros DNS que deciden si el correo que dice venir de tu dominio se acepta o se descarta. Funcionan como un conjunto: SPF indica qué servidores pueden enviar en nombre del dominio, DKIM firma el mensaje criptográficamente para que no se pueda alterar en tránsito, y DMARC une ambos a la dirección De visible y dice a los receptores qué hacer cuando una comprobación falla. Si falta uno, los otros dos hacen menos de lo que crees: los suplantadores se cuelan por el hueco y el correo legítimo acaba en spam.

Este verificador consulta los tres a la vez desde nuestros servidores y te responde en lenguaje claro. Analiza tu registro SPF y cuenta las consultas DNS que provoca frente al límite estricto de diez, lee tu clave pública DKIM y estima su longitud en bits, y evalúa tu política DMARC desde la simple observación hasta el rechazo total. Un dominio de entrada, tres veredictos de salida. Sin registro, y no se guarda nada sobre tu dominio.

SPF: qué servidores pueden enviar en nombre de tu dominio

Un registro SPF es un único registro TXT en tu dominio que empieza por v=spf1 y enumera los hosts autorizados a enviar correo en tu nombre. Cada término nombra fuentes directamente (ip4:, ip6:) o apunta a otro sitio (include:_spf.google.com incorpora los rangos de tu proveedor, a y mx autorizan tus propios hosts A/MX). Un servidor receptor recorre esa lista y comprueba si la IP que se conecta está cubierta. El registro termina con un mecanismo all que recoge todo lo que no haya coincidido antes, y el calificador de ese all resume toda la política en un solo carácter.

Los calificadores, del más estricto al más débil: -all (fallo duro) indica a los receptores que rechacen todo lo que venga de una fuente no listada; ~all (fallo suave) dice que lo traten como sospechoso pero lo acepten, la opción pragmática mientras no tengas la certeza de que tu lista está completa; ?all (neutro) no expresa opinión y no te aporta nada; y +all autoriza expresamente a todo internet a enviar en tu nombre, lo que casi siempre es un error de configuración que anula el propósito del registro. La mayoría de los dominios bien llevados se sitúan en ~all o -all.

La trampa que rompe más registros SPF que ninguna otra es el límite de diez consultas. Cada término include, a, mx, ptr, exists y redirect obliga al receptor a hacer una consulta DNS, y esas consultas se anidan: un include puede contener sus propios includes. El RFC 7208 limita el total de toda la cadena a diez, y superarlo provoca un permerror que hace fallar el registro entero, en silencio. Por eso los grandes remitentes publican registros «aplanados» que incorporan rangos de IP en línea en lugar de encadenar includes. El verificador cuenta tu total real y recursivo de consultas para que sepas cuánto margen te queda antes de pasarte.

DKIM: una firma que demuestra que el mensaje no se ha alterado

DKIM añade una firma criptográfica a cada mensaje saliente. Tu servidor de correo guarda una clave privada y firma cada mensaje; la clave pública correspondiente se publica en DNS, y el receptor la usa para verificar que las partes firmadas del mensaje no cambiaron después de salir de ti. Una firma válida demuestra dos cosas a la vez: el mensaje procede realmente de un sistema que posee tu clave, y sus cabeceras y su cuerpo llegaron intactos.

La clave pública vive en un selector: una etiqueta que eliges y que le da a la clave su propio espacio de nombres en DNS, publicada en <selector>._domainkey.<domain>. Los selectores existen para que puedas mantener varias claves a la vez (una por servicio de envío) y rotarlas sin cortes: publica un selector nuevo, cambia la firma a él y retira el antiguo después. El nombre del selector no es secreto, pero tampoco se deduce solo del dominio; lo encuentras en las instrucciones DNS de tu proveedor de correo (Google usa google, Microsoft 365 usa selector1/selector2, muchas plataformas de envío usan el suyo) o leyendo la cabecera DKIM-Signature de un mensaje que ya hayas recibido, donde aparece como la etiqueta s=. Esta herramienta también puede sondear una lista de selectores comunes por ti cuando no lo conoces.

La longitud de la clave importa. Una clave RSA de 1024 bits fue el valor por defecto histórico y hoy se considera débil: está al alcance de un atacante decidido y algunos proveedores han empezado a desconfiar de ella. 2048 bits es la referencia actual y lo que deberías publicar; algunas configuraciones usan claves ed25519, cortas pero robustas. Rota las claves periódicamente sea cual sea su longitud, porque una clave que nunca cambia es una clave que nunca se recupera si se filtra. El verificador lee tu clave publicada y estima su tamaño para que distingas de un vistazo una clave moderna de 2048 bits de una heredada de 1024 bits.

DMARC: alineación, política e informes

DMARC es el registro que hace que SPF y DKIM sumen algo. Vive en _dmarc.<domain> como registro TXT que empieza por v=DMARC1 y cumple tres funciones: exige alineación, el dominio que superó SPF o DKIM debe coincidir con el dominio De visible, lo que cierra el resquicio por el que un mensaje supera SPF para un dominio ajeno mientras suplanta el tuyo; declara una política que dice a los receptores qué hacer cuando un mensaje falla; y solicita informes para que veas quién envía en tu nombre.

La política es la etiqueta p= y es una escalera que se sube, no un interruptor que se acciona. p=none es solo observación: los receptores siguen entregando el correo que falla pero te envían informes, y ahí es justo donde debería empezar cualquier despliegue, para observar el tráfico sin romper nada. p=quarantine indica a los receptores que traten el correo fallido como sospechoso, normalmente enviándolo a spam. p=reject les dice que lo rechacen sin más, y es el estado final que de verdad detiene la suplantación. Otras dos etiquetas modulan el despliegue: pct= aplica la política solo a un porcentaje del correo (una forma de subir reject desde el 10%), y un pct por debajo de 100 significa que la mayor parte del correo fallido sigue pasando.

La etiqueta rua= es donde envías los informes agregados: resúmenes XML diarios de los receptores que enumeran cada fuente que envía como tu dominio, cuáles superan o fallan la comprobación y de qué forma. Sin rua aplicas una política a ciegas; con ella puedes localizar a todos los remitentes legítimos antes de endurecer a reject, para no bloquear por accidente tus propias facturas o boletines. Un registro DMARC sin dirección de informes es el motivo más habitual de que un despliegue se quede en p=none para siempre.

Desplegar los tres en el orden correcto

El orden importa porque cada registro depende de los anteriores. Consigue primero que SPF y DKIM se superen y estén alineados, después coloca DMARC encima en modo observación y luego endurece. Saltar directamente a p=reject antes de haber confirmado que todos los remitentes legítimos están alineados es la forma de bloquear tu propio correo.

Un punto de partida mínimo y correcto se parece a los registros de abajo: un registro SPF que autorice a tu proveedor y haga fallar el resto de forma suave, una clave DKIM publicada en el selector de tu proveedor, y un registro DMARC en modo observación con una dirección de informes, para poder mirar antes de aplicar.

• Publica SPF primero: enumera todas las fuentes de envío y termina con ~all, por ejemplo v=spf1 include:_spf.google.com ~all. Vuelve a comprobar que el número de consultas se mantiene por debajo de diez.
• Añade DKIM: activa la firma en tu proveedor de correo y publica la clave pública en el selector que te indique (por ejemplo google._domainkey.example.com). Prefiere una clave de 2048 bits.
• Añade DMARC en modo observación: v=DMARC1; p=none; rua=mailto:reports@example.com. Recoge informes durante unas semanas y confirma que todos los remitentes reales pasan.
• Endurece de forma gradual: pasa de p=none → p=quarantine → p=reject, subiendo si quieres con pct=, solo cuando los informes muestren que todas las fuentes legítimas están alineadas.