Aprendí por las malas lo que realmente significa SPF. Una tarde de viernes cambié nuestro dominio de producción de modo softfail a hardfail, olvidando por completo una plataforma de eventos que habíamos configurado meses atrás. Los correos simplemente desaparecieron. Ese viernes me enseñó algo crucial: ¿sabes realmente de todos los lugares desde donde se origina tu correo, y estás preparado para las consecuencias si te equivocas?

Desde entonces, trato los cambios en SPF como los pilotos tratan las listas de verificación: de manera metódica, con salvaguardas y sin prisas.

Permíteme desglosar qué está sucediendo realmente bajo el capó. SPF (marco de políticas de remitente) es un sistema de autenticación de correos basado en DNS. Publicas un registro SPF como un registro TXT en DNS en tu dominio que indica a los servidores receptores qué hosts están autorizados a enviar correos en tu nombre. Esos servidores verifican tus mecanismos (ip4, ip6, a, mx, include) y calificadores, y luego producen un resultado: pass, none, neutral, softfail, hardfail, temperror o permerror.

La diferencia clave radica en ese calificativo final. Un softfail (~all) dice "esto parece no autorizado, pero procede con precaución." Un hardfail (-all) dice "solo los hosts listados son legítimos—bloquea todo lo demás." Ese carácter único cambia cómo los proveedores de buzones tratan tus mensajes.

Aquí es donde se vuelve práctico. Con softfail, normalmente ves que los correos van a la carpeta de spam o a cuarentena. Con hardfail, especialmente cuando está en marcha la alineación DMARC, puedes recibir un rechazo directo en el servidor de correo. Microsoft 365 y Outlook tienden a combinar SPF con DKIM y filtros de contenido. Google y Yahoo dependen mucho de DMARC y la reputación del remitente. Así, un softfail puede terminar en Promociones; un hardfail con alineación DMARC puede significar bloqueo definitivo.

Nunca paso directamente a hardfail. Mi camino siempre es: neutral (?all) → softfail (~all) → hardfail (-all). Durante la fase de descubrimiento, cuando no estoy seguro de los flujos de correo heredados o los rangos de IP de los proveedores, uso softfail. Esto señala un uso indebido del dominio sin afectar demasiado la entregabilidad mientras inventario todas las fuentes de envío—CRM, automatización de marketing, tickets, RRHH, finanzas, incluso impresoras.

Una vez que he validado todos los remitentes autorizados y DKIM es consistente en todos lados, entonces paso a hardfail. La compensación de riesgos es real: softfail te da mejor entregabilidad durante el inventario, pero mayor riesgo de que el phishing pase como spam en lugar de ser bloqueado. Hardfail te da mayor seguridad, pero puede romper correos legítimos si te has olvidado de algún remitente.

He visto equipos superar el límite de 10 búsquedas DNS por sobre-anidar includes. Los he visto olvidar proveedores estacionales como Livestorm o webhooks de Prismic. Y he visto a gente asumir que DMARC salvará un registro SPF roto—no lo hará, no sin alineación.

La verdadera lección: trata SPF, DKIM y DMARC como un sistema, no como piezas aisladas. El reenvío rompe SPF porque la IP de conexión cambia. Si usas SRS (Sender Rewriting Scheme), estás bien. Si no, softfail puede ser todo lo que evita un fuego amigo. Por eso monitoreo obsesivamente los informes agregados de DMARC y leo los encabezados Authentication-Results cuando algo falla.

Mi despliegue seguro: mapea primero todos los servidores de correo y flujos de trabajo, valida DKIM en todos lados, habilita DMARC en p=none para telemetría, pasa SPF a softfail y observa dos ciclos de envío, investiga cada remitente no autorizado, y luego realiza una prueba en modo rechazo antes de cambiar a hardfail.

En los últimos años, Google y Yahoo han endurecido los requisitos de autenticación. La aplicación de políticas es cada vez más multifacética: modo SPF, firmas DKIM, política DMARC, contenido y reputación son todos importantes. Por eso nunca trato SPF de forma aislada. Un hardfail en SPF sin DKIM sólido aún puede perjudicar la entregabilidad si el reenvío es frecuente.

El mayor error que todavía veo: equipos que cambian a hardfail antes de que DKIM sea universal, o que dependen del softfail para siempre mientras los atacantes se adaptan y el spoofing de correos prospera en esa ambigüedad. Es un equilibrio, pero el camino está claro si eres metódico al respecto.