Um provedor só
- Entrada
- include:_spf.google.com
- Saída esperada
- v=spf1 include:_spf.google.com ~all
1 consulta no topo; o que há dentro do include se soma pela contagem real.
Carregando ferramenta… / Loading tool…
spf permerror muitas consultas dns
Marque os provedores na aba SPF e veja o medidor de consultas subir a cada include. O botão de contagem real segue a cadeia pelo DNS e mostra o total que o receptor vai enxergar, inclusive as consultas escondidas dentro de cada provedor.
1 consulta no topo; o que há dentro do include se soma pela contagem real.
0 consultas, por maior que seja a lista.
3 consultas no topo.
Já no amarelo: o próximo provedor provavelmente estoura, pois cada include ainda pode ter consultas por dentro.
O SPF inteiro é descartado.
0 consultas; nenhum IP está autorizado.
A RFC 7208 manda limitar a 10 os termos que fazem consulta de DNS: include, a, mx, ptr, exists e redirect. Ip4, ip6 e all não contam, mas cada include conta mais as consultas que existem dentro dele. Passou de 10, o resultado é PermError e o SPF inteiro é ignorado. Também há o limite de 2 void lookups, consultas que não devolvem nada. Use Contar consultas reais para seguir a cadeia e ver o total.
Não. Só os termos que fazem consulta de DNS contam: include, a, mx, ptr, exists e redirect. Endereços ip4 e ip6 e o all são resolvidos sem consultar o DNS, por isso trocar um include de IP estável por ip4 reduz o total.
Porque cada include traz as consultas do registro que ele aponta, e esses provedores muitas vezes têm includes aninhados. A conta é do conjunto. Use a contagem real para ver o total e os void lookups, que também têm limite de 2.
Só para provedores com IPs estáveis e documentados, e com revisão periódica. Achatar resolve os includes em endereços, e quando o provedor troca de IP o seu registro passa a rejeitar e-mail legítimo. Para provedores de IP dinâmico, como o Microsoft 365, prefira subdomínios.
Sem digitar nada o exemplo já funciona. Digite o seu domínio para os nomes dos registros virem completos.
include:_spf.google.comfonte oficialIncludes conferidos nas páginas de ajuda de cada provedor em 2026-10-18. Se o seu provedor não está aqui, use o campo abaixo.
~all: falha branda. Aceita e marca. Padrão da página do Google Workspace e boa escolha para começar.
@exemplo.com.br
v=spf1 include:_spf.google.com ~all
Include, a, mx, exists e redirect gastam uma consulta cada; ip4, ip6 e all não gastam. O limite é 10 no total, contando o que há dentro de cada include.
Prefira a chave que o seu provedor gera (Google Workspace, Microsoft 365, SES e outros): ele também assina as mensagens e cuida da rotação. A chave gerada aqui só serve se você mesmo configurar o servidor de e-mail para assinar com a chave privada. Nunca compartilhe nem versione a chave privada.
O seletor é o prefixo do nome do registro: mail._domainkey. Ele permite ter várias chaves ao mesmo tempo e trocar sem derrubar a assinatura. Use um nome por chave e por serviço, por exemplo com o ano.
Gere ou cole uma chave pública para ver o registro DKIM.
Use o que o painel dele mostrar. O Google Workspace publica um TXT em google._domainkey por padrão, e o Microsoft 365 usa dois CNAME em selector1._domainkey e selector2._domainkey. O tipo e o valor vêm do provedor: esta aba serve para quem gera a chave por conta própria. Depois de publicar, confira no verificador de SPF, DKIM e DMARC.
Tags p, sp, pct, rua, ruf, adkim, aspf, fo e ri. Todo receptor entende.
none: só monitora e envia relatórios. Nada é bloqueado. Ponto de partida de qualquer implantação.
Vazio usa dmarc@seu-domínio. Vários endereços separados por espaço. Endereços em outro domínio exigem um registro de autorização.
Na prática os receptores só aplicam bem 0 e 100 (RFC 9989, apêndice A.6). Valores no meio servem como transição, sem garantia.
Opcional. Veja o aviso de privacidade. Muitos receptores não enviam.
0: quando tudo falha. 1: quando qualquer um falha. d: falha de DKIM. s: falha de SPF. Só vale com ruf.
Fique em cada etapa o tempo necessário para ler os relatórios e corrigir todo remetente legítimo que falha. Não há prazo fixo; algumas semanas por etapa é comum.
v=DMARC1; p=none; rua=mailto:[email protected]
Nada muda na entrega. Você só recebe relatórios.
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
A política vale só para uma parte das falhas. Receptores nem sempre respeitam valores no meio.
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
A política vale só para uma parte das falhas. Receptores nem sempre respeitam valores no meio.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
Falhas vão para spam. Corrija remetentes legítimos antes do reject.
Arquivo SVG Tiny PS em HTTPS, hospedado no seu domínio.
O certificado vem de uma autoridade certificadora. A ferramenta não valida o certificado nem o desenho do logotipo.
XDMARC com p=quarantine ou reject (o Gmail não aceita p=none).
OKSem pct abaixo de 100 e sem modo de teste.
?VMC ou CMC emitido por uma autoridade certificadora. Não dá para checar aqui.
As duas primeiras linhas acompanham a política da aba DMARC.
Informe a URL do logotipo ou do certificado para montar o registro.
Ative o MTA-STS ou o TLS-RPT para gerar os registros.
A página do Google trata como volume quem envia mais de 5.000 mensagens por dia para contas Gmail pessoais. O Yahoo não define o termo.
Todo remetente precisa de ao menos um dos dois nos domínios de envio.
Remetentes em volume precisam dos dois.
Remetentes em volume precisam de uma política DMARC, mesmo que p=none, e a mensagem precisa passar nela.
O domínio do cabeçalho From deve alinhar com o domínio do SPF ou do DKIM. O alinhamento relaxado vale.
Mínimo de 1024 bits para o Gmail e o Yahoo. O Google recomenda 2048.
O Yahoo recomenda fortemente a tag rua. Sem ela você não vê as falhas.
Cada IP de envio precisa de PTR que aponta para um nome, e esse nome precisa resolver de volta ao mesmo IP. O Yahoo prefere PTR significativo, não genérico.
O Google exige TLS no envio de e-mail.
Acompanhe no Google Postmaster Tools. O Google recomenda ficar abaixo de 0,10% e evitar chegar a 0,30%.
Siga a RFC 5322 (o Yahoo cita também a 5321): um só endereço no From, Message-ID válido, cabeçalhos únicos não repetidos.
Inclua List-Unsubscribe com uma URL e List-Unsubscribe-Post com List-Unsubscribe=One-Click (RFC 8058). O gerador de cabeçalhos está logo abaixo.
Mensagens de marketing e assinadas precisam de um link de descadastro claramente visível no corpo.
O Yahoo pede que os descadastros sejam processados em até 2 dias.
O Yahoo pede um feedback loop de reclamações ativo para todos os domínios DKIM.
Não envie com endereço @gmail.com no From por servidores que não são do Google. O Google avisa que isso afeta a entrega.
Cole a URL HTTPS que recebe o POST do descadastro e, se quiser, um e-mail. Os cabeçalhos seguem o que a página do Google descreve (RFC 2369 e RFC 8058).
Os painéis mudam de tela. Confira a prévia do nome completo antes de salvar: ela deve bater com a coluna menor sob o nome de cada registro.
@exemplo.com.br
v=spf1 include:_spf.google.com ~all
Os registros são montados no seu navegador. Nenhum domínio, chave ou endereço é enviado a servidores. A contagem real de consultas do SPF, opcional, só pergunta ao DNS público os nomes dos includes.