¿Cómo se verifica un registro SPF para el correo de una aplicación?

Empiece por la identidad que SPF realmente comprueba

Una verificación SPF necesita tres datos: la dirección IP del cliente SMTP, el dominio cuya política de autorización se evalúa y la identidad del remitente. En el correo habitual de una aplicación, ese dominio se toma de la dirección SMTP MAIL FROM, también llamada remitente del sobre o return path. Puede ser distinta de la dirección que las personas ven en el encabezado From del mensaje. Si MAIL FROM está vacío, como suele ocurrir en una notificación de estado de entrega, SPF usa la identidad HELO para la comprobación de MAIL FROM. Registre la IP de conexión real y la identidad del sobre a partir de un mensaje de prueba recibido o de la configuración del proveedor de envío antes de consultar el DNS. Comprobar example.test porque aparece en From no es concluyente cuando la aplicación en realidad envía con MAIL FROM en bounce.provider.test o bounces.example.test.

Consulte TXT en el dominio MAIL FROM exacto

Consulte el TXT del DNS en el dominio exacto seleccionado en el primer paso. RFC 7208 exige que las políticas SPF versión 1 se publiquen como registros TXT en el nombre de propietario que rigen. Ignore los valores TXT no relacionados y seleccione los registros cuya sección de versión sea exactamente v=spf1. Si no se selecciona ningún registro, el resultado SPF es none. Si se selecciona más de un registro SPF, el resultado es permerror; publicar registros separados para distintos proveedores no es una forma válida de combinarlos. Las herramientas DNS pueden dividir un único registro de recurso TXT en cadenas de caracteres entre comillas, pero esas cadenas se concatenan sin insertar espacios antes de analizar SPF. Capture la respuesta completa, el resolvedor, la hora de la consulta y el TTL para poder repetir la verificación después de un cambio.

Valide la sintaxis y evalúe los términos de izquierda a derecha

Un registro SPF es una política ordenada, no una lista desordenada de proveedores. Después de v=spf1, los mecanismos se evalúan de izquierda a derecha hasta que uno coincide. Un calificador inicial controla el resultado: + significa pass y es el valor predeterminado, - significa fail, ~ significa softfail y ? significa neutral. Los mecanismos ip4 e ip6 comparan la dirección del cliente con una dirección o red. Los mecanismos a y mx resuelven DNS, mientras que include evalúa la política SPF de otro dominio y solo coincide según las reglas de include. exists realiza una prueba basada en DNS. all siempre coincide y suele cerrar el registro. Un error de sintaxis en cualquier parte provoca permerror antes de la evaluación normal. Un verificador útil debería indicar qué mecanismo coincidió, su calificador y cada dominio expandido, en lugar de devolver solo una insignia de color.

Siga include y redirect sin tratarlos como alias

Siga cada include y redirect dentro del mismo contexto de evaluación. Include es un mecanismo: pregunta si la política incluida devuelve pass para el cliente y el remitente actuales y, si no coincide, continúa en el registro original. Redirect es un modificador que se tiene en cuenta cuando ninguno de los mecanismos del registro actual coincide; transfiere la evaluación a otra política conservando la IP del cliente y el remitente. Un redirect se ignora si all aparece en cualquier parte del registro. Estas diferencias importan durante las migraciones. Sustituir include:vendor.test por redirect=vendor.test puede reemplazar toda la política de respaldo del propietario del dominio en lugar de simplemente agregar un proveedor. Detecte ciclos, destinos inexistentes, destinos no válidos y errores permanentes o transitorios anidados, y conserve la cadena de dependencias en el resultado para que un cambio de política del lado del proveedor sea visible.

Cuente el presupuesto completo de consultas DNS

Cuente los términos que generan consultas DNS en toda la evaluación recursiva, no solo en el registro de nivel superior. RFC 7208 limita los términos include, a, mx, ptr, exists y redirect a diez durante una misma evaluación SPF; superar el límite exige un permerror. Los mecanismos all, ip4 e ip6 no consumen ese presupuesto de términos. El procesamiento de MX y PTR tiene límites adicionales de consultas de direcciones. La RFC también recomienda limitar a dos las consultas vacías (void lookups), es decir, respuestas vacías exitosas o errores de nombre, y producir permerror cuando se supera ese límite. Se desaconseja el mecanismo ptr porque es lento y poco confiable. Un registro puede parecer corto mientras los include de los proveedores se expanden en suficientes términos anidados como para fallar, así que informe el total, cada término que contribuye, las consultas vacías y la rama exacta seguida para la IP probada.

Interprete el resultado SPF sin exagerar su alcance

Use el vocabulario de resultados estándar. Pass significa que el cliente probado está autorizado a usar la identidad SMTP comprobada. Fail significa que se encontró una autorización negativa coincidente. Softfail es una declaración negativa débil, mientras que neutral indica que el dominio no hace ninguna afirmación sobre ese cliente. None significa que no se seleccionó ningún registro SPF. Temperror refleja un problema transitorio de evaluación, normalmente de DNS; permerror refleja una política que no se puede evaluar correctamente. Si ningún mecanismo coincide y no se aplica ningún redirect, el resultado es neutral, equivalente a un ?all implícito. Informe el resultado junto con la identidad, la IP del cliente, el término coincidente, la traza DNS y la hora. No interprete pass como mensaje seguro, correo deseado, aceptación del proveedor, entrega en el buzón o llegada a la bandeja de entrada, porque SPF no decide esos resultados.

Verifique un mensaje real, no solo el registro publicado

Una verificación estática del registro responde si una política se puede descubrir y analizar. No demuestra que la aplicación haya usado el dominio MAIL FROM o la IP saliente esperados. Envíe un mensaje controlado por cada ruta real de producción a una cuenta destinataria que usted administre y luego inspeccione los encabezados recibidos. Compare la IP de conexión, el remitente del sobre y la entrada Authentication-Results del receptor con la evaluación DNS. Repita el proceso para cada proveedor, región, pool dedicado o compartido, ruta de respaldo y clase de mensaje que pueda cambiar el return path. Conserve los encabezados en un almacenamiento restringido, porque las direcciones y los datos de enrutamiento pueden ser sensibles. Si el panel de un proveedor y el mensaje recibido no coinciden, el mensaje es una evidencia más sólida de la ruta que realmente se ejecutó, aunque el resultado de un solo receptor no debe generalizarse como comportamiento de entrega universal.

Evalúe la alineación DMARC como un paso aparte

SPF puede dar pass para un dominio de return path propiedad del proveedor y, aun así, DMARC no puede usar ese resultado. Las reglas actuales de DMARC comparan el dominio RFC5321.MailFrom autenticado con éxito por SPF con el dominio del autor en el campo visible RFC5322.From. La alineación estricta exige el mismo dominio DNS. La alineación relajada admite dominios que se resuelven al mismo dominio organizativo según las reglas de descubrimiento de DMARC. Por ejemplo, bounces.example.test y example.test pueden estar alineados en modo relajado, mientras que bounce.provider.test y example.test no. En su lugar, un resultado DMARC puede basarse en una firma DKIM alineada y verificada, de modo que un resultado SPF no alineado no significa por sí solo que DMARC falle. Informe la autenticación y la alineación por separado, y use el procedimiento actual de descubrimiento de dominios en lugar de una comparación rígida de las dos últimas etiquetas.

Pruebe la configuración de MAIL FROM específica de cada proveedor

La configuración del proveedor determina qué identidad SPF aparece en la conexión. Amazon SES, por ejemplo, documenta un dominio MAIL FROM personalizado que necesita su propio registro MX y su propio registro TXT de SPF. SES puede recurrir a un dominio MAIL FROM de amazonses.com que depende de la región cuando el MX del dominio personalizado está mal configurado, o puede rechazar el envío, según el comportamiento configurado. Ese respaldo puede cambiar la alineación DMARC incluso cuando la dirección From visible no cambia. Para cualquier proveedor, registre el dominio de return path configurado, los valores DNS requeridos, el comportamiento de respaldo, las regiones de envío y el responsable. Después de un cambio de DNS o de proveedor, espere a que caduquen las respuestas en caché pertinentes y luego repita la evaluación DNS y los envíos controlados. No copie el include de un proveedor en el dominio From visible a menos que esa sea la identidad real y el inventario completo de remitentes del dominio lo respalde.

Use una auditoría SPF reproducible durante los cambios

Mantenga una fila por cada ruta de envío con un responsable, la aplicación, la clase de mensaje, el dominio From visible, el dominio MAIL FROM, el dominio HELO, los rangos de origen esperados, la dependencia del proveedor y la fecha de la última prueba controlada. Guarde cada verificación SPF con el registro seleccionado, la traza recursiva, el número de consultas DNS, el mecanismo coincidente, el resultado, la decisión de alineación y un identificador de prueba no sensible. Durante una migración, mantenga autorizadas las fuentes legítimas antiguas y nuevas solo durante el periodo de transición necesario, verifique la nueva ruta y luego elimine deliberadamente la autorización obsoleta. Monitoree los errores de autenticación permanentes y transitorios en lugar de reaccionar solo ante los rechazos. Vuelva a ejecutar la auditoría después de cambios de proveedor, movimientos de pools de IP, cambios de dominio, ediciones de DNS o nuevas aplicaciones. Este flujo detecta tanto las políticas demasiado estrechas que bloquean rutas legítimas como las demasiado amplias que conservan autorizaciones sin uso.

Compruebe SendHQ con el mismo estándar de evidencia

SendHQ documenta que un envío directo debe usar una dirección de un dominio verificado del espacio de trabajo. Eso verifica la identidad del remitente, pero no reemplaza una evaluación de SPF. Un mensaje controlado de SendHQ aún necesita el mismo rastreo de DNS, inspección del encabezado recibido, resultado SPF y comprobación de alineación DMARC descritos anteriormente.

Preguntas frecuentes

Fuentes

• RFC 7208: Sender Policy Framework (SPF), marco de políticas del remitente — IETF
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — IETF
• RFC 9989: autenticación, informes y conformidad de mensajes basados en dominios (DMARC) — RFC Editor
• Uso de un dominio MAIL FROM personalizado en Amazon SES — Amazon Web Services
• Contrato OpenAPI de SendHQ — SendHQ