Aprendi sobre SPF da pior forma—alterei um domínio de produção de softfail para hardfail numa sexta-feira à tarde e vi toda uma cadeia de emails desaparecer. Acontece que tinha esquecido de uma plataforma de eventos que tinha configurado meses antes. Esse erro me ensinou algo crucial: antes de mexer no seu registro SPF, é preciso saber exatamente de todos os locais de onde seus emails se originam, e aceitar as consequências se fizer algo errado.

Deixe-me explicar o que realmente importa aqui. SPF (Sender Policy Framework) é basicamente o seu domínio dizendo aos servidores receptores: aqui está o meu registro DNS TXT que lista quais hosts podem enviar emails legítimos em meu nome. Quando chega um email, o receptor verifica o seu registro SPF contra o domínio do Return-Path, avalia seus mecanismos (ip4, ip6, a, mx, include), e decide o que fazer. Essa decisão depende de uma coisa: do seu qualifier no final—o modo que você escolhe.

Aqui está a diferença principal que confunde as pessoas. Um softfail (~all) diz "isto parece não autorizado, mas talvez esteja tudo bem—prossiga com cautela." Geralmente, isso aciona filtros de spam, não rejeição total. Um hardfail (-all) diz "apenas os hosts que listei são legítimos—bloqueie tudo o mais." É definitivo, e quando combinado com alinhamento DMARC, resulta na rejeição real da mensagem.

Penso nisso como staging versus produção. Softfail é o modo de staging cauteloso enquanto você ainda está descobrindo as coisas. Hardfail é virar o disjuntor em produção e assumir as consequências.

O caminho prático que sigo é metódico: começo com ?all para observação pura, passo para softfail (~all) assim que começo a monitorar os relatórios agregados do DMARC, e só mudo para hardfail (-all) depois de validar todos os remetentes autorizados e garantir que seus falsos positivos estejam quase zero. Nunca faço isso na pressa. Inventário tudo—CRM, automação de marketing, ticketing, RH, faturamento, até coisas estranhas como impressoras. Confirmo quais fornecedores suportam DKIM e alinhamento DMARC. Documentei quem é responsável por cada mudança.

Uma coisa que vai te pegar rápido: SPF tem um limite rígido de 10 consultas DNS. Já vi gente aninhar includes tão profundamente que atingem esse limite de repente, e tudo quebra. Simplifique seus includes, prefira intervalos de IPs ao invés de cadeias aninhadas, e elimine serviços mortos. Se um remetente em massa rotaciona IPs constantemente, exija um include estável com SLAs.

Reencaminhamento é outro problema. Quebra o SPF porque o IP de conexão muda. Se o reencaminhador usa SRS (Sender Rewriting Scheme), tudo bem. Se não, um softfail pode ser a única coisa impedindo um erro amigo. É por isso que confio mais em DKIM e no alinhamento DMARC para esses caminhos.

A lista de verificação de implementação no mundo real que refinei ao longo do tempo: mapeie todos os servidores de email e fluxos de trabalho, valide DKIM em todos os lugares, ative DMARC com p=none para telemetria, coloque o SPF em softfail ~all e monitore por pelo menos duas ciclos de envio, investigue cada remetente não autorizado e autorize-o ou elimine o fluxo, depois implemente uma política de rejeição com aplicação do DMARC antes de mudar para hardfail. Essa última etapa—mudar para hardfail somente quando a cobertura de remetentes legítimos estiver completa—é inegociável.

Mais uma coisa que notei: Google e Yahoo reforçaram bastante seus padrões. A aplicação de políticas de email agora combina modo SPF, assinaturas DKIM, política DMARC, análise de conteúdo e pontuação de reputação. Por isso, nunca trato SPF isoladamente. Um hardfail de SPF sem suporte sólido de DKIM ainda pode prejudicar a entregabilidade se o reencaminhamento for comum no seu ambiente.

Os maiores erros que vejo as pessoas cometerem: aninhar includes até ultrapassar o limite de 10 consultas DNS, esquecer fornecedores sazonais que enviam como seu domínio, achar que DMARC vai salvar uma configuração de SPF quebrada, confiar em softfail para sempre enquanto atacantes se adaptam, ou mudar para hardfail antes que DKIM esteja em todos os envios. Essa última—especialmente—é ótima para segurança, mas péssima para entregabilidade quando há muito reencaminhamento.

Se você está usando softfail agora e se perguntando se deve mudar, a resposta é: só quando estiver pronto. Você validou todos os remetentes? DKIM está alinhado? Seus falsos positivos estão quase zero? Se a resposta for sim para tudo, faz sentido passar para hardfail. Caso contrário, seja paciente. Softfail não é um estado permanente—é um ponto de verificação.