/
Gerador DNS de E-mail (SPF DKIM DMARC)

Gerador DNS de E-mail (SPF DKIM DMARC)

Gere registros DNS de e-mail completos incluindo SPF, DKIM, DMARC, MX e BIMI. Exporte arquivos de zona BIND, combata o spoofing e garanta 100% de entregabilidade na caixa de entrada.

✨ Predefinições:

Fluxo de Entrega e Autenticação de E-mail em Tempo Real

Postura DMARC Ativa:p=none
MTA Remetenteacme-corp.comFiltro SPF~all (1/10 consultas)RFC 7208Verificação DKIMgoogle (RSA-2048)RFC 6376Alinhamento DMARCp=none (100%)RFC 7489Entregue na Caixa de EntradaApenas MonitoradoSpam / QuarentenaIgnoradoDescarte 550 / RejeiçãoInativo
Domínio e Arquitetura de E-mailacme-corp.com
Controles do Registro SPF (RFC 7208)1/10 consultas
Controles do Registro DKIM (RFC 6376)
Mecanismo de Política DMARC (RFC 7489)_dmarc.acme-corp.com
Porcentagem de Aplicação da Política (pct=)100%
Roteamento de E-mail MX (RFC 5321)1 servidores
1smtp.google.com.
Indicador de Marca BIMI (BIMI v1)
Domínio: acme-corp.comConsultas SPF: 1/10
Tabela consolidada de todos os registros DNS sintetizados. Copie valores individuais ou exporte o arquivo de zona completo.4 registros
TipoHost / NomePrioridade / TTLConteúdo do RegistroAção
MX@1 (TTL 3600)smtp.google.com.
TXT@3600v=spf1 include:_spf.google.com ~all
TXTgoogle._domainkey3600v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w9Z8fGk3wIDAQAB
TXT_dmarc3600v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Total de Registros: 4Postura: B (65/100)
Limite de Consultas RFC 7208
1 / 10Sem PermError
Segurança da Chave Criptográfica
RSA-2048String Única
Política Antispoofing
p=none100% Rollout

Processamento no Cliente

Cálculo de alta performance executado integralmente na memória do navegador.

Privacidade com Zero Envio ao Servidor

Todos os dados permanecem estritamente locais, sem qualquer transmissão para servidores externos.

Exportação Pronta para Produção

Formatos de saída limpos e otimizados, prontos para implantação imediata em servidores de DNS.

Referência técnica e guia de arquitetura

Gerador DNS de E-mail (SPF & DMARC) — Guia de referência

Gere registros DNS completos para e-mail com SPF, DKIM, DMARC, MX e BIMI. Exporte arquivos de zona BIND, bloqueie spoofing e garanta 100% de entregabilidade na caixa de entrada.

Gerador DNS de E-mail (SPF & DMARC) — Guia de referência — Arquitetura em memória do lado do cliente e fluxo de dados
Gerador DNS de E-mail (SPF & DMARC) — Guia de referência — Arquitetura em memória do lado do cliente e fluxo de dados

Parâmetros-chave e controles

v=spf1 (Versão do Sender Policy Framework)String ("v=spf1")

Designa o registro TXT como uma definição de política SPF versão 1 (RFC 7208). Deve figurar obrigatoriamente como o primeiro prefixo da string; qualquer caractere anterior ou variação em minúsculas faz com que os MTAs receptores rejeitem a sintaxe com erro permanente (PermError).

Padrão: v=spf1
include (Delegações de Domínios Autorizados no SPF)Lista de Strings de Domínio ("include:dominio.com")

Delega a autorização de envio via SPF ao registro de um serviço de terceiros. Cada instrução include dispara uma consulta DNS recursiva que conta para o limite obrigatório de 10 consultas estabelecido pela RFC 7208.

Padrão: _spf.google.com
all (Qualificador de Fallback do SPF)Enum ("-all" | "~all" | "?all" | "+all")

Determina a ação para mensagens originadas de endereços IP não autorizados. O valor -all impõe rejeição estrita (hard fail); ~all define falha suave (soft fail, aceito porém suspeito); ?all especifica disposição neutra.

Padrão: ~all
k & p (Algoritmo e Chave Pública do DKIM)Enum ("rsa" | "ed25519") e Chave em Base64

Publicado no registro TXT em <seletor>._domainkey.<dominio>. Define o algoritmo criptográfico k e a chave pública codificada em base64 p, utilizados pelos MTAs receptores para validar cabeçalhos DKIM-Signature conforme RFC 6376 e RFC 8463.

Padrão: k=rsa; p=...
p & sp (Políticas DMARC para Domínio e Subdomínios)Enum ("none" | "quarantine" | "reject")

Determina como os servidores de e-mail tratam mensagens que falham no alinhamento DMARC segundo a RFC 7489. none coleta métricas e relatórios sem interferir na entrega; quarantine direciona falhas para a caixa de spam; reject bloqueia o recebimento por completo.

Padrão: none
rua & ruf (URIs de Relatórios de Feedback DMARC)Lista de URIs (mailto:[email protected])

rua recebe relatórios diários de telemetria agregada em XML detalhando volume de entrega e taxas de sucesso/falha de autenticação; ruf recebe notificações forenses quase em tempo real de falhas individuais no formato AFRF da RFC 6591.

Padrão: mailto:[email protected]
aspf & adkim (Modos de Alinhamento de Identificador DMARC)Enum ("r" | "s")

r (relaxed/flexível) permite que subdomínios alinhem com o domínio organizacional raiz; s (strict/estrito) exige correspondência exata caractere por caractere entre o domínio do cabeçalho From (RFC 5322) e o Return-Path do SPF ou a tag d= do DKIM.

Padrão: r
Localização e Autoridade BIMI (Tags l= e a=)String de URI HTTPS

Publicado sob default._bimi.<dominio>. A tag l= aponta para o logotipo da marca em formato vetorial SVG Tiny Portable/Secure quadrado; a tag a= vincula opcionalmente ao Certificado de Marca Verificada (VMC) em formato PEM.

Padrão: Nenhum

Dicas profissionais e melhores práticas

Evite o Erro Fatal do Limite de 10 Consultas DNS no SPF

A RFC 7208 impõe um limite estrito de no máximo 10 consultas DNS na avaliação de um registro SPF, somando include, a, mx, ptr e redirect. Ultrapassar 10 lookups gera um erro permanente (PermError), fazendo com que grandes provedores (Gmail, Yahoo, Outlook) classifiquem seus e-mails como não autenticados ou spam. Utilize blocos de IP CIDR em vez de mecanismos a ou mx, e consolide periodicamente cadeias de include de terceiros.

Divida Chaves DKIM de 2048 Bits para BIND e Cloudflare

Registros DNS TXT impõem um limite máximo de 255 octetos por string individual (RFC 1035). Chaves RSA padrão de 2048 bits geram cerca de 400 caracteres em base64. Nunca trunque a chave; em vez disso, envolva o registro entre parênteses com strings concatenadas: ("v=DKIM1; k=rsa; p=PRIMEIROS_200_CARACTERES" "CARACTERES_RESTANTES"). Cloudflare e painéis DNS modernos fazem essa divisão automaticamente, mas arquivos de zona BIND brutos exigem concatenação explícita.

Execute uma Implementação Progressiva do DMARC em 3 Fases

Nunca configure p=reject diretamente em domínios de produção. Inicie com p=none; rua=mailto:... por 2 a 4 semanas para mapear todos os remetentes legítimos de shadow IT (CRMs, plataformas de suporte, folha de pagamento). Progrida para p=quarantine; pct=25 aumentando gradualmente até pct=100 e, finalmente, faça a transição para p=reject; sp=reject assim que todos os fluxos legítimos passarem pelo alinhamento SPF e DKIM.

Bloqueie Spoofing Oculto em Subdomínios com sp=reject

Atacantes frequentemente forjam e-mails a partir de subdomínios inativos (ex.: cobranca.suamarca.com.br). Se o seu domínio raiz estiver com p=none durante o período de monitoramento, defina explicitamente sp=reject para bloquear ataques em subdomínios não configurados sem impactar o fluxo de e-mails do domínio principal.

Armadilhas comuns e solução de problemas

⚠️DMARC falha no alinhamento mesmo com SPF e DKIM reportando PASS

Passar na autenticação técnica não é suficiente; o DMARC exige alinhamento de identificadores. Verifique se o domínio visível no cabeçalho From: (RFC 5322) coincide com o domínio do Return-Path (Mail From, RFC 5321) no SPF ou com a tag d= na assinatura DKIM. Ao enviar via plataformas de terceiros (como Mailchimp ou Zendesk), configure chaves DKIM personalizadas e um CNAME de Return-Path customizado para que os cabeçalhos usem a sua marca em vez do domínio compartilhado do fornecedor.

⚠️Gmail e Yahoo rejeitam e-mails com erro 550-5.7.26 de autenticação

Desde fevereiro de 2024, Google e Yahoo exigem obrigatoriamente SPF, DKIM e DMARC para remetentes em massa (mais de 5.000 mensagens/dia). Garanta que seu domínio tenha um registro DMARC ativo (mínimo p=none), DNS reverso (rDNS/PTR) válido correspondente ao hostname do servidor MTA remetente e cabeçalhos de cancelamento de inscrição em um clique (RFC 8058). Verifique também se o registro SPF não excede o limite de 10 consultas DNS.

⚠️Provedor DNS exibe erro de string superior a 255 caracteres ou sintaxe TXT inválida

Isso ocorre ao colar chaves DKIM de 2048 ou 4096 bits em painéis de controle DNS que não dividem strings longas automaticamente. Ative a opção de divisão segura para 255 bytes nesta ferramenta para exportar o registro formatado em múltiplas substrings entre aspas duplas, ou configure seu MTA para utilizar chaves RSA de 1024 bits ou chaves modernas Ed25519, se suportadas pelo servidor de correio.

Perguntas frequentes (FAQ)

Como o limite de 10 consultas DNS no SPF afeta a entregabilidade de e-mails?▼

A RFC 7208 estabelece que a avaliação de um registro SPF não pode ultrapassar 10 consultas DNS diretas ou aninhadas somando mecanismos include:, a, mx, ptr, exists: e redirect. Se uma mensagem recebida disparar a 11ª consulta, o MTA receptor interrompe a verificação imediatamente com um erro permanente (PermError). Os principais servidores de e-mail (Google Workspace, Microsoft 365, Yahoo) tratam o PermError como falha total de autenticação, encaminhando mensagens diretamente para o spam ou rejeitando a entrega no ato da conexão. Para se manter dentro do limite, remova mecanismos a e mx desnecessários, substitua domínios por blocos de IP diretos (ip4: e ip6:) e evite aninhar múltiplos provedores SaaS no domínio raiz.

Por que e-mails falham no alinhamento DMARC mesmo quando SPF e DKIM são aprovados?▼

A validação DMARC não exige apenas que o SPF ou DKIM passem nos testes criptográficos, mas também que o domínio autenticado esteja rigorosamente alinhado ao domínio do cabeçalho From: visível ao destinatário (RFC 5322). Ao disparar mensagens via serviços terceirizados (como SendGrid, Salesforce ou Shopify) sem configuração de domínio próprio, o SPF é validado em nome do provedor (ex.: sendgrid.net no Return-Path) e o DKIM usa a chave do fornecedor, mas nenhum coincide com suaempresa.com.br. Como o domínio autenticado e o remetente visível são distintos, o alinhamento DMARC falha. Para solucionar, configure um subdomínio de Return-Path personalizado para o SPF e crie registros CNAME de DKIM dedicados para assinar os e-mails com seu próprio domínio.

Como dividir chaves públicas DKIM de 2048 bits com mais de 255 caracteres no DNS?▼

De acordo com a RFC 1035, uma única cadeia de caracteres em um registro DNS TXT não pode exceder 255 octetos. Como uma chave pública RSA de 2048 bits codificada em base64 tem cerca de 400 caracteres, o registro precisa ser dividido em duas ou mais substrings. Em arquivos de zona BIND e no PowerDNS, isso é feito encapsulando o registro entre parênteses e colocando cada segmento entre aspas duplas: ( "v=DKIM1; k=rsa; p=PARTE_1" "PARTE_2" ). Na consulta DNS, os servidores recursivos concatenam esses segmentos automaticamente em uma chave contínua, sem espaços adicionais. Provedores como Cloudflare, AWS Route 53 e Google Cloud DNS realizam essa quebra de forma transparente, enquanto painéis legados como cPanel ou certos registradores exigem a inserção manual das partes entre aspas.

Qual é a diferença entre as políticas p=none, p=quarantine e p=reject no DMARC?▼

A tag p= define a instrução que os servidores de e-mail receptores devem executar quando uma mensagem que alega partir do seu domínio falha no alinhamento SPF e DKIM. A política p=none opera em modo de monitoramento passivo: os e-mails são entregues normalmente e relatórios diários agregados em XML são enviados ao endereço configurado em rua=. A política p=quarantine orienta os destinatários a encaminharem mensagens não alinhadas para a pasta de spam, lixo eletrônico ou quarentena, mitigando ataques de phishing enquanto permite auditoria. Já a política p=reject aplica a proteção máxima, instruindo os servidores receptores a recusarem mensagens não alinhadas durante o diálogo SMTP (rejeição com erro 550 SMTP), impedindo que e-mails forjados cheguem à caixa postal de destino.

Como configurar registros BIMI com Certificados VMC para Gmail e Apple Mail?▼

O Brand Indicators for Message Identification (BIMI) exibe logotipos oficiais autenticados ao lado de e-mails em clientes compatíveis, como Gmail, Apple Mail e Yahoo. Para implementar o BIMI: 1) Garanta que seu domínio possua uma política DMARC ativa com p=quarantine (pct=100) ou p=reject; 2) Crie um arquivo vetorial no perfil estrito SVG Tiny Portable/Secure (proporção 1:1 quadrada, sem scripts ou animações); 3) Obtenha um Certificado de Marca Verificada (VMC) emitido por uma autoridade certificadora autorizada (como DigiCert ou Entrust), comprovando a titularidade da marca registrada; 4) Publique um registro TXT em default._bimi.seudominio.com com o conteúdo v=BIMI1; l=https://seudominio.com/logo-bimi.svg; a=https://seudominio.com/certificado-vmc.pem. Enquanto o Yahoo pode exibir logotipos sem VMC, o Gmail e o Apple Mail exigem obrigatoriamente um VMC válido para exibir a identidade visual.

Ferramentas e utilitários relacionados

Todas as ferramentas →