Esta herramienta se ejecuta en el servidor
Cómo funciona
El protocolo de correo no verifica quién envía: cualquier servidor puede poner tu dominio en el remitente. Tres registros DNS cierran esa puerta. SPF enumera qué servidores pueden enviar en nombre del dominio. DKIM firma cada mensaje con una clave privada cuya pública se publica en el DNS. DMARC une a los dos: exige que al menos uno pase y coincida con el dominio visible del remitente, indica al receptor qué hacer con lo que falla y pide informes de todo lo que se envió con tu nombre.
Desde febrero de 2024, Gmail y Yahoo exigen SPF, DKIM y DMARC a quien envía más de 5000 mensajes diarios a sus usuarios, y la falta de cualquiera de ellos se traduce en correos rechazados o en la carpeta de spam. Por eso conviene revisar los tres juntos: un SPF impecable sirve de poco sin DMARC, y un DMARC en reject con un DKIM mal publicado deja fuera tu propio correo.
La verificación se hace desde nuestro servidor con consultas DNS públicas, igual que las haría cualquier servidor de correo. SPF se evalúa completo, siguiendo cada include y redirect para contar las consultas DNS, porque pasar el límite de 10 anula el registro entero. Además se consultan los registros MX y los opcionales MTA-STS, TLS-RPT y BIMI.
Ejemplos
github.comSPF · 10 / 10Ocho includes de proveedores (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) y los que ellos incluyen llevan la evaluación justo al límite de 10 consultas DNS. Un proveedor más y el SPF entero pasaría a dar error permanente.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sLa configuración correcta para un dominio que no envía ni recibe correo: MX nulo, SPF que no autoriza a nadie y DMARC en reject. Protege a los dominios aparcados, que son un blanco habitual de la suplantación.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Un despliegue gradual: solo uno de cada cuatro mensajes que fallan va a spam, y los informes llegan al buzón indicado en rua para detectar remitentes legítimos que todavía no están autenticados.Casos de uso
- Diagnosticar por qué los correos del dominio llegan a spam o los rechaza Gmail, Outlook o Yahoo.
- Comprobar que el SPF no supere las 10 consultas DNS antes de añadir un proveedor nuevo de envíos, como un CRM o una plataforma de newsletters.
- Verificar que la clave DKIM de un proveedor quedó bien publicada después de configurarla.
- Planificar el paso de DMARC de none a quarantine y a reject sin cortar el correo legítimo.
- Auditar los dominios de un cliente o de una empresa adquirida, incluidos los aparcados que no deberían enviar correo.
- Revisar la configuración de un remitente sospechoso durante el análisis de un phishing.
Preguntas frecuentes
¿Por qué dice que no encontró DKIM si mi dominio firma los correos?
Porque DKIM no permite listar las claves de un dominio: cada una vive en <selector>._domainkey.<dominio> y hay que conocer el selector para consultarla. La herramienta prueba los selectores más usados, pero muchos proveedores usan nombres propios o con fecha. Abre un correo enviado desde el dominio, busca la cabecera DKIM-Signature y copia el valor de s=; con ese selector la verificación es exacta.
¿Qué pasa si el SPF supera las 10 consultas DNS?
La RFC 7208 obliga al receptor a devolver un error permanente (permerror), y para DMARC eso cuenta como que SPF falló. Consumen consultas los mecanismos include, a, mx, ptr y exists y el modificador redirect, incluidos los que aparecen dentro de cada include; ip4 e ip6 no consumen. Para bajar el número se quitan proveedores que ya no se usan, se sustituyen includes por rangos ip4 o se envía desde subdominios con su propio SPF.
¿~all o -all?
Con DMARC activo la diferencia es menor: el receptor aplica la política DMARC y no el calificador de SPF. ~all es lo habitual porque algunos receptores rechazan en el acto con -all antes de evaluar DKIM, y eso puede hacer perder correo reenviado que DKIM habría salvado. Sin DMARC, -all es la única forma de pedir que lo no autorizado se rechace.
¿Cómo paso DMARC de none a reject sin perder correo?
Empieza en p=none con una dirección en rua y lee los informes agregados durante unas semanas: muestran cada servidor que envía con tu dominio y si pasa SPF o DKIM. Autentica a los remitentes legítimos que falten, pasa a quarantine con pct bajo, sube pct poco a poco y termina en reject. El salto directo a reject suele dejar fuera sistemas de facturación, CRMs o sistemas internos que nadie recordaba.
¿Basta una clave DKIM de 1024 bits?
Funciona, porque la RFC 8301 exige a los receptores aceptar claves de 1024 a 4096 bits, pero la misma norma recomienda que quien firma use al menos 2048. Las claves por debajo de 1024 no se consideran válidas. Rotar a 2048 es sencillo: se publica la clave nueva con otro selector, se cambia la firma y después se revoca la vieja dejando p vacío.
¿Para qué sirven MTA-STS, TLS-RPT y BIMI?
MTA-STS (RFC 8461) pide a los servidores que envían que exijan TLS al entregar en tus MX, lo que evita ataques que degradan la conexión a texto plano. TLS-RPT (RFC 8460) te hace llegar informes cuando esas entregas fallan. BIMI muestra el logotipo de la marca junto al remitente en los clientes que lo admiten, y solo funciona con DMARC en quarantine o reject. Ninguno es obligatorio, pero los tres suman.