Gerador de Registros DMARC DNS e Validador de Sintaxe

Gerador de Registros DMARC DNS e Validador de Sintaxe

Gere e valide registros DNS TXT DMARC em conformidade com o RFC 7489, com aplicação de políticas (none/quarantine/reject), relatórios agregados rua/ruf e tags de alinhamento.

Predefinições:
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health ScoreGrau de segurança A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
Estado da políticap=reject (100%)
Feeds de relatórios1 RUA / 0 RUF
Modos de alinhamentoDKIM: Relaxed | SPF: Relaxed

Sintaxe compatível com RFC 7489

Formata instantaneamente tags v=DMARC1 válidas com ordem estrita de tags e validação rigorosa.

Construtor no navegador sem envio

Todo o cálculo de políticas e a execução do analisador ocorrem no cliente com zero telemetria.

Mecanismo de exportação multiplataforma

Gere registros de zona BIND, configurações Cloudflare/Route53, testes dig CLI e autorizações RFC 7489 Seção 7.1.

Referência técnica e guia de arquitetura

Construtor de Registro de Política DMARC DNS e Validador de Sintaxe — Guia de referência

Gere e valide registros DNS TXT DMARC em conformidade com o RFC 7489, com aplicação de políticas (none/quarantine/reject), relatórios agregados rua/ruf e tags de alinhamento.

Parâmetros principais e controles

v (Versão do protocolo)Enum ("DMARC1")

Identifica o registro TXT como uma especificação de política DMARC. Deve ser a primeira tag, escrita em letras maiúsculas e seguida por ponto e vírgula.

Padrão: DMARC1
p (Política do receptor)Enum ("none" | "quarantine" | "reject")

Política de aplicação imposta pelos servidores de destino quando uma mensagem falha em SPF e DKIM. 'none' monitora o tráfego sem bloqueios; 'quarantine' direciona para a pasta de spam; 'reject' recusa o recebimento na camada SMTP.

Padrão: none
sp (Política para subdomínios)Enum ("none" | "quarantine" | "reject")

Sobrescreve a diretiva 'p' especificamente para todos os subdomínios. A definição explícita de 'sp=reject' protege subdomínios inativos contra ataques de falsificação de identidade (spoofing).

Padrão: Herdada (igual a p)
rua (URIs de relatórios agregados)Lista de URIs (mailto:address)

Lista separada por vírgulas de URIs mailto: designadas para receber relatórios diários em XML contendo dados agregados de autenticação, IPs de origem e volume de envios.

Padrão: Nenhum
ruf (URIs de relatórios forenses/falhas)Lista de URIs (mailto:address)

Lista de URIs mailto: para receber notificações forenses imediatas no formato RFC 6591 AFRF quando ocorrerem falhas individuais de validação.

Padrão: Nenhum
pct (Percentual de aplicação da política)Integer (0 - 100)

Percentual de mensagens com falha às quais a política 'p' ou 'sp' é aplicada. Facilita uma transição gradual e segura (ex.: 25% -> 50% -> 100%) antes do bloqueio definitivo.

Padrão: 100
adkim / aspf (Modos de alinhamento)Enum ("r" | "s")

Define o rigor de correspondência de domínio para DKIM e SPF. 'r' (relaxado) aceita correspondência no domínio raiz organizacional (subdomain.example.com com example.com); 's' (estrito) exige FQDN idêntico.

Padrão: r (relaxado)

Dicas profissionais e melhores práticas

Mantenha 'p=none' por 2 a 4 semanas

Mantenha 'p=none' por 2 a 4 semanas para coletar e examinar relatórios XML agregados (rua), identificando serviços legítimos de terceiros (SendGrid, Microsoft 365, Zendesk). Quando mais de 99% dos fluxos válidos estiverem alinhados com SPF e DKIM, suba para 'p=quarantine; pct=25', avance para 100% e, por fim, configure 'p=reject'.

Se o seu domínio for 'example.com' e o

Se o seu domínio for 'example.com' e o destino 'rua' for 'mailto:[email protected]', o RFC 7489 Seção 7.1 exige que o domínio destinatário publique um registro DNS TXT em 'example.com._report._dmarc.thirdparty.com' contendo 'v=DMARC1;'. Sem essa permissão mútua, os servidores descartarão os relatórios para evitar abuso de tráfego.

Muitos criminosos forjam remetentes

Muitos criminosos forjam remetentes usando subdomínios inexistentes (ex.: financeiro.example.com). Ao configurar 'v=DMARC1; p=none; sp=reject; rua=mailto:...', você preserva a entrega dos seus e-mails corporativos principais enquanto bloqueia integralmente o spoofing em qualquer subdomínio.

Sempre que um e-mail é redistribuído

Sempre que um e-mail é redistribuído por listas de discussão ou regras de reenvio automático, o IP do remetente no envelope é alterado, invalidando o SPF. As assinaturas criptográficas DKIM sobrevivem intactas ao transporte, sendo cruciais para evitar rejeições indevidas sob DMARC restrito.

Problemas comuns e solução de problemas

Nenhum relatório agregado rua é recebido de provedores como Google e Microsoft

Verifique se o campo rua contém o prefixo obrigatório 'mailto:' (ex.: 'mailto:[email protected]'). Se estiver enviando para uma ferramenta de monitoramento externa, certifique-se de que o registro TXT de autorização externa foi publicado no domínio destino e se a caixa postal receptora não atingiu o limite de armazenamento.

E-mails de marketing e sistemas transacionais passam a cair na caixa de spam após mudar para quarantine ou reject

Consulte os relatórios XML para identificar desalinhamentos de SPF ou DKIM. Certifique-se de que as plataformas externas assinem as mensagens com chave DKIM própria vinculada ao domínio do cabeçalho From: visível (RFC 5322), e configure os CNAMEs necessários para o Return-Path.

Validadores de DNS indicam 'Registro DMARC inexistente' ou 'Múltiplos registros DMARC encontrados'

O registro TXT do DMARC deve ser configurado exclusivamente no subdomínio '_dmarc.meudominio.com' (jamais no domínio raiz '@'). É estritamente proibido publicar mais de um registro TXT que comece com 'v=DMARC1'; a presença de múltiplos registros anula a política conforme determina o RFC 7489.

Perguntas frequentes (FAQ)

Como SPF, DKIM e DMARC interagem tecnicamente na proteção de e-mails?▼

O SPF (RFC 7208) verifica o endereço IP do servidor remetente em relação ao envelope Return-Path (MAIL FROM). O DKIM (RFC 6376) assina digitalmente cabeçalhos e conteúdo garantindo integridade. O DMARC (RFC 7489) une esses mecanismos ao endereço exibido no campo 'From:' (RFC 5322), exige alinhamento de domínio, define instruções contra fraudes e envia relatórios de telemetria.

É necessário passar simultaneamente em SPF e DKIM para ser aprovado no DMARC?▼

Não. Pelas regras do RFC 7489, uma mensagem obtém aprovação no DMARC se o alinhamento SPF OU o alinhamento DKIM for bem-sucedido. Basta a validação de um dos métodos, embora alinhar ambos seja a melhor prática para proteção contra falhas em trânsito.

Qual a diferença entre os modos de alinhamento relaxado ('r') e estrito ('s')?▼

No modo relaxado ('r', padrão em aspf e adkim), o domínio da assinatura DKIM ou do Return-Path do SPF só precisa pertencer à mesma organização raiz do cabeçalho From: (ex.: envios.example.com alinha com example.com). No modo estrito ('s'), os nomes de domínio FQDN devem ser exatamente idênticos.

Por que listas de e-mails e encaminhamentos quebram a validação DMARC?▼

Serviços de encaminhamento alteram o IP de envio, quebrando o SPF. Listas de discussão frequentemente inserem rodapés ou prefixos no assunto, alterando o corpo e invalidando a assinatura DKIM. Para mitigar esse problema na internet, o protocolo ARC (Authenticated Received Chain, RFC 8617) foi desenvolvido para validar o histórico de autenticação.

Quais são as diferenças fundamentais entre relatórios rua e ruf?▼

Os relatórios rua trazem visões diárias agregadas em formato XML com totais de envios, IPs de origem e status de autenticação, sem expor mensagens. Os relatórios ruf fornecem diagnósticos forenses individuais e em tempo real sobre mensagens com falha. Por questões de privacidade e conformidade com leis como LGPD/GDPR, grandes provedores não geram relatórios ruf.

Ferramentas e utilitários relacionados

Todas as ferramentas →
Gerador de Registros DNS CAA e Validador de PolíticasSegurança

Crie registros DNS CAA em conformidade com a RFC 8659 para restringir a emissão de certificados SSL/TLS exclusivamente a autoridades confiáveis (Let's Encrypt, DigiCert, Sectigo).

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de Registros DNS DKIM TXT e SeletoresSegurança

Gere registros DNS DKIM TXT compatíveis com a RFC 6376 com seletor, formatação de chave pública (v=DKIM1; k=rsa; p=...), divisão de 255 caracteres e validação.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador de Políticas MTA-STS e Registros DNS TLS-RPTSegurança

Documentação técnica completa e boas práticas para geração de arquivos de política RFC 8461 MTA-STS, registros DNS TXT _mta-sts e relatórios RFC 8460 TLS-RPT.

Abrir ferramenta→
Decodificador e Inspetor de Segurança de Tokens JWTSegurança

Utilitário para desenvolvedores para decodificar JSON Web Tokens no navegador, inspecionar claims RFC 7519 e OIDC, auditar prazos de expiração e verificar assinaturas HMAC localmente.

Abrir ferramenta→
Gerador Criptográfico de Senhas e Frases-ChaveSegurança

Gere senhas seguras de alta entropia, frases-passe memoráveis (Diceware), códigos PIN e tokens de API com a Web Crypto API CSPRNG nativa em conformidade com o NIST SP 800-63B.

Abrir ferramenta→
Gerador de Hashes Criptográficos e Verificador de ChecksumSegurança

Calcule instantaneamente hashes SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak e CRC32 localmente no navegador com segurança Web Crypto API 100% privada.

Abrir ferramenta→