Aprendi da maneira difícil o que SPF realmente significa. Uma sexta-feira à tarde, troquei nosso domínio de produção de modo softfail para hardfail, esquecendo completamente de uma plataforma de eventos que configuramos meses atrás. Os e-mails simplesmente desapareceram. Aquela sexta-feira me ensinou algo crucial: você realmente sabe de onde seu e-mail se origina, e está preparado para as consequências da entrega se errar?

Desde então, trato mudanças de SPF como os pilotos tratam suas listas de verificação—de forma metódica, com salvaguardas e nunca apressado.

Deixe-me explicar o que realmente acontece por baixo do capô. SPF (framework de política de remetente) é um sistema de autenticação de e-mails baseado em DNS. Você publica um registro SPF como um registro TXT de DNS no seu domínio que informa aos servidores receptores quais hosts estão autorizados a enviar e-mails em seu nome. Esses servidores verificam seus mecanismos (ip4, ip6, a, mx, include) e qualificadores, e então produzem um resultado: passar, nenhum, neutro, softfail, hardfail, temperror ou permerror.

A diferença principal está naquele qualificador final. Um softfail (~all) indica "isto parece não autorizado, mas prossiga com cautela." Um hardfail (-all) indica "apenas os hosts listados são legítimos—bloqueie tudo o mais." Esse único caractere muda como os provedores de caixa postal tratam suas mensagens.

Aqui é onde fica prático. Com softfail, você geralmente vê a mensagem sendo colocada na pasta de spam ou em quarentena. Com hardfail, especialmente quando a alinhamento DMARC está em vigor, você pode receber uma rejeição direta no servidor de e-mail. Microsoft 365 e Outlook tendem a combinar SPF com DKIM e filtros de conteúdo. Google e Yahoo dependem fortemente de DMARC e reputação do remetente. Então, um softfail pode acabar em Promoções; um hardfail com alinhamento DMARC pode significar bloqueio decisivo.

Nunca parto direto para o hardfail. Meu caminho sempre é: neutro (?all) → softfail (~all) → hardfail (-all). Durante a descoberta, quando estou incerto sobre fluxos de e-mail legados ou faixas de IP de fornecedores, uso softfail. Ele sinaliza uso indevido do domínio sem prejudicar a entregabilidade enquanto faço inventário de todas as fontes de envio—CRM, automação de marketing, tickets, RH, finanças, até impressoras.

Depois de validar todos os remetentes autorizados e garantir que o DKIM esteja consistente em todos os lugares, então passo para o hardfail. A troca de risco é real: softfail oferece melhor entregabilidade durante o inventário, mas maior risco de phishing passar como spam ao invés de ser bloqueado. Hardfail oferece segurança mais forte, mas pode interromper e-mails legítimos se você esquecer de algum remetente.

Já vi equipes ultrapassarem o limite de 10 consultas DNS por causa de includes aninhados demais. Já vi esquecerem fornecedores sazonais como Livestorm ou webhooks do Prismic. E já observei pessoas assumindo que DMARC vai salvar um registro SPF quebrado—não vai, pelo menos não sem alinhamento.

A lição real: trate SPF, DKIM e DMARC como um sistema, não como peças isoladas. Encaminhamento quebra SPF porque o IP de conexão muda. Se você usa SRS (Sender Rewriting Scheme), está tranquilo. Se não, softfail pode ser tudo o que impede um ataque amigo. Por isso, monitoro obsessivamente os relatórios agregados do DMARC e leio os cabeçalhos de Authentication-Results quando algo falha.

Minha implementação segura: mapeie primeiro todos os servidores de e-mail e fluxos de trabalho, valide o DKIM em todos os lugares, habilite DMARC com p=none para telemetria, coloque SPF em softfail e monitore por duas ciclos de envio, investigue todos os remetentes não autorizados, e antes de mudar para hardfail, faça um teste de rejeição em modo dry-run.

Nos últimos anos, Google e Yahoo reforçaram os requisitos de autenticação. A aplicação de políticas está cada vez mais multi-sinal: modo SPF, assinaturas DKIM, política DMARC, conteúdo e reputação tudo importam. Por isso, nunca trato SPF isoladamente. Um hardfail de SPF sem DKIM sólido ainda pode prejudicar a entregabilidade se o encaminhamento for comum.

O maior erro que ainda vejo: equipes mudando para hardfail antes de DKIM estar amplamente implementado, ou confiando no softfail para sempre enquanto atacantes se adaptam e o spoofing de e-mails prospera nessa ambiguidade. É um equilíbrio, mas o caminho fica claro se você for metódico sobre isso.