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, le dice al receptor qué hacer con lo que falla y pide reportes 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 no sirve de mucho sin DMARC, y un DMARC en reject con un DKIM mal publicado deja afuera 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 estacionados, que son un blanco habitual de la suplantación.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Un despliegue gradual: sólo uno de cada cuatro mensajes que fallan va a spam, y los reportes llegan a la casilla indicada 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 sumar 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 estacionados 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. Abrí un correo enviado desde el dominio, buscá la cabecera DKIM-Signature y copiá 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 reemplazan 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?
Empezá en p=none con una dirección en rua y leé los reportes agregados durante unas semanas: muestran cada servidor que envía con tu dominio y si pasa SPF o DKIM. Autenticá a los remitentes legítimos que falten, pasá a quarantine con pct bajo, subí pct de a poco y terminá en reject. El salto directo a reject suele dejar afuera facturadores, CRMs o sistemas internos que nadie recordaba.
¿Alcanza 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) le 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 reportes cuando esas entregas fallan. BIMI muestra el logo de la marca junto al remitente en los clientes que lo soportan, y sólo funciona con DMARC en quarantine o reject. Ninguno es obligatorio, pero los tres suman.