DMARC mínimo para remetente em volume
- Entrada
- p=none, rua [email protected]
- Saída esperada
- v=DMARC1; p=none; rua=mailto:[email protected]
Atende o piso do Gmail e do Yahoo; não protege contra falsificação.
Carregando ferramenta… / Loading tool…
exigências gmail yahoo remetentes em massa spf dkim dmarc
A aba Gmail e Yahoo reúne as exigências com a origem de cada uma (Google, Yahoo ou as duas) e marca como coberto tudo o que os registros gerados já resolvem. O que não é DNS fica como lista de conferência, e o gerador de cabeçalhos de descadastro está na mesma aba.
Atende o piso do Gmail e do Yahoo; não protege contra falsificação.
Registro da página oficial do Google.
Acompanha List-Unsubscribe-Post: List-Unsubscribe=One-Click.
A chave pública de 2048 bits ocupa 294 bytes, que em base64 são 392 caracteres.
Já no limite que o Google manda evitar; a recomendação é ficar abaixo de 0,10%, ou 10 reclamações nessa base.
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.
Para o Google, quem envia mais de 5.000 mensagens por dia a contas pessoais do Gmail. O Yahoo não define o termo em sua página. Na dúvida, aplique as regras de volume: o custo é publicar um DMARC e manter o alinhamento.
Para a exigência de ter DMARC, sim: as duas páginas aceitam none. Mas p=none só monitora, então não impede ninguém de falsificar o seu domínio. O plano de implantação da aba DMARC leva até quarantine e reject.
O Google cita que mensagens que falham na autenticação exigida podem ser recusadas com o erro 5.7.26. Além disso, enviar com taxa de spam alta ou sem descadastro prejudica a reputação e a entrega, mesmo sem recusa explícita.
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.