# O que é registro SPF? Sintaxe, limites e falhas comuns URL: https://notificationharbor.com/pt/journal/o-que-e-registro-spf-sintaxe-limites-e-falhas Type: blog Locale: pt Published: 2026-10-20 Updated: 2026-10-23 --- > Um registro SPF lista os servidores autorizados a enviar e-mail pelo seu domínio. Veja a sintaxe, o limite de 10 consultas DNS, as falhas no encaminhamento e como verificar o seu. O que é registro SPF? É um único registro DNS do tipo TXT, publicado no domínio, que lista os servidores autorizados a enviar e-mail usando esse domínio no envelope do remetente. O servidor receptor lê esse registro, compara o IP que se conecta com a lista e devolve pass, fail, softfail ou neutral. O SPF autentica o caminho de envio, não a mensagem, e não diz nada sobre o endereço From que uma pessoa lê na tela. Essa diferença explica a maior parte dos chamados de SPF que vemos nos traces. ## Um registro SPF é uma lista de remetentes publicada no DNS SPF significa Sender Policy Framework, especificado na [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208). O registro é uma entrada TXT na raiz do domínio que começa com `v=spf1`. Um exemplo mínimo: `example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"`Leia da esquerda para a direita. O receptor verifica cada termo em ordem e para na primeira correspondência. O termo final `all` pega tudo o que não bateu antes. O domínio verificado não é o cabeçalho From. É o domínio do comando `MAIL FROM` do SMTP, também chamado de envelope sender ou Return-Path. Se ele estiver vazio, como em bounces, o receptor usa o nome do `HELO`. ![Mesa de desenvolvedor com terminal em notebook e um caderno com diagrama de rede desenhado à mão](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/0bf38c-inline1.webp) ## Os mecanismos: ip4, ip6, a, mx, include e exists Cada termo é um mecanismo, opcionalmente precedido por um qualificador. Seis cobrem quase todos os registros reais. - **`ip4:` e `ip6:`** comparam com um endereço literal ou uma faixa CIDR. Não custam consultas. - **`a`** compara com os registros A e AAAA do domínio. Custa uma consulta. - **`mx`** compara com os hosts dos registros MX. Custa uma consulta, mais uma por host. - **`include:`** compara com tudo o que o registro SPF de outro domínio autoriza. Custa uma consulta, mais tudo o que estiver aninhado dentro dele. - **`exists:`** compara com qualquer registro A de um nome montado na hora. Custa uma consulta. - **`ptr`** compara com o reverse DNS do IP conectado. Custa consultas, e a RFC 7208 desaconselha o uso. Os qualificadores definem o resultado quando um termo bate. `+` é pass e é o padrão, `-` é fail, `~` é softfail, `?` é neutral. Assim, `-all` significa "rejeite tudo o que não está listado", e `~all` significa "aceite, mas marque". Prefira `ip4:` e `ip6:` sempre que você controlar o endereço. Eles não custam consultas e não quebram quando o DNS de outra empresa muda. ## O limite de 10 consultas DNS é o que quebra registros reais A RFC 7208 limita uma avaliação SPF a 10 termos que disparam consultas DNS: `include`, `a`, `mx`, `ptr`, `exists` e o modificador `redirect`. Includes aninhados também contam. Acima de 10, o resultado é `permerror`, e a verificação falha de forma permanente em vez de cair num padrão. Há um segundo limite menos citado. Termos que retornam resposta vazia ou NXDOMAIN são consultas vazias (void lookups), e a especificação manda parar em duas. Um `include:` antigo apontando para um fornecedor que você abandonou no ano passado é uma consulta vazia pela qual você continua pagando. Veja como as equipes chegam ao teto na prática. O Google Workspace ocupa um include. Um provedor transacional ocupa outro. Uma plataforma de marketing ocupa um, e ainda aninha três dentro dele. Uma central de suporte, um CRM e uma ferramenta de cobrança somam mais quatro. Você chega a 11 sem ter feito nada fora do comum. A falha é silenciosa. As mensagens continuam saindo, e alguns receptores ainda entregam, mas o SPF já não autentica nada para você. Se o alinhamento DMARC depende do SPF, esse caminho some até você achatar o registro ou remover remetentes. Existem três correções, em ordem de preferência: - Remova os remetentes que você não usa mais. Audite os includes com os relatórios agregados DMARC dos últimos 90 dias. - Mova o tráfego em massa para um subdomínio, como `mail.example.com`, com registro SPF próprio e orçamento próprio de 10 consultas. - Achate os includes em faixas `ip4:` literais, mas apenas com automação. Fornecedores rotacionam IPs, e um registro achatado à mão fica desatualizado sem nenhum alerta. ![Quadro branco com setas saindo de vários serviços de envio até uma caixa central](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/96537f-inline2.webp) ## Publique exatamente um registro SPF por domínio Um domínio não pode publicar dois registros SPF. Se o receptor encontrar duas entradas TXT com `v=spf1`, o resultado é `permerror`, como no limite de consultas. Isso acontece quando uma pessoa adiciona um registro para uma ferramenta nova enquanto outra já tinha publicado o seu. A correção é mecânica. Junte os termos num único registro, com um `v=spf1` no início e um `all` no fim. Tudo o que a documentação do fornecedor pedir entra dentro do registro existente como mais um `include:`, nunca como uma nova entrada TXT. Duas armadilhas menores. Uma string TXT com mais de 255 caracteres precisa ser dividida em várias strings entre aspas dentro do mesmo registro, o que a maioria dos provedores de DNS faz para você. E mantenha a resposta inteira abaixo de cerca de 450 bytes sempre que possível, porque respostas maiores podem cair do UDP para TCP, e alguns resolvedores lidam mal com isso. ## Softfail ou hardfail: escolha com base no que você consegue ver O termo `all` é uma declaração de política, e o conselho padrão ("use `-all`") pula justamente a parte que importa. Um hard fail só é seguro quando você conhece todos os remetentes legítimos. Nossa regra prática, tirada da leitura de traces: - `~all` enquanto você ainda faz o inventário de remetentes, ou se encaminha e-mails e não controla o caminho. - `-all` quando os relatórios DMARC mostrarem que todas as fontes legítimas passam por algumas semanas. - Nunca `+all`, que autoriza a internet inteira, e nunca `?all` num domínio de produção. Na prática, a diferença é menor do que se imagina. A maioria dos grandes receptores trata o SPF como um sinal entre vários, e com uma política DMARC publicada o veredito do DMARC é o que decide. Ainda assim, um `-all` num registro incompleto é a forma mais rápida de perder notas fiscais. ![Feixe de cabos ethernet identificados dentro de um rack de servidores](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/3e48d3-inline3.webp) ## O SPF quebra no encaminhamento, e isso é por design O SPF valida o IP que se conectou ao servidor receptor. Quando uma mensagem é encaminhada, redistribuída por uma lista de discussão ou retransmitida por um serviço de alias, o IP conectado é o do encaminhador, não o seu. A verificação SPF falha mesmo sem você ter feito nada de errado. Não há como corrigir isso dentro do SPF. Por isso o DKIM existe ao lado dele: a assinatura sobrevive ao salto, uma lista de IPs não sobrevive. Um domínio que depende só do SPF verá falhas de autenticação em toda mensagem encaminhada. Por isso o SPF sozinho também não satisfaz o DMARC para e-mails encaminhados. Conte com o DKIM para levar essas mensagens. ## Alinhamento SPF: passar não é o mesmo que bater com o domínio From Uma mensagem pode passar no SPF e ainda falhar no DMARC. O DMARC exige que o domínio que passou no SPF, o domínio do Return-Path, seja igual ao domínio do From visível. Muitos provedores compartilhados usam por padrão o próprio domínio de bounce, então o SPF passa para `provedor-mail.net` e não diz nada sobre `example.com`. Verifique isso nos cabeçalhos brutos. Na linha `Authentication-Results`, procure `smtp.mailfrom=`. Se ele não for o seu domínio ou um subdomínio dele, o SPF está passando sem ajudar você. O remédio é um Return-Path personalizado num subdomínio seu, algo que os remetentes sérios costumam suportar. Postmark, Resend, Mailgun e SendGrid documentam essa configuração, embora nem sempre ela venha ativada por padrão. ## Os provedores de caixa de entrada agora exigem autenticação de todo remetente Desde fevereiro de 2024, o Google exige que todos os remetentes se autentiquem com SPF ou DKIM, e quem envia mais de 5.000 mensagens por dia para o Gmail precisa ter SPF, DKIM e DMARC configurados. Os detalhes estão nas [diretrizes do Google para remetentes de e-mail](https://support.google.com/mail/answer/81126). O Yahoo definiu regras equivalentes na mesma época. Isso tirou o SPF da categoria "seria bom ter" e o colocou entre os pré-requisitos de entrega. Um registro ausente ou quebrado agora aparece como rejeição e spam, não apenas como uma nota de reputação mais baixa. Nossa leitura depois de alguns anos de traces: as regras pegam sobretudo domínios sem autenticação nenhuma e remetentes com taxa alta de reclamação de spam. Um registro SPF correto sozinho não coloca você na caixa de entrada, mas um registro ausente mantém você fora. ## Como verificar e corrigir um registro SPF em quatro passos Faça estes passos na ordem e verifique de novo após cada mudança no DNS. - **Consulte o registro atual.** Rode `dig +short TXT example.com` e encontre a entrada que começa com `v=spf1`. Se houver duas, junte-as. - **Conte as consultas.** Some `include`, `a`, `mx`, `exists`, `redirect` e tudo o que está aninhado nos includes. Se você estiver em 8 ou mais, planeje a limpeza agora, e não no 11º. - **Liste os remetentes reais.** Use os relatórios agregados DMARC ou os cabeçalhos Authentication-Results de envios de teste. Adicione só as fontes que aparecem. - **Envie um teste e leia o cabeçalho.** O resultado deve mostrar `spf=pass` com `smtp.mailfrom` no seu domínio. Mudanças de DNS levam tempo para se propagar, e o TTL do registro atual define quanto tempo as respostas antigas sobrevivem. Reduza-o para 300 segundos um dia antes de uma mudança planejada. ## Um registro completo para uma empresa SaaS com três remetentes Imagine um produto que envia pelo Google Workspace, por um provedor transacional e por uma central de suporte. Um registro limpo fica assim: `example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"`São três includes, e cada um esconde consultas aninhadas. Conte antes de publicar, porque o tamanho visível do registro não diz nada sobre o orçamento real. Um registro com três includes já pode estar em 7 ou 8 consultas. Agora separe por finalidade. Mantenha o e-mail humano no domínio raiz. Coloque as notificações do produto em `notify.example.com`, com um registro que liste apenas o provedor transacional. O registro raiz fica curto, o subdomínio ganha orçamento próprio de 10 consultas, e um problema de reputação num fluxo deixa de arrastar o outro. Essa separação também torna os relatórios DMARC legíveis. Cada fluxo tem seu próprio domínio de Return-Path, então uma falha aponta para um remetente, e não para um monte deles. ## O que o SPF não faz Ele não impede alguém de falsificar o seu endereço From, porque nunca olha esse cabeçalho. Não criptografa nada. Não explica por que uma mensagem caiu no spam. E não escala além do orçamento de 10 consultas sem manutenção contínua. Trate-o como um de três registros que você publica juntos: SPF para o caminho de envio, DKIM para a integridade da mensagem, DMARC para a política que amarra os dois ao seu domínio From. Se você tem SPF e mais nada, o próximo passo concreto é publicar um registro DMARC com `p=none` e ler os relatórios por duas semanas. ## FAQ ### O que é um registro SPF em termos simples? É um registro DNS do tipo TXT que lista os servidores autorizados a enviar e-mail pelo seu domínio. O receptor compara o IP de envio com essa lista para decidir se a mensagem passa no SPF. ### Um domínio pode ter mais de um registro SPF? Não. Dois registros que começam com v=spf1 geram permerror. Junte todos os remetentes autorizados em um único registro, com um só termo all no final. ### Qual é o limite de 10 consultas DNS do SPF? A RFC 7208 limita a avaliação a 10 termos que fazem consultas DNS: include, a, mx, ptr, exists e redirect. Includes aninhados também contam. Ao passar do limite, o resultado é permerror e o SPF deixa de autenticar seu e-mail. ### Devo usar -all ou ~all no registro SPF? Use ~all enquanto faz o inventário de remetentes e troque para -all quando os relatórios DMARC mostrarem que todas as fontes legítimas passam por várias semanas. Nunca use +all, que autoriza qualquer servidor. ### Por que o SPF falha quando o e-mail é encaminhado? O SPF verifica o IP que se conecta ao receptor. Quem encaminha se conecta a partir do próprio IP, que o seu registro não lista. O DKIM sobrevive ao encaminhamento porque a assinatura viaja com a mensagem. ### O SPF sozinho protege contra falsificação de remetente? Não. O SPF valida o envelope do remetente, não o endereço From visível. Para proteger o domínio do From é preciso o DMARC, que exige que SPF ou DKIM passem e batam com ele.