Compruebe un registro SPF, expanda cada include y cuente las consultas DNS frente al límite de 10
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Un comprobador de SPF lee el registro TXT que indica qué servidores pueden enviar correo por un dominio, sigue cada include y redirect y cuenta las consultas DNS. RFC 7208 permite como máximo 10 consultas y 2 vacías; un registro que supera cualquiera de los dos límites falla en todos los receptores, por correcto que parezca.
Esta página se ha traducido automáticamente del original en inglés. Ninguna persona ha revisado todavía la traducción, así que la versión en inglés es la que debe consultar. Leer el original en inglés
Escriba el dominio, como example.com, en el campo Dominio.
Pulse Comprobar SPF para leer el registro y seguir cada include.
Lea, bajo el veredicto, el número de consultas DNS de 10 y cómo termina el registro.
Lea Expandido, con cada consulta numerada para ver qué include añade más consultas.
Pulse Copiar el árbol para guardar el registro expandido.
Escriba un dominio y la página pide a un resolver público de DNS sobre HTTPS (Cloudflare o Google, a su elección) sus registros TXT, elige el que empieza por v=spf1 y lo lee término a término. Se sigue cada include: y redirect=, y los registros a los que apuntan se leen igual, de modo que todo el árbol de redes permitidas queda en una sola pantalla.
Lo que cuenta es el número de consultas DNS. La sección 4.6.4 de RFC 7208 limita una comprobación a 10 términos que necesitan DNS: include, a, mx, ptr, exists y redirect cuentan uno cada uno, estén donde estén en el árbol, mientras que ip4, ip6 y all no cuentan nada. Cada término contado está numerado en el árbol, así que cuando un registro se pasa puede ver qué include lo llevó ahí. Las consultas que no encuentran nada, llamadas consultas vacías (void), están limitadas a 2, y un nombre que ya no existe se muestra como void.
El veredicto indica lo que harán realmente los receptores: dos registros SPF en un mismo nombre son un error permanente, +all deja que cualquiera envíe como el dominio, ?all o la falta de all no da respuesta para servidores no listados, ptr se desaconseja y los términos después de all nunca se leen. ~all pide a los receptores marcar el correo de servidores no listados; -all les pide hacerlo fallar. Cada línea cita la sección de RFC 7208 de la que procede.
Lo que no hace: comprueba el registro, no un mensaje. Los términos con macros como %{i} se rellenan con la dirección de envío de cada mensaje, así que se cuentan pero no se consultan. No puede decir si la dirección de un servidor concreto está cubierta, salvo que esa dirección aparezca en el registro.
La pestaña del generador escribe un registro a partir de sus elecciones, con los include de Google Workspace y Microsoft 365 que documentan esos proveedores, y muestra cuántas consultas usa antes de las propias de los proveedores.
El dominio que escribe se envía al resolver que elija, porque una consulta lo necesita. Nada más sale de su dispositivo.
RFC 7208 permite a un receptor hacer como máximo 10 consultas DNS al comprobar un registro SPF, contando cada include, a, mx, ptr, exists y redirect de todo el árbol. Por encima de 10, el resultado es un error permanente y SPF falla para todos los mensajes, incluso de servidores que el registro incluye.
Ambos son válidos. Un registro que termina en -all pide a los receptores hacer fallar el correo de servidores no listados; ~all les pide aceptarlo pero marcarlo como sospechoso. Muchos dominios empiezan con ~all mientras localizan a todos los remitentes y luego pasan a -all. Terminar con +all o sin all no da ninguna protección.
No. RFC 7208 dice que un dominio debe publicar exactamente un registro TXT que empiece por v=spf1. Con dos, los receptores no pueden elegir y devuelven un error permanente, así que SPF falla para todo el correo. Únalos en un solo registro, conservando todos los include y direcciones de ambos.
Un término ip4 o ip6 ya contiene el rango de direcciones, así que comprobarlo no necesita ninguna consulta DNS. Include, a, mx, exists, ptr y redirect necesitan al menos una consulta para saber qué representan. Sustituir un include estable por sus rangos de direcciones es la forma habitual de bajar de 10.
Sí, el nombre de dominio va al resolver de DNS público que elija, Cloudflare o Google, porque una consulta DNS lo necesita. El resolver ve los nombres consultados y su dirección IP, como en cualquier consulta DNS. Nada más sale de su dispositivo, y este sitio no guarda nada sobre la comprobación.
Una consulta vacía es una consulta DNS que no encuentra nada: el nombre no existe, o existe sin registros del tipo pedido. RFC 7208 pide a los receptores permitir como máximo 2, porque un registro lleno de nombres muertos es un ataque habitual contra los receptores. Elimine los nombres que ya no existen.
¿Sigue sin resolverlo? Pregunte sobre Comprobador de SPF y cualquiera que lo sepa puede responder. No se necesita cuenta.