SPF é um registro só — e é assim que se derruba o e-mail da empresa inteira

O SPF diz quais servidores podem mandar e-mail em nome de um domínio. Ele é um registro TXT, e a especificação é clara sobre uma coisa que quase nenhuma tela de configuração menciona: pode existir apenas um por nome. Dois registros que comecem com v=spf1 no mesmo host não se somam. Eles se anulam.

O que acontece na prática

O servidor que recebe a mensagem busca o SPF do domínio, encontra dois, e o resultado da avaliação é PermError — erro permanente. Não é “um dos dois vale”: nenhum vale. A partir daí, todo e-mail que sai daquele domínio passa a falhar a checagem, incluindo os que já funcionavam há anos.

O jeito certo: mesclar, não acrescentar

Se o domínio já tem SPF, o valor novo não é um registro a mais — é uma substituição do que está publicado, com o include: novo somado ao que já existia. Três cuidados na hora de montar o valor mesclado:

1. 1O all que vale é o que já estava lá. ~all e -all são posturas diferentes sobre o que fazer com quem não está na lista, e essa é uma decisão da empresa, não da ferramenta que está entrando.
2. 2Nada é removido sem alguém olhar. O mecanismo que parece sobra pode ser o sistema que emite a nota fiscal.
3. 3O include: novo entra no fim. O SPF é avaliado da esquerda para a direita, e o que já sustenta a operação continua vindo antes.

A armadilha do limite de dez consultas

Cada include: no SPF custa uma consulta de DNS, e a especificação limita o total a dez. Passou de dez, o resultado é PermError de novo — o mesmo sintoma, com outra causa.

Quem já tem Google Workspace, um CRM e um ERP mandando e-mail está em cinco ou seis. Somar mais um serviço às vezes é o que estoura a conta. E como o efeito é o mesmo do registro duplicado — tudo para de autenticar de uma vez — a investigação costuma começar pelo lugar errado.

E o DMARC?

O DMARC também é um registro único por nome, e a regra aqui é ainda mais simples: não sobrescreva. A política de DMARC é uma decisão da empresa sobre o que fazer com mensagens que falham a autenticação, e trocá-la por um p=none genérico para “facilitar a configuração” desliga uma proteção que alguém ligou de propósito.

Se o domínio já tem DMARC válido, o alinhamento pelo DKIM basta. O DKIM, aliás, é o único dos três que convive sem conflito: cada provedor emite o seu com um seletor próprio, e é exatamente por isso que dois serviços de e-mail podem autenticar o mesmo domínio ao mesmo tempo.

Raiz ou subdomínio de envio

Existe uma saída para não encostar no DNS do e-mail corporativo: enviar as campanhas de um subdomínio, como envio.suaempresa.com.br. Ele tem SPF e DMARC próprios, isola a reputação das campanhas do e-mail do dia a dia, e a mescla deixa de ser necessária.

O preço é o nome: o destinatário reconhece suaempresa.com.br e pode estranhar envio.suaempresa.com.br. Não há resposta única — depende de quanto o domínio raiz já carrega. O que não vale é decidir isso sem saber o que já está publicado.