¿Qué es la sintaxis del registro SPF y cómo afecta al correo de las aplicaciones?

Un registro SPF es una expresión de política ordenada

RFC 7208 define un registro SPF como una cadena DNS TXT cuyo primer término es v=spf1. Los demás términos, separados por espacios, son mecanismos, que pueden coincidir, y modificadores, que cambian el procesamiento. La evaluación avanza de izquierda a derecha y se detiene en el primer mecanismo que coincide, así que el orden expresa la política. Un registro típico podría autorizar dos rangos de direcciones fijos, incluir la política de un proveedor y terminar con -all. No pegue ese patrón sin cambios: el registro correcto depende de las identidades SMTP MAIL FROM o HELO exactas y de las fuentes de envío reales. Primero haga un inventario de los proveedores de la aplicación, los servidores de correo, las herramientas de soporte, las plataformas de identidad, los sistemas de marketing, las rutas de reenvío y los remitentes de recuperación ante desastres. Publique la política en el dominio que se evalúa, no automáticamente en el dominio From visible. Un registro sintácticamente válido puede aun así autorizar fuentes equivocadas, omitir un flujo de producción o superar los límites de evaluación DNS.

Los calificadores asignan a cada coincidencia de mecanismo un resultado SPF

Un mecanismo puede empezar con un calificador: + para pass, - para fail, ~ para softfail o ? para neutral. Si no aparece ningún calificador, se asume +. El calificador solo se aplica cuando ese mecanismo coincide. No cambia si se evalúan los términos posteriores cuando el mecanismo no coincide. Los equipos suelen centrarse en el término all final, pero cada mecanismo include, de dirección, a, mx o exists anterior también tiene un calificador y puede terminar la evaluación. Haga una revisión explícita en lugar de suponer que ~all significa modo de prueba o que -all demuestra que se conocen todas las fuentes. Un resultado fail es evidencia para el receptor sobre la identidad SMTP y la IP evaluadas, no una orden universal de eliminar el correo. Los receptores aplican su política local. Neutral y softfail no son aprobaciones de autorización. Registre el resultado previsto para las fuentes autorizadas, no autorizadas y temporalmente sin resolver, y verifíquelo con casos de prueba controlados de IP e identidad.

Los mecanismos de dirección son directos, pero requieren un responsable

Los mecanismos ip4 e ip6 autorizan los rangos de red coincidentes, expresados con la sintaxis propia de cada protocolo y una longitud de prefijo opcional. Evitan consultas de direcciones adicionales durante la evaluación, pero pueden quedar desactualizados cuando cambian las redes de salida. Use direcciones de envío públicas, nunca direcciones privadas del entorno de ejecución, y mantenga los rangos tan reducidos como permita la conmutación por error operativa. Cada rango debe tener un responsable, un sistema de origen, un entorno, un procedimiento de cambio y una fecha de revisión. El mecanismo a resuelve un nombre A o AAAA y, de forma predeterminada, usa el dominio SPF actual salvo que se indique otro domain-spec. El mecanismo mx resuelve los hosts MX y sus direcciones. Estos mecanismos agregan trabajo de DNS y pueden autorizar infraestructura que cambia fuera del ciclo de versiones de la aplicación. No use a ni mx como atajo a menos que todas las direcciones resueltas estén autorizadas intencionadamente a enviar con esa identidad SMTP exacta. Monitoree los cambios y pruebe tanto las rutas IPv4 como las IPv6.

Include evalúa otra política, no un fragmento de texto

El mecanismo include evalúa la política SPF del dominio referenciado y coincide cuando esa evaluación anidada devuelve pass. No pega mecánicamente los términos en la cadena actual, y los demás resultados anidados tienen efectos definidos. Use include solo cuando la organización referenciada documente explícitamente ese dominio para su relación de envío. El dominio del sitio web de un proveedor, su dominio MX o su dominio From visible no son automáticamente su include de SPF. Los includes crean dependencias operativas: un cambio en el registro de un proveedor puede alterar la autorización, agregar consultas DNS anidadas o producir errores temporales y permanentes. Registre el proveedor, el servicio, el dominio include exacto, la fuente contractual, el responsable y el plan de retirada. Pruebe la política resultante desde la IP de envío real del proveedor y su dominio del sobre. Nunca aplane los includes de un proveedor en listas de IP copiadas, a menos que también asuma la responsabilidad de seguir cada cambio de direcciones del proveedor y de conservar la semántica original.

All, redirect y la explicación cumplen funciones distintas

El mecanismo all siempre coincide y normalmente se coloca al final; los términos posteriores no pueden afectar a la evaluación. Su calificador determina el resultado para las fuentes que no coincidieron antes. El modificador redirect indica a SPF que use la política de otro dominio cuando ningún mecanismo del registro actual coincidió. Redirect no es lo mismo que include: include es un mecanismo ordenado más, mientras que redirect reemplaza la decisión final de la política en las condiciones definidas. Un registro no debe contener varios modificadores redirect. El modificador exp puede hacer referencia a una explicación para un resultado fail, pero no autoriza correo y crea consideraciones operativas y de privacidad adicionales. Mantenga las explicaciones genéricas y evite incluir datos del remitente o del destinatario. Elija redirect cuando los dominios compartan intencionadamente toda una política y tengan una gestión coordinada. Elija include cuando quiera agregar las fuentes autorizadas de un proveedor dentro de una política local más amplia. Pruebe las rutas sin coincidencia, no solo las aprobaciones esperadas.

Evite ptr y trate exists y las macros como funciones avanzadas

RFC 7208 indica que no se debe usar el mecanismo ptr porque es lento, poco confiable y costoso. No agregue ptr para que apruebe una IP desconocida. El mecanismo exists puede hacer una prueba de existencia en DNS con un domain-spec, y las macros de SPF pueden expandir componentes de la identidad y de la conexión dentro de los campos admitidos. Estas herramientas pueden expresar una autorización delegada o por cliente, pero aumentan la complejidad, el trabajo de DNS, la exposición de la privacidad y los modos de fallo. La sintaxis de las macros no es una plantilla de cadenas arbitraria; solo son válidos los siguientes elementos: letras, transformadores, delimitadores y contextos definidos. Nunca coloque direcciones completas de destinatarios, secretos ni entradas sin límite de los inquilinos en las consultas DNS. Si un conjunto sencillo de rangos de IP propios e includes de proveedores documentados puede expresar la política, dé preferencia a esa opción. Para las políticas avanzadas, cree casos de prueba deterministas para varios dominios, remitentes, familias de IP, rutas inversas nulas, escape de macros, NXDOMAIN, tiempos de espera y respuestas DNS inesperadas antes de pasar a producción.

Respete el límite de diez consultas DNS

RFC 7208 limita las implementaciones de SPF a diez términos que generan consultas DNS durante una comprobación, incluido el procesamiento de include, a, mx, ptr, exists y redirect correspondiente. Los includes anidados cuentan. La especificación también recomienda limitar a dos las consultas vacías, en las que el DNS devuelve una respuesta vacía o un error de nombre. Superar los límites de procesamiento puede producir un error permanente en lugar de un pass. Cuente el grafo de evaluación expandido, no solo los términos visibles en la cadena TXT de primer nivel. Un solo include de un proveedor puede traer varias dependencias anidadas, y un mecanismo mx puede desencadenar consultas de direcciones para varios hosts. Use un evaluador que respete los estándares con capturas de DNS fijas, pero inspeccione también usted mismo el árbol de dependencias. Elimine los proveedores sin uso y los mecanismos redundantes. Evite los aplanamientos poco seguros que pierden en silencio las actualizaciones del proveedor. Monitoree los cambios de política y deje margen de consultas para la evolución de los proveedores, en lugar de desplegar justo en el máximo.

Publique exactamente una política SPF por dominio

RFC 7208 usa registros DNS TXT para SPF y exige seleccionar el registro que empieza por v=spf1. Varios registros SPF para el mismo nombre exacto provocan un error permanente en lugar de combinar la autorización. Modifique la política existente con una gestión coordinada; no agregue un segundo registro TXT porque otra aplicación necesite acceso. Otros registros TXT no relacionados pueden coexistir en ese nombre, pero solo debe existir una política SPF seleccionada. Confirme cómo el panel de control DNS gestiona el entrecomillado y la división de cadenas, consulte los servidores autoritativos y después resolvedores recursivos independientes. Conserve el valor y el TTL anteriores para la reversión. La propagación del DNS no es instantánea y las cachés negativas pueden persistir. Una marca verde en un panel solo demuestra la consulta que observó y el comportamiento de su analizador. Verifique el dominio del sobre de producción exacto a partir de los encabezados recibidos sin procesar y de los registros del proveedor, incluidos los subdominios y las direcciones de rebote que pueden publicar políticas separadas.

Relacione la sintaxis SPF con DMARC sin confundirlos

SPF normalmente evalúa el dominio MAIL FROM o la identidad HELO según las reglas del protocolo. DMARC usa el dominio From visible de RFC 5322 y acepta SPF como vía solo cuando el dominio autenticado por SPF está alineado con ese dominio visible. Por lo tanto, el return path de un proveedor puede aprobar SPF y seguir sin estar alineado para DMARC. A la inversa, un DKIM alineado y aprobado puede satisfacer DMARC cuando SPF falla o no está alineado. Registre por separado el resultado de SPF, el dominio evaluado, la IP de conexión, el From visible, los resultados de DKIM, la alineación y el resultado DMARC. El reenvío suele cambiar la IP de conexión y puede romper SPF aunque el remitente original estuviera autorizado. No amplíe SPF para incluir reenviadores arbitrarios. Use DKIM y, cuando proceda, mecanismos de cadena autenticada y la evidencia del receptor. Un pass de SPF no demuestra la integridad del mensaje, la seguridad del contenido, el consentimiento del destinatario, la aceptación por el servidor ni la llegada a la bandeja de entrada.

Valide los cambios con un flujo de trabajo determinista

Antes de editar el DNS, exporte el registro actual y enumere cada mecanismo o modificador con su responsable y su finalidad. Analice el candidato con la gramática de RFC 7208, expanda las dependencias DNS a partir de instantáneas controladas, cuente los términos que generan consultas y pruebe casos IPv4 e IPv6 autorizados y no autorizados. Compruebe el comportamiento de los includes anidados ante pass, fail, neutral, softfail, error temporal y error permanente. Pruebe la gestión de la ruta inversa nula mediante HELO, los subdominios, los return paths de los proveedores y una fuente que debería llegar hasta all. Publique mediante los controles de cambios habituales, consulte el DNS autoritativo y recursivo, y luego envíe mensajes controlados por cada flujo real. Conserve los Authentication-Results sin procesar de receptores de confianza y compárelos con las identidades esperadas. Revierta ante fuentes de producción ausentes, selección de varios registros, errores por límite de consultas, temperror generalizados o autorizaciones no previstas. Nunca haga pruebas enviando correo no solicitado.

Configure SPF con SendHQ

SendHQ aprovisiona una política SPF TXT como parte de la configuración de identidad del remitente. Detiene la configuración ante políticas SPF en conflicto e informa un valor SPF combinado recomendado en lugar de sobrescribir silenciosamente una política no relacionada. Mantenga exactamente una política SPF seleccionable; consulte la documentación de Dominios y DNS para conocer detalles de configuración y reparación.

Preguntas frecuentes

Fuentes

• RFC 7208: marco de políticas del remitente (SPF) — RFC Editor
• RFC 7489: autenticación, informes y conformidad de mensajes basados en dominios (DMARC) — RFC Editor
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor