Ferramentas populares

Tema

Verificar SPF — Registro SPF

Para verificar o SPF de um domínio como fazem os servidores de e-mail de destino, veja cada include com o próprio custo em consultas DNS, o total corrido contra o limite de 10, as consultas vazias e o resultado para qualquer IP de envio, com o termo que decidiu. Serve também para validar o SPF depois de uma mudança.

Fontes: os registros TXT do domínio e cada include, pelo Google Public DNS (com a Cloudflare 1.1.1.1 por trás) · check_host da RFC 7208, executado no nosso servidor · nada é guardado

Exatamente o nome que você digita: o SPF não tem herança, então mail.example.com precisa do próprio registro.

Experimente

O que é um registro SPF?

Um registro SPF é um registro TXT que lista os servidores autorizados a enviar e-mails por um domínio. Ele começa com v=spf1, cita os remetentes termo por termo e termina dizendo o que os servidores de destino devem pensar de todos os outros (RFC 7208, abril de 2014, ainda o padrão atual).

Os servidores de destino o conferem com o endereço do servidor que se conecta e com o domínio do remetente do envelope, o MAIL FROM ou Return-Path, não com a linha From: que o leitor vê. Ligar o SPF ao From: é trabalho do DMARC.

Um registro cobre só o nome exato em que está publicado: o SPF não tem herança, então mail.example.com precisa do próprio registro. Um domínio que não envia e-mails deve publicar v=spf1 -all.

Um registro SPF, termo por termogoogle.com · TXT · registrado em 24 de outubro de 2026 · TTL 5 minutos
v=spf1Versãoinclude:_spf.google.comMecanismo · 1 consulta~allQualificador ~ · mecanismo all

O include aponta para _spf.google.com · 8 intervalos, sem mais consultas

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

VersãoExatamente v=spf1, no começo: um registro que comece de outro jeito não é um registro SPF.
Mecanismosinclude, a, mx, ip4, ip6, exists, ptr e all, testados da esquerda para a direita: a primeira combinação decide.
Qualificadores+ pass (o padrão), - fail, ~ softfail, ? neutral, escritos antes de um mecanismo.
Modificadoresredirect= passa a verificação para outro registro; exp= explica um fail.
O registro inteiro de google.com tem três termos: um servidor de destino busca o include, confere o IP de envio com os intervalos dele ou chega ao ~all. Registrado pelo Google Public DNS em 24 de outubro de 2026.

Como verificar um registro SPF

Digite um domínio acima e o verificador lê os registros TXT dele, escolhe o que começa com v=spf1 e segue cada include e redirect como um servidor de destino faria, contando cada consulta DNS pelo caminho. É o jeito mais rápido de validar o SPF de um domínio.

À mão, peça os registros TXT: dig TXT example.com +short ou nslookup -type=TXT example.com. A resposta traz todos os registros TXT do nome; o registro SPF é o que começa com v=spf1, e um registro longo vem como várias strings entre aspas que o SPF junta sem espaço. Cada include é mais uma consulta, e você teria de contá-las por conta própria.

Para ver se um servidor específico pode enviar, passe para Testar um IP: ele faz a mesma verificação para esse endereço e mostra o termo que combinou.

dig TXT example.com +short

Todos os registros TXT do nome, como o seu resolvedor os tem; o registro SPF é o que começa com v=spf1. Rode de novo para cada include.

O que o dig mostra e o que não mostragithub.com · dig TXT · registrado em 24 de outubro de 2026
linha de comando1 de 24 registros TXT
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# e depois cada include, uma consulta por vez:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Um registro começa com v=spf1. Os 23 outros registros TXT ao lado dele (tokens de verificação e coisas do tipo) não importam para o SPF, a não ser pelo tamanho da resposta.
  2. 2 strings, juntas sem espaço. A divisão de 255 bytes cai dentro de ip4:62.253.227.114: os servidores de destino juntam as strings de volta, então tudo bem.
  3. TTL 5 minutos. Por quanto tempo os resolvedores podem guardar esta cópia depois de uma mudança. O servidor da própria zona diz 5 minutos; um resolvedor mostra o que resta da cópia dele.
  4. Cada include é uma consulta própria. Seguir o registro de github.com leva 10 consultas, contando os aninhados. O dig mostra um nome por vez: somar até 10 fica por sua conta.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# todos os registros TXT do nome, do Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Esta página
/pt/spf-checker?domain=github.com
A resposta TXT de github.com vinda do próprio servidor de nomes: o registro SPF chega como duas strings, juntas sem espaço, entre os outros registros TXT do domínio.

Lendo o resultado: a árvore de includes

O veredito diz o que os servidores de destino recebem para um remetente que o registro não lista: válido com o final dele (softfail para ~all, fail para -all), ou um permerror com a causa, ou "não deu para verificar" quando o DNS não respondeu.

A coluna azul-marinho é o orçamento de consultas: uma célula por consulta DNS, colorida pelo include que a gasta, o total corrido contra 10 e as consultas vazias como anéis. Passada a 10ª, as células ficam vermelhas e o ramo em que os servidores de destino param é marcado.

A visualização Árvore lista as leituras, com as falhas primeiro, cada uma com a seção da RFC e a correção, e depois cada consulta na ordem em que um servidor de destino as faz.

Verificar SPF de github.com: 10 de 10 consultas DNS, uma consulta vazia e o custo de cada include no orçamento de consultasVerificar SPF de github.com: 10 de 10 consultas DNS, uma consulta vazia e o custo de cada include no orçamento de consultasO vereditoO que os servidores de destino recebem para um remetente que o registro não lista, e o final que decide isso.O registro, termo por termoCada termo colorido por tipo; um include leva a marca do dono e o próprio custo em consultas.As leiturasUm registro, sintaxe válida, consultas, consultas vazias, o final, ptr, DMARC: as falhas primeiro, cada uma com a correção.O orçamento de consultasCada consulta DNS como uma célula, colorida pelo include que a gasta, contra o limite de 10.O custo de cada includeUm ramo por include: as próprias células, o que ele aninha e o total corrido.As consultas vaziasAnéis para consultas que voltaram vazias; a terceira encerra a verificação.
Uma verificação de SPF de github.com: o veredito, o registro dividido em termos, as leituras e o orçamento de consultas com o custo de cada include. Selecione um número para ver o que cada parte mostra.

O limite de 10 consultas e "too many DNS lookups" (permerror)

Os servidores de destino contam cada termo que exige uma consulta DNS, include, a, mx, ptr, exists e redirect, por todos os includes aninhados, e param em 10. A 11ª dá permerror (RFC 7208 §4.6.4). ip4, ip6, all e exp não custam nada.

É um permerror, não um fail: o que o servidor de destino faz com ele é escolha dele, mas com o DMARC um permerror nunca conta como pass. E, como a verificação para na primeira combinação, um registro acima do limite ainda passa para os remetentes listados no começo e só quebra para os listados no fim.

O custo se esconde dentro dos includes: include:_netblocks.mimecast.com gasta 9 sozinho, o do Yandex 360 gasta 8, o do Freshdesk 7, o do Mailgun 5. Os includes do Google e do Microsoft 365 custam 1 cada. Para ficar abaixo de 10, tire os remetentes que você não usa mais e mova um remetente em massa para um subdomínio com registro próprio.

Quem gasta as 10 consultasCustos medidos em 24 de outubro de 2026 · um registro inventado com includes reais

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

17 consultas necessárias
Listado dentro das primeiras 10 consultas: passMicrosoft 3651Mimecast2–10
Listado depois da consulta 10: permerrorMailgun11–15Twilio SendGrid16–17

Todos os outros também recebem permerror, não o fail do -all do registro: os servidores de destino param antes de chegar a ele.

O que um include custaO include documentado por cada provedor · medido em 24 de outubro de 2026
  • _netblocks.mimecast.comMimecast9 consultas
  • _spf.yandex.netYandex 3608 consultas
  • email.freshdesk.comFreshdesk7 consultas
  • mailgun.orgMailgun5 consultas
  • icloud.comiCloud+5 consultas
  • spf.titan.emailTitan Email4 consultas
  • secureserver.netGoDaddy3 consultas
  • _spf.google.comGoogle Workspace1 consulta
  • spf.protection.outlook.comMicrosoft 3651 consulta
Consultas contadas como a RFC 7208 §4.6.4 conta: o próprio include mais tudo o que há dentro dele. As contagens ao vivo desta página sempre vêm do percurso, não desta tabela.

O que são consultas vazias (void lookups)?

Uma consulta vazia é uma consulta que volta sem registros: o nome não existe (NXDOMAIN) ou existe sem o registro pedido. Os servidores de destino devem permitir duas; a terceira é permerror (RFC 7208 §4.6.4).

Um termo que aponta para um host que sumiu, a:old.example.com, não é um erro por si só: ele só não combina e conta uma consulta vazia. O mesmo vale para exists:%{i}._spf.mta.salesforce.com com todo remetente que a Salesforce não lista, e é por isso que a ordem dos includes importa.

Uma falha do servidor ou um timeout não é uma consulta vazia: é um temperror, e os servidores de destino costumam tentar de novo mais tarde.

Quatro respostas, três resultadosRFC 7208 §4.6.4

O registro de salesforce.com para 192.0.2.1, registrado em 24 de outubro de 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Consultas vazias2 / 2a terceira: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · consulta 3 · em _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · consulta 4 · em salesforce.com

Resultado: softfail, com as duas consultas vazias permitidas gastas

O nome existe, o registro nãoa:mail.example.com para um nome que ainda existe, mas não tem mais um endereço: NOERROR sem resposta. Sem combinação, uma consulta vazia, e a verificação segue.NODATAvazia
O nome não existeexists:%{i}._spf.mta.salesforce.com monta um nome a partir de cada IP de envio; para um endereço que a Salesforce não lista, a resposta é NXDOMAIN: uma consulta vazia a cada vez.NXDOMAINvazia
A terceira consulta vaziamx:shop.example.com, um nome que sumiu, depois de 2 consultas vazias: os servidores de destino param aqui.NXDOMAINpermerror
Nenhuma respostaSERVFAIL ou um timeout para include:_spf.vendor.example: o DNS falhou, então nada conta como consulta vazia.SERVFAILtemperror, não é uma consulta vazia

O include include:spf.bmv.jp de blastmail começa com dois termos exists assim: para um endereço que ele não lista, gasta sozinho as duas consultas vazias permitidas.

Só uma resposta vazia conta como consulta vazia. Uma falha é um temperror, e a verificação é tentada de novo mais tarde.

SPF flattening: quando ajuda e quando quebra

O flattening troca um include pelos endereços que ele lista, para o registro custar menos consultas. Funciona para intervalos que mudam pouco e sai pela culatra quando um provedor acrescenta um servidor que você não copiou: os e-mails dele passam então a falhar no SPF.

A Microsoft diz para não achatar include:spf.protection.outlook.com, e os includes do Google e da Microsoft já custam uma consulta cada. Mover um remetente em massa para um subdomínio como news.example.com dá a ele um registro, e 10 consultas, só dele.

Um include, achatadomailgun.org · registrado em 24 de outubro de 2026

Antes

include:mailgun.org

Consultas
5
Registros buscados
5
Bytes no seu registro
19
Mailgun muda um intervalo
pego na hora

Depois

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 a mais

Consultas
0
Bytes no seu registro
450
Strings TXT necessárias
2
Mailgun muda um intervalo
sua cópia está velha

O risco da cópia velha. Você copia 22 intervalos hoje; quando a Mailgun acrescenta um, os e-mails dele falham no SPF até alguém notar e atualizar o registro.

  1. copiado
  2. Mailgun acrescenta um intervalo
  3. os e-mails dele falham no SPF
Achate só intervalos que mudam pouco, como os endereços dos seus próprios servidores.
Não achate Microsoft 365: a Microsoft diz que os endereços de envio dela mudam com frequência, então mantenha o include.
Prefira um subdomínio por remetente em massa: cada um ganha um registro, e 10 consultas, só dele.
O flattening troca consultas por manutenção: a cópia só está certa até o provedor mudar os intervalos dele.

~all vs -all (e o DMARC)

O último termo diz o que acontece com todo remetente não listado. -all é fail, a declaração mais forte; ~all é softfail, "provavelmente não"; ?all é neutral, que os servidores de destino tratam como a ausência de SPF; +all deixa todo mundo passar e nunca deve ser publicado.

Entre ~all e -all não existe resposta errada. O Google documenta ~all para o Google Workspace e a Microsoft -all para o Microsoft 365. Com o DMARC em modo de aplicação, o ~all deixa o DMARC decidir pelo DKIM: alguns servidores de destino rejeitam por -all antes de o DMARC ver uma assinatura DKIM válida, então e-mails encaminhados podem voltar (RFC 9989 §7.1).

Os quatro finaisRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail“Provavelmente não autorizado”: os servidores de destino não devem rejeitar só por isso.
Documentado porGoogle WorkspaceMailguniCloud+
-all
failA declaração mais forte: um servidor de destino pode rejeitar a mensagem no SMTP.
Documentado porMicrosoft 365ZendeskGoDaddy
?all
neutralNenhuma declaração: os servidores de destino tratam exatamente como a ausência de SPF.
Documentado porFastmailOs includes de IONOS e OVHcloud também terminam em ?all: inofensivo ali, já que só um pass dentro de um include combina.
+all
pass para todosQualquer servidor da Internet passa como o domínio.
Nunca publique

-all com DMARC em p=reject

  1. fail no SPF
  2. rejeitado no SMTP
  3. DKIM nunca verificado

Alguns servidores de destino agem primeiro pelo SPF, então uma mensagem encaminhada com assinatura DKIM válida pode ser recusada antes de o DMARC rodar, e a perda nunca aparece nos relatórios do DMARC.

~all com DMARC em p=reject

  1. softfail no SPF
  2. o DMARC verifica o DKIM
  3. DKIM alinhado: pass

O DMARC decide. Sem uma assinatura DKIM, porém, a Microsoft diz que o DMARC é na prática ignorado nas falhas de ~all, e recomenda -all por isso.

~all e -all são escolhas válidas; ?all não diz nada, e +all deixa qualquer um passar.

Erros comuns de SPF e como corrigi-los

A maioria dos registros quebrados vem de três deslizes: um segundo registro SPF acrescentado ao lado do primeiro em vez de juntá-los, um include de um fornecedor que já saiu e um valor copiado da documentação com um erro de digitação.

A documentação dos fornecedores imprime alguns deles: a Mimecast escreve –all com um travessão en, a Postmark include: spf.mtasv.net com um espaço, a Twilio SendGrid lista um mecanismo aaaa que não existe. Qualquer erro de sintaxe faz o registro inteiro virar permerror. Um ponto final depois de um domínio, por outro lado, é válido.

Oito registros, oito resultadosExemplos inventados de erros reais

Dois registros SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Correção: junte-os em um só: um v=spf1, cada include uma vez, um final.

Mais de 10 consultaspermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 consultas

Correção: tire os remetentes que você não usa mais ou dê a um remetente em massa um subdomínio só dele.

Uma terceira consulta vaziapermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 vazias

Correção: apague os termos cujos nomes sumiram e ponha os includes exists por último.

Um include sem registro SPF por tráspermerror

v=spf1 include:spf.retired-vendor.example -all

Correção: corrija o nome ou remova o fornecedor que você deixou.

Um travessão en em –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Impresso assim na própria documentação da Mimecast

Correção: um hífen simples: -all.

Um espaço depois de include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Impresso assim na própria documentação da Postmark

Correção: include:spf.mtasv.net

Um mecanismo aaaapermerror

v=spf1 aaaa:example.com ~all

Impresso assim na própria documentação da Twilio SendGrid

Correção: a:example.com; o a já combina com os registros AAAA de remetentes IPv6.

Um ponto finalválido

v=spf1 include:spf.protection.outlook.com. -all

Válido: a RFC 7208 §7.3 diz para não publicá-lo, mas os servidores de destino devem aceitá-lo.

A ajuda da Zendesk também diz “redirect: syntax is supported”: o modificador se escreve redirect= (RFC 7208 §6.1).

Cada registro é um exemplo inventado; os erros são os que os servidores de destino mais veem.

O que Gmail, Yahoo e Microsoft exigem

Desde fevereiro de 2024, Gmail e Yahoo exigem que todo remetente configure SPF ou DKIM. Quem envia em massa precisa dos dois, de um registro DMARC de pelo menos p=none e de um domínio no From: alinhado com um deles. O Outlook.com pede SPF e DKIM, os dois, a quem envia em alto volume, e rejeita quem não os tem desde 5 de maio de 2025.

O limite do Gmail é mais de 5.000 mensagens por dia para contas pessoais; o Yahoo não publica nenhum. O SPF sozinho nunca deixa um e-mail "alinhado": o domínio do MAIL FROM precisa ser seu, não o domínio de retorno do provedor.

As regras dos três provedores de caixas de e-mailLido nas próprias páginas de cada provedor, 24 de outubro de 2026
GmailYahooOutlook.com
Limite para envio em massaGmailmais de 5.000 mensagens por dia para contas pessoais do Gmail, contadas por domínio principalYahoonenhum publicado: “We will not specify a volume threshold”Outlook.commais de 5.000 por dia (blog da Microsoft); 5.000 ou mais de um mesmo domínio no From: (o artigo de suporte dela)
Todos os remetentesGmailSPF ou DKIM, mais DNS direto e reverso, TLS e uma taxa de spam abaixo de 0,3%YahooSPF ou DKIM, mais DNS direto e reverso e uma taxa de spam abaixo de 0,3%Outlook.comnenhuma regra rígida
Remetentes em massaGmailSPF e DKIM, DMARC (p=none basta), From: alinhado com SPF ou DKIM, cancelamento de inscrição com um clique para e-mails de marketingYahooSPF e DKIM, DMARC de pelo menos p=none e passando, From: alinhado com SPF ou DKIM, cancelamento de inscrição com um cliqueOutlook.comO SPF precisa passar e o DKIM precisa passar, DMARC de pelo menos p=none, alinhado com SPF ou DKIM
Em vigor desdeGmail1 de fevereiro de 2024; as rejeições aumentaram a partir de novembro de 2025Yahoofevereiro de 2024Outlook.com5 de maio de 2025 (rejeição)
A falha de SPF aparece comoGmail4.7.275.7.27Yahoonão documentado para o SPFOutlook.com550 5.7.515

Japão: a configuração mais rígida de NTT docomo, 「全て拒否する」, recusa e-mails cujo IP de envio o registro SPF do domínio não autoriza, e e-mails de domínios que não publicam nenhum registro SPF. docomo.ne.jp

Fontessupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

As regras de cada provedor como as próprias páginas dele as declaram em 24 de outubro de 2026.

Consulta SPF vs dig e nslookup

O dig e o nslookup mostram os registros TXT como o seu resolvedor os tem: o registro SPF e o mais que houver no nome. Eles não seguem includes, não contam consultas nem consultas vazias e não dizem o que um servidor de destino decidiria.

Uma consulta SPF como esta percorre o registro inteiro, então os números batem com o que um servidor de destino calcula. Use o dig para um nome, este verificador para o veredito.

Três jeitos de olhar o SPFO que cada um mostra
Este verificadordig TXTnslookup -type=TXT
Mostra os registros TXTEste verificadorSimdivididos em termosdig TXTSimnslookup -type=TXTSim
Junta as strings de um registro longoEste verificadorSimcomo os servidores de destinodig TXTNãomostra cada string à partenslookup -type=TXTNãomostra cada string à parte
Segue todos os includesEste verificadorSima árvore inteiradig TXTNãoum nome por consultanslookup -type=TXTNãoum nome por consulta
Conta as consultas até 10Este verificadorSimum total corrido, por includedig TXTNãoà mãonslookup -type=TXTNãoà mão
Conta as consultas vaziasEste verificadorSimcom os nomesdig TXTNãonslookup -type=TXTNão
Diz que dois registros = permerrorEste verificadorSimdig TXTNãoimprime os doisnslookup -type=TXTNãoimprime os dois
Testa um IP de envioEste verificadorSimcheck_host e o termo que combinoudig TXTNãonslookup -type=TXTNão
Pergunta ao seu próprio resolvedorEste verificadorNãoGoogle Public DNS, a partir do nosso servidordig TXTSimnslookup -type=TXTSim
A mesma pergunta feita de três jeitos: o dig e o nslookup mostram o que o seu resolvedor tem, o verificador o que um servidor de destino calcula.

Verificador de SPF: perguntas frequentes

O que é verificar um registro SPF?

Verificar um registro SPF é ler o registro SPF de um domínio, o registro TXT que começa com v=spf1, e percorrê-lo como um servidor de e-mail de destino faz: cada include e redirect seguido, cada consulta DNS contada contra o limite de 10 e cada resposta vazia contra o limite de 2. O fim é o que os servidores de destino recebem para um remetente não listado, ou o permerror e a causa dele.

Como testar se um endereço IP pode enviar e-mails pelo meu domínio?

Escolha Testar um IP, digite o domínio e o endereço do servidor de envio, IPv4 ou IPv6, e, se quiser, o endereço do MAIL FROM e o nome HELO. O verificador roda o check_host para esse endereço e mostra pass, fail, softfail, neutral ou permerror, o termo exato que combinou, o qualificador dele e a cadeia de includes que levou até ele.

O que significa "SPF too many DNS lookups"?

Significa que verificar o registro exige mais de 10 consultas DNS, o limite da RFC 7208. Cada include, a, mx, ptr, exists e redirect custa uma, inclusive os aninhados dentro de includes. Os servidores de destino param na 11ª com permerror, então os remetentes listados depois desse ponto deixam de passar no SPF. Remova includes sem uso ou mova um remetente para um subdomínio com registro próprio.

O que é um permerror de SPF?

Um permerror é o resultado do SPF para "este registro não pode ser avaliado". Vem de mais de 10 consultas DNS, mais de 2 consultas vazias, dois registros SPF no mesmo nome, um include de um nome sem registro SPF ou um erro de sintaxe. Não é um fail: os servidores de destino decidem o que fazer com ele, mas com o DMARC ele nunca conta como pass.

O que é uma consulta vazia (void lookup) no SPF?

Uma consulta vazia é uma consulta DNS feita para um termo SPF que volta sem nada: o nome não existe (NXDOMAIN) ou não tem registro do tipo pedido. A RFC 7208 diz que os servidores de destino devem permitir duas; a terceira é permerror. Uma falha do servidor ou um timeout não é uma consulta vazia, e sim um temperror, que os servidores de destino costumam tentar de novo mais tarde.

Meu registro SPF deve terminar com ~all ou -all?

Os dois são válidos. -all (fail) é a declaração mais forte e a Microsoft o documenta para o Microsoft 365; ~all (softfail) é o que o Google documenta para o Google Workspace. Com assinatura DKIM e DMARC em quarentena ou rejeição, ~all costuma ser o final mais seguro, porque alguns servidores de destino rejeitam por -all antes de o DMARC aceitar uma assinatura DKIM válida.

Um domínio pode ter dois registros SPF?

Não. Se um nome tem dois registros TXT que começam com v=spf1, os servidores de destino não conseguem escolher um e a verificação termina em permerror antes de qualquer consulta, para todos os remetentes (RFC 7208 §4.5). Isso costuma acontecer quando o registro de um novo provedor é acrescentado ao lado do antigo. Junte-os em um só, com um v=spf1, cada include uma vez e um único final.

O que é SPF flattening e devo usá-lo?

O flattening troca includes pelos intervalos de IP que eles listam, para o registro precisar de menos consultas DNS. Ajuda com intervalos que mudam pouco, mas uma cópia achatada fica velha assim que o provedor acrescenta servidores, e os e-mails deles passam a falhar no SPF. Prefira remover includes sem uso ou dar a um remetente em massa o próprio subdomínio; nunca achate o include do Microsoft 365.

Um subdomínio precisa do próprio registro SPF?

Sim. O SPF não tem herança: um registro cobre só o nome exato em que está publicado, então mail.example.com ou news.example.com precisa do próprio registro se aparece no MAIL FROM ou no HELO. Isso difere do DMARC, que recorre ao domínio organizacional. Um subdomínio que não envia e-mails pode publicar v=spf1 -all.

Por que o SPF passa aqui, mas falha no Gmail?

Em geral porque o Gmail verificou outro domínio ou endereço. O SPF é avaliado para o domínio do MAIL FROM (Return-Path) e o IP do servidor que se conecta, que podem ser o domínio de retorno do seu provedor, não o seu. O encaminhamento também quebra o SPF, já que o IP de quem encaminha não está no seu registro. Veja o cabeçalho Authentication-Results de um e-mail real e teste aqui esse IP e esse domínio.

Qual é a diferença entre SPF, DKIM e DMARC?

O SPF lista os servidores autorizados a enviar por um domínio e é conferido com o remetente do envelope. O DKIM assina cada mensagem com uma chave publicada no DNS, então a assinatura sobrevive ao encaminhamento. O DMARC os liga ao endereço do From: que o leitor vê: uma mensagem passa no DMARC quando o SPF ou o DKIM passa para um domínio alinhado com o From:, e a política diz o que fazer no caso contrário.

Quanto tempo leva para uma mudança no registro SPF valer?

O tempo que os resolvedores guardarem o registro antigo: até o TTL dele, que o domínio define (300 segundos para google.com e github.com, uma hora para microsoft.com quando verificamos). Os servidores de destino perguntam ao resolvedor deles, então uma mudança aparece quando cada cópia em cache expira. Este verificador mostra o TTL como o servidor de nomes do próprio domínio o serve; verifique de novo depois desse tempo.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta

Ferramentas de e-mail e DNS relacionadas