Aprendí sobre SPF de la manera difícil—cambié un dominio en producción de softfail a hardfail un viernes por la tarde y vi desaparecer todo un flujo de correos electrónicos. Resulta que había olvidado algunas plataformas de eventos que había configurado meses antes. Ese error me enseñó algo crucial: antes de modificar tu registro SPF, necesitas saber exactamente de dónde proviene cada envío de correo, y aceptar las consecuencias si te equivocas.

Déjame explicar qué es realmente importante aquí. SPF (Sender Policy Framework) es básicamente tu dominio diciendo a los servidores receptores: aquí está mi registro DNS TXT que lista qué hosts pueden enviar correos legítimamente en mi nombre. Cuando llega un email, el receptor verifica tu registro SPF contra el dominio del Return-Path, evalúa tus mecanismos (ip4, ip6, a, mx, include), y decide qué hacer. Esa decisión depende de una cosa: tu calificativo al final—el modo que eliges.

Aquí está la diferencia clave que confunde a la gente. Un softfail (~all) dice "esto parece no autorizado, pero quizás esté bien—proceda con precaución." Normalmente, esto activa filtros de spam, no un rechazo total. Un hardfail (-all) dice "solo los hosts que listé son legítimos—bloquea todo lo demás." Es definitivo, y cuando se combina con la alineación DMARC, obtienes un rechazo real del mensaje.

Lo pienso como staging versus producción. Softfail es tu modo de staging cauteloso mientras todavía estás averiguando las cosas. Hardfail es cambiar el interruptor en producción y aceptar las consecuencias.

El camino práctico que sigo es metódico: empezar con ?all para pura observación, pasar a softfail (~all) una vez que estás revisando los informes agregados de DMARC, y luego cambiar a hardfail (-all) solo después de haber validado cada remitente autorizado y que tus falsos positivos sean casi cero. Nunca apuro esto. Hago un inventario de todo—CRM, automatización de marketing, ticketing, RRHH, facturación, incluso cosas raras como impresoras. Confirmo qué proveedores soportan DKIM y alineación DMARC. Documenté quién es responsable de cada cambio.

Una cosa que te puede morder rápido: SPF tiene un límite duro de 10 búsquedas DNS. He visto gente anidar includes tan profundo que alcanzan ese límite de repente, y todo se rompe. Simplifica tus includes, prefiere rangos de IP en lugar de cadenas anidadas, y elimina servicios muertos. Si un remitente masivo rota IPs constantemente, presiona para que tengan un include estable con SLAs.

El reenvío (forwarding) es otro problema. Rompe SPF porque la IP que conecta cambia. Si el reenvío usa SRS (Sender Rewriting Scheme), estás bien. Si no, un softfail puede ser lo único que evita un fuego amigo. Por eso, confío más en DKIM y en la alineación DMARC para esos caminos.

La lista de verificación para despliegues en el mundo real que he perfeccionado con el tiempo: mapear cada servidor de correo y flujo de trabajo, validar DKIM en todos lados, habilitar DMARC en p=none para telemetría, mover SPF a softfail y vigilar durante al menos dos ciclos de envío, investigar cada remitente no autorizado y autorizarlo o eliminar el flujo, y luego hacer un despliegue escalonado con una política de rechazo y aplicación de DMARC antes de cambiar a hardfail. Ese último paso—solo pasar a hardfail cuando la cobertura de remitentes legítimos esté completa—es innegociable.

Una cosa más que he notado: Google y Yahoo han endurecido mucho sus estándares. La aplicación de políticas de email ahora combina modo SPF, firmas DKIM, política DMARC, análisis de contenido y puntuación de reputación. Por eso, nunca trato SPF en aislamiento. Un hardfail de SPF sin soporte DKIM sólido aún puede perjudicar la entregabilidad si el reenvío es frecuente en tu entorno.

Los mayores errores que veo: anidar includes hasta superar el límite de 10 búsquedas DNS, olvidar proveedores estacionales que envían como tu dominio, asumir que DMARC salvará una configuración rota de SPF, confiar en softfail para siempre mientras los atacantes se adaptan, o cambiar a hardfail antes de que DKIM esté en todas partes. Especialmente lo último—bueno para seguridad, pero terrible para la entregabilidad cuando el reenvío es frecuente.

Si ahora mismo estás en softfail y te preguntas si debes cambiar, la respuesta es: solo cuando estés listo. ¿Has validado todos los remitentes? ¿Está DKIM alineado? ¿Tus falsos positivos están cerca de cero? Si la respuesta a las tres es sí, tiene sentido pasar a hardfail. Si no, sé paciente. Softfail no es un estado permanente—es un punto de control.