Qué comprueba la consulta MX
La herramienta lee los registros MX del dominio y enumera cada servidor de correo con su valor de preferencia. Cuando los nombres de host coinciden con el patrón de un proveedor conocido, indica el proveedor probable. Después obtiene la política SPF de los registros TXT del dominio y la política DMARC de _dmarc bajo el dominio, analiza ambas e informa de los hallazgos.
Todo se lee del DNS público. La herramienta no se conecta a su servidor de correo, no envía mensajes de prueba ni mira dentro de ningún buzón.
Cómo leer los registros MX
Los servidores emisores prueban primero el servidor MX con el número de preferencia más bajo y pasan a números más altos solo si ese falla. Los números iguales reparten la carga. El destino de un MX debe ser un nombre de host que resuelva a una dirección; no debe ser una dirección IP ni un CNAME. Si un dominio no tiene ningún registro MX, los emisores recurren al registro A o AAAA del dominio, que rara vez es lo que alguien pretende.
Un dominio que nunca debe recibir correo puede publicar un MX nulo: un único registro con preferencia 0 y un solo punto como destino. Eso indica a los emisores que fallen de inmediato en lugar de reintentar durante días.
SPF: quién puede enviar en nombre del dominio
SPF es un registro TXT que empieza por v=spf1 y enumera los servidores autorizados a usar el dominio en la dirección del remitente del sobre. Los hallazgos buscan los errores que lo rompen en la práctica: más de un registro SPF, que hace fallar la evaluación por completo; mecanismos que requieren más de diez consultas DNS una vez seguidos los include; el mecanismo ptr, obsoleto; y un final +all, que autoriza a toda Internet.
Una política que termina en ~all pide a los receptores que traten con sospecha las demás fuentes, y -all les pide que las rechacen. Cualquiera de las dos es razonable combinada con DMARC. Un registro con ?all o sin mecanismo all apenas ofrece protección.
DMARC: política e informes
DMARC vincula SPF y DKIM con la dirección que la gente ve de verdad en la cabecera From. Un mensaje pasa cuando pasa SPF o DKIM y el dominio autenticado está alineado con el dominio del From. El registro indica qué deben hacer los receptores con los fallos (none, quarantine o reject) y adónde enviar los informes agregados.
p=none es el punto de partida correcto porque permite recopilar informes sin afectar a la entrega. No es un destino. Un dominio que se queda indefinidamente en p=none tiene visibilidad, pero ninguna protección frente a la suplantación. La herramienta muestra la política, la política de subdominios si existe, el valor pct y las direcciones de los informes.
Por qué DKIM necesita un selector
Las claves públicas DKIM se publican en selector._domainkey.example.com, y el selector es una etiqueta arbitraria que elige el sistema emisor. Un dominio puede tener muchos selectores y el DNS no ofrece ninguna forma de enumerarlos, así que ninguna herramienta puede descubrir una clave DKIM solo a partir del nombre de dominio. El selector se encuentra en la cabecera DKIM-Signature de un mensaje enviado desde el dominio, en la etiqueta s=; después puede consultar ese nombre con una consulta DNS.
Lo que estos registros no pueden demostrar
Unos registros MX, SPF, DKIM y DMARC correctos son necesarios para una entrega fiable, pero no garantizan que un mensaje llegue a la bandeja de entrada. Los proveedores de buzones también valoran la reputación del remitente, las tasas de quejas, el contenido y la interacción de los destinatarios, y nada de eso se ve en el DNS. Del mismo modo, una configuración limpia no demuestra que el correo esté fluyendo. Muestra que la política publicada es coherente, que es la parte que se puede corregir desde el DNS.