[ SPF ]

Por qué dos verificadores SPF pueden informar recuentos de búsqueda diferentes

Dos herramientas SPF pueden contar cosas diferentes o evaluar caminos diferentes. Concilie el dispositivo de entrada y el seguimiento antes de utilizar un recuento para aprobar un cambio DNS .

Por el equipo de investigación EmailAuth · 4 minutos de lectura

[Puntos clave]

  • Identifique si una herramienta cuenta términos evaluados, nodos de gráficos o consultas.
  • Utilice la misma IP, identidad SMTP e instantánea DNS .
  • Explique el primer paso diferente antes de cambiar la producción.
En esta página

cuando dos SPF Las fichas muestran diferentes recuentos de búsqueda, no elija el número más tranquilizador. Establecer qué midió cada herramienta. Uno puede mostrar términos dependientes de DNS en una ruta evaluada, otro puede expandir un gráfico de políticas y un tercero puede mostrar consultas de red. Esos resultados pueden responder diferentes preguntas incluso cuando inspeccionan el mismo dominio.

Pregunta qué significa el contador.

RFC 7208 sección 4.6.4 límites evaluaron los términos dependientes de DNS a lo largo de la recursividad. No se trata simplemente del recuento de todas las cadenas TXT , de cada paquete DNS o del número de inclusiones escritas visiblemente en el nivel superior. Las respuestas almacenadas en caché no otorgan un presupuesto de término lógico mayor.

Separe también otras restricciones. Las direcciones de especificación búsquedas nulas y límites específicos del mecanismo además del límite principal del período evaluado. Una herramienta puede presentar una advertencia combinada mientras que otra expone cada categoría. Guarde el texto de advertencia exacto y la documentación en lugar de asumir que cada etiqueta roja significa lo mismo.

Dale a ambas herramientas el mismo accesorio.

Registre el dominio evaluado, IP de conexión, identidad del remitente, HELO cuando sea relevante, vista de resolución y tiempo de consulta. Si la herramienta acepta sólo un dominio, averigüe si su recuento es una estimación estática, un análisis del peor de los casos o una ruta sintética particular. Un análisis de solo dominio no equivale automáticamente a evaluar una conexión real.

Para las políticas que utilizan macros, las entradas de identidad que faltan pueden importar directamente. Compare los casos de IPv4 e IPv6 por separado cuando ambos ocurren. Conserve las respuestas DNS o un dispositivo controlado reproducible para que un cambio de proveedor posterior no convierta una supuesta comparación de herramientas en una comparación de diferentes políticas.

Camina un pequeño ejemplo ilustrativo.

Considere una política sintética:

v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all

Bajo RFC 7208 §4.6.2 y RFC 7208 §5.6, para 192.0.2.10 la dirección explícita puede coincidir antes de que se evalúe la inclusión. Para otra dirección, la evaluación puede llegar a la inclusión y sus dependencias anidadas. Una herramienta de expansión de gráficos puede mostrar esa rama incluso cuando la ruta del primer mensaje nunca llega a ella. Los diferentes números necesitan una explicación, no un veredicto automático de que cualquiera de las herramientas está defectuosa.

Haga que el objetivo de inclusión sea explícito para comparar recuentos numéricos. En este accesorio sintético, _spf.vendor.example tiene exactamente un SPF registro TXT, v=spf1 ip4:192.0.2.20 -all. Suponga una recuperación DNS exitosa, sintaxis válida, sin dependencias adicionales y normal CORREO DE evaluación para el dominio principal.

  • Entrada 192.0.2.10 : el primer mecanismo ip4 del padre coincide. La ruta real evalúa 0 términos dependientes de DNS y nunca visita la inclusión.
  • Entrada 192.0.2.20 : la ip4 de los padres no coincide. Se evalúa la inclusión, su ip4 objetivo coincide y el padre devuelve aprobado. La ruta real evalúa un término dependiente de DNS, el include.
  • Entrada 192.0.2.30 : el objetivo de inclusión alcanza -all y los retornos fallan, por lo que la inclusión no coincide. El padre alcanza su propio -all y los retornos fallan. La ruta real aún evalúa 1 término dependiente de DNS, de acuerdo con RFC 7208 §5.2.

Un recuento de gráficos estáticos de términos dependientes de DNS es 1 para todo este dispositivo, independientemente de la conexión seleccionada. Se requiere la recuperación TXT inicial de la póliza principal, pero no es en sí misma uno de los términos evaluados que se cuentan para este límite. Por lo tanto, se puede explicar una visualización de 0 para la primera entrada y de 1 para el gráfico expandido. Estos son resultados analíticos esperados, no mediciones ejecutadas ni recuentos de paquetes de red.

Ahora imagine que la política incluida cambia entre los dos escaneos. Un nuevo análisis podría exponer legítimamente un árbol de dependencia diferente. Guarde marcas de tiempo y respuestas reales antes de intensificar el desacuerdo. Una captura de pantalla sin entradas es una prueba débil.

Comparar trazas en la primera divergencia.

Cree una lista en paralelo de los términos evaluados. Encuentre el primer lugar en el que las herramientas no están de acuerdo: selección de registros, una coincidencia temprana, recursividad, un error DNS , una expansión macro o una convención de conteo. Compruebe si uno se detiene ante un error mientras el otro continúa con fines de diagnóstico. Una ampliación del diagnóstico puede resultar útil sin representar una evaluación completa válida.

Si una herramienta parece contradecir el estándar, produzca una fijación sintética mínima y el comportamiento esperado con una referencia de sección. Envíelo al mantenedor de la herramienta a través de su proceso de soporte normal, evitando datos de producción confidenciales donde bastará con un accesorio. No altere la producción sólo para que los paneles inconsistentes coincidan.

Tomar una decisión a partir de la evidencia resuelta.

Una ruta corta válida para un remitente no establece el estado de todos los remitentes. Pruebe entradas legítimas representativas y una entrada que no coincida, e inspeccione las dependencias que podrían cambiar más adelante. Por el contrario, un gráfico estático de gran tamaño no es por sí solo una prueba de que cada mensaje excede el límite de términos evaluados.

Registre qué medición respalda su decisión, cualquier limitación de herramienta no resuelta y el impacto esperado de un cambio propuesto. Usar ordenamiento del mecanismo sólo después de comprender esos caminos. Si no puede conciliar una discrepancia consecuente, conserve la evidencia actual y busque una revisión específica de la implementación en lugar de presentar un recuento inexplicable como certeza.

Poner la decisión por escrito.

Para el dispositivo de dos registros dado, conserve el texto principal y secundario, la dirección de entrada, la definición del conteo y la aprobación/falla esperada. Los valores 0/1/1 son recuentos analíticos de términos evaluados, no paquetes DNS medidos ni ejecución de herramientas independientes. Si una herramienta informa una cantidad diferente, etiquétela antes de comparar. Una discrepancia en una ruta de manejo de errores necesita su propio arreglo en lugar de una extrapolación de estas búsquedas exitosas.

[ Llevar ]

Identifique si una herramienta cuenta términos evaluados, nodos de gráficos o consultas. Utilice la misma IP, identidad SMTP e instantánea DNS . Explique el primer paso diferente antes de cambiar la producción.

[ Por rol ]

¿Qué significa esto para ti?

Elija su función para conocer los próximos pasos prácticos.

Administrador de TI/correo

Reproduzca la primera divergencia.

Un seguimiento con entradas fijas es más útil que totales competitivos.

Próximos pasos

  1. Guarde respuestas DNS y marcas de tiempo.
  2. Distinga la expansión del gráfico de la ejecución.
  3. Compara errores, recursividad y coincidencias tempranas.

CISO / Operaciones de seguridad

Preservar la incertidumbre honestamente.

Las diferencias de herramientas no resueltas son una limitación de la evidencia, no una prueba de seguridad o falla.

Próximos pasos

  1. Requerir una base de conteo documentada.
  2. Utilice accesorios mínimos para la escalada.
  3. Revise rutas no probadas y cambios de dependencia.

Fundador / No técnico

Requiere una explicación de la decisión.

Los números conflictivos del tablero deben resolverse antes de que justifiquen una interrupción operativa.

Próximos pasos

  1. Pregunta qué mide cada número.
  2. Mantenga visibles los casos de prueba críticos para el negocio.
  3. Evite cambios realizados sólo para mejorar una puntuación.

[ Preguntas frecuentes ]

Preguntas frecuentes

¿Qué corrector SPF es correcto?

Determine si midieron primero los mismos insumos y cantidades. Una diferencia por sí sola no es suficiente para elegir un ganador.

¿Cada paquete DNS cuenta para el límite de diez términos?

No. El límite principal SPF se refiere a términos dependientes de DNS evaluados y especificados, no a un contador de paquetes.

RFC 7208 §4.6.4

¿El almacenamiento en caché reduce el recuento de términos lógicos SPF ?

No. Puede afectar el trabajo de resolución real o la latencia, pero no crea una asignación de protocolo mayor.

RFC 7208 §4.6.4

¿Por qué un verificador de solo dominio muestra más trabajo?

Puede expandir ramas a las que una conexión particular no llegaría. Consulte el método documentado de la herramienta.

RFC 7208 §4.6.2

¿Puede un cambio de proveedor explicar resultados diferentes?

Sí. Compare los datos DNS y las marcas de tiempo reales, no solo el nombre de dominio.

¿Las búsquedas nulas son el mismo contador?

No. Son una restricción distinta que se analiza junto con el límite del mandato evaluado. Conservar la categoría reportada por la herramienta.

RFC 7208 §4.6.4

¿Qué es un informe de error útil?

Proporcione un accesorio mínimo, entradas exactas, seguimiento observado, comportamiento esperado y la sección de especificaciones relevante.

¿Puedo aprobar un cambio si solo pasa un remitente?

Esa evidencia cubre sólo el camino probado. Evalúe otras rutas legítimas y un caso que no coincida antes de sacar una conclusión más amplia.

[ Fuentes ]

Fuentes

  1. RFC 7208

    Secciones §2.4 · §4.1 · §4.6.2 · §4.6.4 · §5.1 · §5.2 · §5.6 · §7

[ Glosario ]

Glosario

SPF
Evaluación de autorización para una IP de conexión y la identidad SMTP relevante.

RFC 7208 §2.4

SPF incluye
Evaluación recursiva cuyo pase hace que la inclusión coincida; el calificador de inclusión determina el resultado externo.

RFC 7208 §5.2

Límite de plazo evaluado dependiente del DNS
El límite de diez términos específicos que provocan consultas de DNS alcanzado durante la evaluación, incluidas las comprobaciones recursivas, distintos de un recuento de paquetes.

RFC 7208 §4.6.4

Procedencia de la empresa

Por qué las principales instituciones financieras y gobiernos retiraron sus paneles de seguridad de correo electrónico.

Las plataformas tradicionales de autenticación de correo electrónico le venden un panel y piden a sus ingenieros que hagan el trabajo. En entornos de alto riesgo, la supervisión manual significa retrasos en la aplicación, cambios en la configuración y dominios en la sombra no monitoreados.

EmailAuth es la plataforma de procedencia de correo electrónico agente. Nuestros agentes hacen cumplir p=reject, mantenga alineados a los remitentes externos y mueva sus dominios al máximo RFC 9989 cumplimiento, el nuevo estándar DMARC , con auditabilidad humana.

Gobiernos Grandes empresas Instituciones financieras de primer nivel

SaaS · Arrendamiento dedicado · Air-gapped on-premise · Cifrado BYOK

Base de conocimientos