Verificador de Registro DMARC Grátis

O que é DMARC e por que isso importa em 2026

DMARC — Domain-based Message Authentication, Reporting & Conformance — é a camada de política que une SPF e DKIM. SPF informa aos servidores receptores quais IPs estão autorizados a enviar e-mail pelo seu domínio. DKIM assina criptograficamente cada mensagem para que os destinatários possam verificar que ela não foi adulterada. DMARC é o manual de instruções: ele diz ao Gmail, Outlook, Yahoo e a qualquer outro provedor de caixa de entrada o que fazer quando uma mensagem que diz vir do seu domínio falha em uma ou nas duas verificações. Sem DMARC, atacantes podem falsificar seu endereço From e usar sua reputação para chegar direto na caixa de entrada dos seus clientes.

Em 2026 isso não é mais opcional. Desde fevereiro de 2024 — e com regras cada vez mais rígidas em 2025 e 2026 — Gmail e Yahoo exigem que qualquer remetente que envie mais de 5.000 mensagens por dia tenha um registro DMARC válido. O Microsoft 365 seguiu o mesmo caminho com sua própria aplicação de regras para remetentes de alto volume. Domínios sem DMARC veem e-mails em massa rejeitados ou roteados direto para spam, e taxas de phishing por personificação de marca praticamente dobram quando o DMARC está ausente.

Anatomia de um registro DMARC

Um registro DMARC é um único registro TXT publicado em _dmarc.seudominio.com. É uma lista de tags separadas por ponto e vírgula. Veja um registro típico e o que cada parte faz:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r;

• v=DMARC1 — Tag de versão obrigatória. Deve ser exatamente DMARC1 (sensível a maiúsculas) ou o registro inteiro é ignorado.
• p= — A política em si. p=none significa apenas monitorar — falhas continuam sendo entregues. p=quarantine envia e-mails que falham para o spam. p=reject bloqueia diretamente na borda SMTP.
• rua= — Caixa de relatórios agregados. Receptores enviam relatórios XML diários aqui resumindo quais IPs enviaram e-mail usando seu domínio e quantas mensagens passaram ou falharam. Formato: rua=mailto:dmarc-reports@seudominio.com.
• ruf= — Caixa de relatórios forenses (de falha). Amostras por mensagem com cabeçalhos e às vezes corpo censurado. A maioria dos provedores não envia mais por questões de privacidade, então rua é muito mais útil na prática.
• pct= — Porcentagem de e-mails com falha em que aplicar a política (1–100). Permite implantação por etapas: pct=25 com p=quarantine coloca em quarentena 25% das falhas e deixa 75% serem entregues.
• aspf= / adkim= — Modo de alinhamento. aspf=s/r e adkim=s/r controlam se o casamento de domínio SPF/DKIM é estrito (correspondência exata) ou relaxado (subdomínio permitido). O padrão é relaxado, que é o que quase todo mundo quer.

5 erros DMARC comuns e como corrigi-los

Erro: nenhum registro DMARC encontrado

O modo de falha mais comum. Rode dig TXT _dmarc.seudominio.com — se não retornar nada, o registro está ausente. Verifique três coisas: (1) você publicou o registro TXT em _dmarc como subdomínio, não no domínio raiz; (2) o campo host é exatamente _dmarc com underscore inicial (algumas UIs de DNS removem); (3) você esperou a propagação. O TTL costuma ser 300–3600 segundos, mas Cloudflare e Route53 normalmente ficam ativos em menos de um minuto. Evite _DMARC em maiúsculas — labels DNS não diferenciam caixa, mas alguns validadores são rigorosos.

Erro: múltiplos registros DMARC

Se houver dois ou mais registros TXT em _dmarc, a RFC 7489 exige que receptores ignorem todos — seu domínio fica sem política. Isso costuma acontecer quando uma ferramenta de marketing ou um script de migração publica um segundo registro sem remover o primeiro. Rode dig +short TXT _dmarc.seudominio.com — se aparecer mais de uma linha v=DMARC1, exclua a mais antiga ou mais fraca. Consolide tudo em um único registro com todas as tags que você precisa (p, rua, ruf, pct, aspf, adkim).

Erro: sintaxe inválida

Os parsers DMARC são rigorosos. Os cinco erros de sintaxe mais comuns: (1) falta ponto e vírgula entre tags — todo par de tag deve terminar com ;; (2) usar = em URIs mailto sem codificação adequada; (3) usar aspas inteligentes copiadas de um documento Word em vez de aspas ASCII retas; (4) erros de digitação como p=quarentine ou p=rejct; (5) envolver o registro inteiro em aspas extras quando a UI de DNS já adiciona. Valide com nosso checker acima — ele faz parse tag por tag e diz exatamente qual token falhou.

Erro: falhas de alinhamento SPF/DKIM

DMARC só passa quando SPF ou DKIM autenticam E alinham com o domínio From. Pegadinha comum: seu ESP (ex.: Mailchimp) autentica com seu próprio return-path como bounces.mcsv.net, então SPF passa mas não alinha com seudominio.com. Resolva ativando assinatura DKIM com seu domínio no ESP — alinhamento DKIM é mais fácil que alinhamento SPF porque a tag d= na assinatura DKIM pode bater com seu domínio raiz. Para subdomínios, defina aspf=r e adkim=r (relaxado, padrão) para que e-mails de subdomínio alinhem com a raiz.

Passo a passo de configuração DMARC em 5 etapas

1. Audite a autenticação atual — Antes de publicar DMARC, conserte SPF e DKIM. Rode nosso SPF Checker e DKIM Checker em todos os domínios e subdomínios remetentes. Confirme que o SPF está abaixo do limite de 10 lookups DNS e termina em -all ou ~all. Confirme que o DKIM está assinando com chave de 2048 bits e alinhado com seu domínio From.
2. Publique um registro de monitoramento (p=none) — Adicione este registro TXT no host _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; pct=100; aspf=r; adkim=r. p=none significa nenhum impacto no fluxo de e-mail — receptores começarão a te enviar relatórios agregados sem colocar em quarentena ou rejeitar nada. Esta é sua fase de coleta de dados. Use uma caixa dedicada ou uma ferramenta analisadora de DMARC, porque XML bruto é ilegível em escala.
3. Colete relatórios agregados — Em até 24 horas você deve começar a receber relatórios XML diários dos principais receptores. Faça parse para identificar todo IP e plataforma enviando e-mail como seu domínio. Remetentes esperados (Google Workspace, Mailchimp, SendGrid) devem passar. Inesperados são shadow IT ou spoofers — investigue antes de apertar a política.
4. Mude para quarantine com pct=25 — Quando 95%+ do e-mail legítimo estiver passando SPF e DKIM com alinhamento, aperte para v=DMARC1; p=quarantine; pct=25; rua=...;. Agora 25% do e-mail que falha vai para spam. Acompanhe relatórios e tickets de suporte para falsos positivos. Após duas semanas limpas, suba pct para 50, depois 100.
5. Chegue ao p=reject — Estado final: v=DMARC1; p=reject; rua=mailto:dmarc@seudominio.com; pct=100;. E-mails com falha são rejeitados na borda SMTP — phishers não conseguem mais falsificar seu domínio. Esta é a única configuração que protege totalmente sua marca. A maioria dos domínios chega ao reject em 8 semanas a partir do p=none.

Fases de implantação DMARC (4 a 8 semanas)

Uma implantação DMARC segura segue uma rampa baseada em porcentagem para você pegar configurações erradas antes que elas atrapalhem a entregabilidade. O cronograma viável mínimo é de quatro semanas; oito é mais seguro para organizações com muitas plataformas de envio.

• Semana 1-2: Monitorar (p=none) — Publique p=none com relatório rua=. Colete relatórios agregados, identifique todo remetente legítimo e conserte gaps de SPF/DKIM. Espere descobrir pelo menos um ESP shadow que ninguém avisou para a TI.
• Semana 3-4: Quarantine pct=25 — Mude para p=quarantine; pct=25. Um quarto do e-mail não autenticado agora cai no spam. Monitore os relatórios diariamente para quedas inesperadas em e-mails legítimos. Se um remetente quebrar, volte para p=none, conserte e tente de novo.
• Semana 5-6: Quarantine pct=100 — Suba para p=quarantine; pct=100. Todo e-mail que falha vai para spam. Nesse ponto seus relatórios devem mostrar 99%+ de aprovação dos remetentes conhecidos. E-mails falsificados tentando usar seu domínio agora são neutralizados na caixa de entrada do destinatário.
• Semana 7-8: Reject — Vá para p=reject; pct=100. E-mails com falha são rejeitados na transação SMTP — nunca chegam ao destinatário. Este é o estado de destino. Mantenha o relatório ligado (rua=) para você detectar regressões quando um novo ESP for adicionado.

Requisitos do Gmail e Yahoo em 2026

Se você envia mais de 5.000 mensagens por dia para endereços do Gmail ou Yahoo, DMARC é obrigatório. O registro mínimo aceitável é p=none — mas o próprio guia do Google agora recomenda p=quarantine ou mais forte. Sem um registro DMARC válido, remetentes em massa veem mensagens rejeitadas com 5.7.26 'unauthenticated email is not accepted' ou roteadas direto para spam, independentemente do conteúdo. Os outros requisitos de 2026 se acumulam em cima: cabeçalho de unsubscribe em um clique, taxa de reclamação de spam abaixo de 0,3% e TLS para SMTP. DMARC é o mais barato de implementar — normalmente um único registro TXT e 30 minutos de trabalho — e é a maior alavanca de entregabilidade para e-mails transacionais e de marketing.