O SPF flattening afeta DKIM e DMARC?

Resposta curta: o SPF flattening não altera o DKIM de forma alguma, e só afeta o DMARC indiretamente. O flattening reescreve a maneira como seu registro v=spf1 é avaliado — ele troca cadeias de include: aninhadas por entradas explícitas ip4:/ip6: — mas nunca modifica suas chaves DKIM, suas assinaturas DKIM ou os domínios contra os quais o DMARC se alinha. Bem feito, o flattening na verdade fortalece o DMARC ao manter o SPF abaixo do teto de 10 consultas, para que ele passe de forma confiável. Mal feito (IPs desatualizados, registros grandes demais), ele pode fazer o SPF falhar e empurrar o DMARC a depender inteiramente do DKIM.

Se você entender essa única distinção, todo o resto decorre dela. Esta página percorre exatamente como os três protocolos interagem, para que você possa achatar com confiança em vez de medo.

Como SPF, DKIM e DMARC realmente se relacionam

Os três protocolos fazem trabalhos diferentes, e apenas um deles é afetado pelo SPF flattening:

• SPF verifica se o IP de conexão está autorizado a enviar em nome do domínio no envelope SMTP (o MailFrom / Return-Path). A avaliação percorre mecanismos DNS — include:, a, mx, ptr, exists, redirect — e, de acordo com a RFC 7208, é limitada a 10 consultas DNS. Cruze esse limite e você obtém um PermError, que conta como uma falha de SPF para cada mensagem do domínio.
• DKIM anexa uma assinatura criptográfica a cada mensagem usando uma chave privada, verificada contra uma chave pública publicada no DNS. Ele é completamente independente do SPF e do IP de conexão.
• DMARC amarra os dois. Ele passa quando ou o SPF ou o DKIM passa e se alinha com o domínio visível do From: (relaxado ou estrito). Se ambos falham, o DMARC aplica sua política — p=none, p=quarantine ou p=reject.

O flattening vive inteiramente dentro da caixa do SPF. Ele muda a estrutura do registro SPF, não os domínios envolvidos. É por isso que ele não pode, por definição, alterar a assinatura DKIM ou o alinhamento DKIM.

O SPF flattening afeta o DKIM?

Não — não diretamente, e não de nenhuma forma que importe para a assinatura. O DKIM depende de uma chave privada na sua plataforma de envio e de uma chave pública em selector._domainkey.yourdomain.com. O flattening nunca toca em nenhuma delas. Seus seletores, comprimentos de chave e canonicalização (c=relaxed/relaxed vs simple/simple) permanecem intocados por qualquer coisa que um flattener faça ao seu registro TXT v=spf1.

Existe exatamente uma relação indireta que vale a pena nomear: o DKIM se torna mais importante no momento em que o flattening dá errado. Se um registro achatado fica desatualizado e o SPF começa a falhar, o DMARC tem apenas um caminho restante para passar — o DKIM. Portanto, uma configuração de DKIM saudável e alinhada é sua rede de segurança durante qualquer soluço do SPF. Isso é uma razão para manter o DKIM forte, não uma razão para evitar o flattening.

O SPF flattening afeta o DMARC?

Sim, mas geralmente para melhor. O caminho de SPF do DMARC passa quando o SPF avalia de forma limpa e o domínio do MailFrom se alinha com o domínio do From:. O flattening melhora a primeira metade dessa equação:

• Menos consultas, menos erros. Colapsar cadeias de include: em literais de IP normalmente reduz a avaliação de 10+ consultas para 1–3. Isso elimina o PermError (consultas demais) e reduz o TempError (timeouts de DNS) que, de outra forma, seriam registrados como falhas de SPF — e o DMARC trata um PermError de SPF como falha.
• O alinhamento permanece inalterado. O flattening não toca nos domínios do MailFrom ou do From:, então ele não ajuda nem prejudica o alinhamento em si. Ele simplesmente aumenta as chances de que o SPF possa ser avaliado com sucesso em primeiro lugar.

Na prática, equipes que achatam bem veem sua taxa de “aprovação alinhada por SPF” do DMARC subir substancialmente, porque o caminho do SPF para de dar erro. O ganho é real, mas vem da confiabilidade, não de mudar o que o DMARC verifica.

A única maneira pela qual o flattening pode prejudicar o DMARC

O flattening congela IPs de terceiros na sua zona. Quando um provedor rotaciona seu pool de envio, um registro achatado desatualizado deixará de fora os novos IPs, e o e-mail legítimo falhará no SPF. Quando isso acontece, o DMARC recorre ao DKIM. Se o DKIM está presente e alinhado, o e-mail ainda passa. Se o DKIM está ausente ou desalinhado — comum para envios transacionais ou disparados — o DMARC falha e, sob p=quarantine ou p=reject, esse e-mail é retido ou devolvido.

Portanto, o risco não é o flattening em si. O risco é o flattening não mantido. Este é o ponto operacional isolado mais importante desta página.

Por que a manutenção é o jogo inteiro

As faixas de IP dos fornecedores mudam constantemente — grandes ESPs e CDNs rotacionam faixas a cada poucas semanas, às vezes mais rápido durante eventos de pico. Um registro que você achata à mão hoje é preciso hoje e derivando amanhã. Dois modos de falha decorrem disso:

Sintoma de registro desatualizado	O que quebra	Efeito no DMARC
Faltam novos IPs do provedor	E-mail legítimo falha no SPF	O DMARC depende do DKIM; falha se o DKIM estiver ausente/desalinhado
Manter IPs aposentados	IPs reatribuídos podem passar no SPF para seu domínio	Janela de spoofing — um novo tenant poderia enviar e-mail “autorizado”

Ambos são evitáveis, mas somente com automação que re-resolve o registro em uma cadência apertada. É exatamente aqui que o AutoSPF foi construído para ajudar: ele reexamina a cada 15 minutos e atualiza automaticamente o registro no momento em que os IPs upstream mudam e resolve exatamente para os mesmos IPs para os quais seus includes resolvem — sem autorização excessiva, sem supernets amplas deixadas abertas para abuso. Essa combinação fecha tanto a lacuna de entregabilidade de IPs desatualizados quanto a janela de spoofing que o flattening manual deixa aberta.

Mantendo o registro seguro: tamanho, consultas e a regra do registro único

Além da desatualização, três restrições técnicas impedem que o SPF achatado quebre o DMARC:

• Apenas um registro. Um domínio pode publicar exatamente um registro TXT começando com v=spf1. Dois deles produzem um PermError. Se você precisar dividir por tamanho, divida em várias strings dentro do mesmo registro TXT — nunca em registros separados.
• Fique de olho no orçamento de bytes. Cada segmento de string TXT é limitado a 255 caracteres (as implementações os concatenam). Mantenha o total confortavelmente abaixo de ~450–600 bytes; registros grandes demais correm risco de truncamento e fragmentação entre resolvers.
• Fique abaixo de 10 consultas. O flattening parcial que deixa include:, a, mx ou exists aninhados no lugar ainda pode estourar o teto. Prefira literais ip4:/ip6:, remova o ptr obsoleto e comprima faixas contíguas em CIDRs.

Mantenha seu qualificador de fechamento deliberado — termine com -all (hard fail) ou ~all (soft fail) conforme sua política. Aprenda a mecânica completa em como achatar um registro SPF e, se estiver ponderando isso contra abordagens baseadas em macros, veja SPF flattening vs macros.

O que o flattening não pode corrigir

O flattening resolve erros de consulta e de timeout. Ele não resolve:

• Encaminhamento. Quando uma mensagem é encaminhada, o IP de conexão muda, então o SPF do seu domínio falha independentemente de quão limpo seja seu registro. As correções são SRS no encaminhador ou — de forma mais confiável — DKIM alinhado, que sobrevive ao encaminhamento. É precisamente por isso que o DKIM deve sempre ser de primeira classe.
• Desalinhamento de fornecedor. Se um ESP envia com um domínio de bounce que não é um subdomínio do seu domínio From:, o alinhamento estrito de SPF falha aconteça o que acontecer. Isso é um problema de configuração de MailFrom, não de flattening.

Para esses casos, a resposta é DKIM + DMARC (e SRS/ARC em intermediários), nunca flattening mais agressivo.

A postura recomendada

A configuração mais segura é híbrida: achate os provedores estáveis e de alto número de consultas para permanecer abaixo do teto; mantenha os remetentes genuinamente dinâmicos em includes gerenciados pelo fornecedor; imponha DKIM alinhado em todos os fluxos; e monitore os relatórios agregados de DMARC para poder ver se é o SPF ou o DKIM que está de fato carregando suas aprovações.

Antes de mudar qualquer coisa, confirme onde você está hoje. Rode seu registro atual no SPF Checker para ver sua contagem de consultas ao vivo e identificar os includes que estão empurrando você para o limite — depois decida o que achatar. Automatizar a atualização com o AutoSPF transforma o único risco real do flattening — a deriva — em um problema resolvido, para que seu SPF achatado fortaleça o DMARC em vez de miná-lo silenciosamente.

Perguntas Frequentes

O SPF flattening muda minha configuração de DKIM?

Não. O flattening só reescreve como seu registro SPF é avaliado, trocando cadeias de include: por literais ip4:/ip6:. Ele nunca toca na sua chave privada DKIM, na chave pública, nos seletores ou nas assinaturas. A única conexão é que uma configuração de DKIM forte e alinhada atua como a rede de segurança do DMARC caso um registro SPF achatado alguma vez fique desatualizado e o SPF falhe.

O SPF flattening vai quebrar o DMARC?

Não, se for mantido. Como o DMARC passa quando o SPF ou o DKIM se alinha, o flattening bem mantido na verdade melhora o DMARC ao manter o SPF abaixo do limite de 10 consultas, para que ele passe de forma confiável. O DMARC só sofre se um registro achatado ficar desatualizado, o SPF começar a falhar e o DKIM não estiver lá para cobrir a mensagem.

O SPF flattening é seguro?

Sim, quando é automatizado. O único risco real é a deriva — os provedores rotacionam IPs e um registro achatado estático fica desatualizado, causando falhas de SPF ou deixando IPs aposentados autorizados. Uma ferramenta que reexamina com frequência e re-resolve exatamente para os IPs upstream (o AutoSPF verifica a cada 15 minutos) remove esse risco. O flattening manual, do tipo configure-e-esqueça, é onde mora o perigo.

Ainda preciso de DKIM se meu SPF está perfeitamente achatado?

Com certeza. O DKIM é o caminho de aprovação de DMARC mais confiável porque sobrevive ao encaminhamento e às listas de e-mail, onde o SPF falha por definição. Mesmo um registro achatado impecável pode atingir um problema transitório de DNS, e o DKIM é o que mantém o DMARC passando naquele momento. Nunca trate o flattening como um substituto para o DKIM.

O SPF flattening pode causar spoofing de e-mail?

Somente por negligência. Se um registro achatado mantém IPs que um provedor aposentou, e esses IPs são reatribuídos a um novo tenant, esse tenant poderia passar no SPF para seu domínio. Achatar exatamente para os mesmos IPs para os quais seus includes resolvem — e podar faixas aposentadas automaticamente — evita essa autorização excessiva por completo.

Com que frequência um registro SPF achatado deve ser atualizado?

Com a mesma frequência com que seus provedores mudam os IPs, o que para remetentes dinâmicos de nuvem pode ser a cada poucos dias. Atualizações manuais não conseguem acompanhar o ritmo, e é por isso que a automação importa: o AutoSPF reexamina a cada 15 minutos e republica no momento em que os IPs upstream mudam, para que o registro nunca derive o suficiente para quebrar o SPF ou deixar uma janela de spoofing aberta.