SPF com excesso de consultas DNS: como resolver o limite de 10 e o permerror

O que significa “consultas DNS demais”

Quando um servidor de destino verifica o SPF, ele lê o registro TXT que começa com v=spf1 no domínio do remetente do envelope (o endereço MAIL FROM, que depois aparece como Return-Path) e avalia os termos da esquerda para a direita. Alguns termos obrigam o destinatário a fazer uma nova consulta DNS. A seção 4.6.4 da RFC 7208 limita esses termos a 10 por verificação, incluindo os que estão dentro de cada registro incluído. Se a avaliação precisar de um 11º, o destinatário deve parar e retornar permerror, o resultado para registros publicados que não puderam ser interpretados corretamente.

Normalmente o problema aparece em um destes três lugares: no cabeçalho Authentication-Results de uma mensagem entregue (RFC 8601), por exemplo spf=permerror smtp.mailfrom=example.com; numa mensagem de devolução (bounce) que fala em consultas demais; ou nos erros de SPF dos relatórios agregados do DMARC.

Dois detalhes deixam o erro confuso. Os destinatários contam as consultas durante a avaliação, e a avaliação para no primeiro termo que corresponder. O e-mail de um serviço que aparece cedo no registro pode continuar passando, enquanto o de um serviço cujo include vem depois da décima consulta recebe permerror; por isso o problema pode parecer intermitente. Além disso, permerror não é fail: o SPF simplesmente deixa de ajudar. O DMARC passa quando o SPF ou o DKIM passa para um domínio alinhado com o endereço From (RFC 9989); assim, uma mensagem com assinatura DKIM alinhada continua passando, e uma que dependia só do SPF, não. Fora isso, como cada destinatário trata um permerror é decisão dele.

Quais termos do SPF contam para o limite e quais não contam

O orçamento vale para a avaliação inteira, não para um único registro. Um include custa uma consulta por si só e, além disso, o que custar o registro para onde ele aponta, até o último nível de aninhamento. Os provedores mudam os próprios registros, por exemplo ao distribuir suas faixas de endereços em mais include aninhados, então o seu total pode mudar sem que você mexa em nada.

O limite existe porque um registro SPF faz os destinatários dispararem consultas DNS em nome de quem o publica; a seção 11.1 da RFC 7208 descreve como um atacante poderia usar isso para sobrecarregar o DNS de terceiros. A RFC também sugere um tempo máximo para a verificação inteira, de pelo menos 20 segundos. Estourar esse tempo resulta em temperror, um erro temporário, e não em permerror.

O segundo limite: no máximo duas consultas vazias

A RFC 7208 acrescenta um limite separado para as consultas que voltam vazias: uma resposta sem registros (NOERROR com zero respostas) ou um erro de nome (NXDOMAIN, o nome não existe). Elas se chamam consultas vazias (void lookups). As implementações DEVERIAM aceitar no máximo duas, e passar disso também gera permerror, mesmo que o total ainda esteja abaixo de 10. Isso impede que um registro SPF mande os destinatários atrás de longas listas de nomes que não existem.

As consultas vazias costumam vir de sobras de configurações antigas:

• a:old-web.example.com depois que o nome DNS do servidor antigo foi apagado.
• mx ou mx:example.org num nome sem registros MX. O mecanismo não pode recorrer ao registro A do nome, então simplesmente não encontra nada.
• a no domínio raiz depois que o site mudou para uma hospedagem que só responde em www.

Com include: a regra é mais rígida. Se o nome incluído não existir ou não publicar registro SPF, o include não conta só como consulta vazia: ele transforma o resultado inteiro em permerror na hora (seção 5.2). É o que acontece quando um provedor que você deixou de usar desativa o domínio que o seu registro ainda inclui. Consulte cada nome para onde o seu registro aponta; um nome que não retorna nada deve ser corrigido ou removido.

Como contar à mão as consultas do seu SPF

Comece pelo domínio do remetente do envelope, que aparece no cabeçalho Return-Path de uma mensagem enviada por você, e percorra o registro de forma recursiva:

1. Leia o registro: dig +short TXT example.com, ou nslookup -type=TXT example.com no Windows.
2. Conte 1 para cada include, a, mx, ptr, exists e redirect, e 0 para ip4, ip6 e all.
3. Para cada include e redirect, leia o registro de destino e conte da mesma forma, até o nível mais profundo.
4. Some tudo e anote qualquer nome que não tenha retornado registros.

Veja um registro hipotético com apenas cinco termos de consulta à vista:

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

O total é o pior caso. Um remetente reconhecido pelo primeiro include precisa de no máximo cinco consultas e passa. Um remetente que não corresponde a nada antes chega ao a final, a 11ª consulta; por isso o e-mail falsificado recebe permerror em vez do fail que o -all deveria produzir. Refaça a contagem sempre que acrescentar um serviço de envio e, de qualquer forma, de tempos em tempos, porque os registros incluídos mudam sem aviso.

Como voltar a ficar abaixo de dez sem perder e-mails

• Remova os include que você não usa mais. Um provedor de e-mail anterior, uma ferramenta de newsletter cancelada, um CRM avaliado por algumas semanas. Os relatórios agregados do DMARC mostram quais fontes realmente enviam em nome do seu domínio, o que ajuda a achar include que ninguém usa. Fale com o responsável por cada serviço antes de removê-lo.
• Confira se um include chega a ser avaliado. O SPF é verificado no domínio do remetente do envelope. Se as mensagens de um serviço mostram o domínio do próprio serviço em Return-Path, os destinatários consultam o registro SPF desse domínio, não o seu, e o seu include não faz nada por esse e-mail. Confirme na documentação do provedor antes de tirá-lo.
• Troque a e mx por ip4 e ip6 nos servidores que você controla. Se o seu próprio servidor envia a partir de 192.0.2.10, ip4:192.0.2.10 não custa nada, enquanto a custa uma consulta. Pergunte-se se o mx precisa estar ali: os servidores que recebem o seu e-mail não necessariamente enviam, e, se forem do seu provedor de e-mail, o include dele talvez já cubra os servidores de envio. Atualize o endereço quando o servidor mudar.
• Dê a cada remetente de alto volume um subdomínio próprio. Faça um serviço de newsletter ou de atendimento usar como remetente do envelope um domínio de devolução como news.example.com, com registro SPF próprio e limite próprio de 10. O SPF não é herdado, então o subdomínio precisa desse registro. Com o alinhamento relaxado que o DMARC usa por padrão, news.example.com continua alinhado com um endereço From em example.com. Muitos serviços chamam isso de return-path personalizado ou domínio de bounce.
• Elimine o ptr. A RFC 7208 diz que ele NÃO DEVERIA ser publicado: é lento, depende do DNS reverso controlado pelo dono do IP que se conecta e gasta consultas. Troque-o por ip4/ip6 ou pelo include do provedor.
• Reordenar não resolve. Colocar o remetente de maior volume no começo faz menos mensagens chegarem à 11ª consulta, mas o registro continua quebrado para tudo o que vem depois, inclusive o e-mail falsificado que deveria cair no -all.

O DKIM também alivia a pressão. O DMARC só precisa de um resultado alinhado que passe, e o DKIM costuma sobreviver ao encaminhamento, enquanto o SPF não. Verifique se todos os serviços assinam com o seu domínio e só depois enxugue o registro SPF.

Flattening do SPF: menos consultas, mais manutenção

O flattening (achatamento) troca um include pelas faixas ip4 e ip6 que ele resolve hoje. O número de consultas cai, mas o seu registro passa a guardar uma cópia da lista de outra empresa, e essa cópia não se atualiza sozinha.

Serviços de flattening automático resolvem os include periodicamente e reescrevem o seu registro. Isso evita faixas desatualizadas, mas dá a um terceiro um papel no seu DNS, e uma atualização que falhar quebra o seu SPF. Tente primeiro as outras soluções. Se mesmo assim optar pelo flattening, anote qual include você substituiu e quando, compare regularmente com as faixas publicadas pelo provedor e teste o SPF depois de cada mudança (o Microsoft Learn dá o mesmo conselho aos clientes dele).

Um único registro SPF por nome, dividido do jeito certo

Um nome deve ter exatamente um registro TXT que comece com v=spf1. Com dois, o destinatário não consegue escolher e retorna permerror (seção 4.5 da RFC 7208). Isso costuma acontecer quando o guia de configuração de um serviço novo diz “adicione este registro TXT” e alguém cria um segundo registro SPF em vez de editar o primeiro. Um segundo registro, portanto, não dobra o orçamento; junte os dois:

# Errado: dois registros SPF no mesmo nome
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Certo: um único registro
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Outros registros TXT no mesmo nome, como tokens de verificação de serviços, não atrapalham; só contam os que começam com v=spf1. Uma string dentro de um registro TXT comporta no máximo 255 caracteres. Um registro SPF maior continua sendo um único registro TXT formado por várias strings entre aspas, que os destinatários juntam sem acrescentar espaços (seção 3.3); por isso, termine a string com um espaço onde um termo acaba:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

Outros erros produzem o mesmo permerror: um erro de sintaxe em qualquer ponto do registro, como include= no lugar de include: (seção 4.6), ou um include de um domínio sem registro SPF. Os registros SPF também não são herdados: cada nome usado como remetente do envelope precisa do próprio registro, e cada um tem o seu limite de 10.

O que o verificador gratuito de SPF e DMARC conta

O snapshot gratuito de prontidão para lançamento roda oito verificações passivas em um domínio público, sem cadastro; uma delas lê os registros DNS de e-mail. Ele não é um pentest nem a auditoria das seis áreas, e não envia e-mails.

• Nome exato. Ele lê o registro SPF do nome que você digitar, sem recorrer ao domínio pai. Digite o próprio domínio do remetente do envelope, por exemplo example.com em vez de www.example.com.
• Contagem no primeiro nível. Ele conta os termos com consulta DNS desse registro (include, a, mx, ptr, exists e redirect) e sinaliza mais de dez como risco médio.
• O que ele não segue. Ele não segue include: nem redirect=, não conta consultas vazias e não sinaliza um segundo registro SPF no mesmo nome. O exemplo de cinco termos acima passa nessa contagem, embora os destinatários precisem de onze consultas; por isso, faça também a contagem recursiva por conta própria.
• Outros sinais de SPF. +all é sinalizado como risco alto e ?all como baixo; a falta de registro SPF ou DMARC é sinalizada quando o host tem registros MX.

Para abrir primeiro a verificação do DNS de e-mail, use o verificador de SPF e DMARC gratuito: ele executa o mesmo snapshot e mostra essa verificação acima das outras sete. Para o restante do registro, da escolha entre ~all e -all até levar o DMARC de none para reject, veja o guia de SPF e DMARC.