O Que É o Mecanismo ptr do SPF — e Por Que Ainda Está em 950.631 Registos? (2026)

Q: O que devo usar em vez do ptr?

Blocos ip4:/ip6: para os servidores que controla, ou o include: documentado do seu fornecedor. Ambos são determinísticos, rápidos e fiáveis — tudo aquilo que o ptr não é.

Q: O ptr conta para o limite de 10 consultas do SPF?

Sim — cada ptr custa pelo menos uma das dez consultas de DNS que um recetor fará antes de desistir com um PermError. Em registos já sobrecarregados de mecanismos include:, o mecanismo morto pode ser aquele que o faz ultrapassar o limite.

Publicado 2026-07-03

Valores de 2026-06-29 · metodologia v7. Censo agregado de 261 milhões de domínios avaliados. Todos os valores são agregados — nunca o registo de uma empresa individual. Ver como avaliamos.

O ptr é um mecanismo do SPF que autoriza remetentes através de uma consulta de DNS reverso — e o próprio padrão SPF diz “não o use” desde 2014. 12 anos depois, 950.631 domínios continuam a publicá-lo. Isso equivale a cerca de 1 em cada 146 dos 139 milhões de registos SPF na internet que carregam um mecanismo que a especificação descontinuou antes mesmo de alguns desses domínios terem sido registados.

O que o ptr era suposto fazer

O ptr diz: “aceita correio de qualquer servidor cujo DNS reverso resolva de volta para o meu domínio.” Parece elegante — não há listas de IP para manter. Na prática, exige que o recetor faça uma consulta reversa ao IP que se liga e, depois, confirme por consulta direta cada nome de anfitrião devolvido. O RFC 7208 (§5.5) descontinuou-o com todas as letras: o mecanismo é “lento, não é tão fiável como outros mecanismos em casos de erros de DNS, e impõe uma grande exigência de recursos aos servidores de nomes .arpa” — e determina que “NÃO DEVE ser usado.”

Por que ainda é uma armadilha em 2026

Três razões pelas quais um mecanismo descontinuado há 12 anos ainda importa:

Consome o seu orçamento de consultas. Cada ptr conta para o limite rígido do SPF de 10 consultas de DNS por verificação — o limite que, uma vez ultrapassado, invalida todo o registo com um PermError. Um mecanismo que nada faz de fiável continua a custar-lhe o orçamento de que os seus verdadeiros mecanismos include: precisam.
Falha de forma imprevisível. O DNS reverso é o canto menos mantido da maioria das redes. Quando a consulta ptr expira ou a confirmação direta falha, o seu correio legítimo perde a aprovação SPF com que contava.
Alguns recetores ignoram-no por completo. Como o padrão o descontinua, algumas implementações simplesmente ignoram o ptr — por isso, os remetentes que ele deveria autorizar nunca chegaram a estar protegidos.

De onde vem

Quase ninguém escolhe o ptr hoje em dia. Ele chega por herança: um guia de configuração escrito em 2009, um modelo copiado de uma configuração antiga de servidor, um registo “que funciona” migrado intacto ao longo de três mudanças de alojamento. É o padrão que o nosso censo vê em todos os mecanismos descontinuados-mas-presentes: os conselhos antigos não morrem, são copiados e colados. Os domínios que carregam o ptr não são descuidados — estão a seguir instruções que foram retiradas há 12 anos.

Como corrigi-lo — grátis, cinco minutos

Encontre o seu registo SPF (dig TXT yourdomain.com ou verifique grátis).
Se contiver ptr, identifique quais os servidores que dependiam dele.
Substitua o ptr pela forma precisa: um bloco ip4:/ip6: para os servidores que controla, ou o include: que o seu fornecedor documenta.
Já que está a mexer, confirme que o registo termina num qualificador real — ver ~all vs -all.

Perguntas frequentes

O que significa ptr num registo SPF? Autoriza qualquer servidor cujo DNS reverso resolva para o seu domínio. O RFC 7208 §5.5 descontinuou-o em 2014 por ser lento e pouco fiável, e diz que NÃO DEVE ser usado — no entanto, 950.631 domínios continuam a publicá-lo em 2026-06-29.

O mecanismo ptr do SPF é alguma vez válido? Ainda é interpretado, e alguns recetores ainda o avaliam — mas o padrão desaconselha-o em todos os casos, alguns recetores ignoram-no, e ele gasta uma das suas dez consultas de DNS. Não existe qualquer configuração moderna em que ptr seja a resposta certa.

O que devo usar em vez do ptr? Blocos ip4:/ip6: para os servidores que controla, ou o include: documentado do seu fornecedor. Ambos são determinísticos, rápidos e fiáveis — tudo aquilo que o ptr não é.

O ptr conta para o limite de 10 consultas do SPF? Sim — cada ptr custa pelo menos uma das dez consultas de DNS que um recetor fará antes de desistir com um PermError. Em registos já sobrecarregados de mecanismos include:, o mecanismo morto pode ser aquele que o faz ultrapassar o limite.

Verifique o seu registo à procura de fantasmas

Um mecanismo descontinuado há 12 anos, ainda instalado no seu DNS, é exatamente o tipo de coisa que ninguém procura. Procurar demora meio minuto.

Verifique o seu domínio → · Corrigir SPF → · Dois registos SPF = nenhum → · O modelo de maturidade do SPF → · Apenas dados agregados. Dados armazenados e processados na UE.