Verificador DMARC

Para verificar o registro DMARC de um domínio como o lê um servidor de e-mail de destino, veja onde a política é encontrada, o que acontece com os e-mails que falham, se os relatórios chegam a alguém e o que SPF e DKIM precisam antes de você aplicar a política.

Atualizado em 25 de outubro de 2026

Fontes: os registros TXT _dmarc do domínio e dos domínios acima dele, pelo Google Public DNS (com a Cloudflare 1.1.1.1 por trás) · busca na árvore DNS da RFC 9989 · autorização de relatórios pela RFC 9990 · SPF e DKIM dos nossos próprios verificadores · nada sobre você é armazenado

Como verificar um registro DMARC?

Digite um domínio acima: o verificador pede ao DNS o registro TXT em _dmarc. mais o domínio, sobe até o domínio organizacional quando não há nenhum (RFC 9989 §4.10) e mostra o que um servidor de destino faz com os e-mails que falham.

À mão, peça o mesmo nome: dig +short TXT _dmarc.paypal.com, ou nslookup -type=TXT _dmarc.paypal.com no Windows. Uma resposta que comece com v=DMARC1 é o registro; duas respostas significam que os servidores de destino não usam nenhuma (RFC 9989 §4.10).

O dig para por aí. Ele não sobe a partir de um subdomínio, não confere se os endereços de relatório aceitam os relatórios nem diz qual RFC um servidor de destino segue. É isso que o verificador acrescenta.

% dig +short TXT _dmarc.example.com

Todas as respostas no nome. Uma que comece com v=DMARC1 é o registro.

O que o dig mostra e o que não mostra

terminal

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

1O nome é _dmarc. mais o domínioNão é o próprio domínio: um TXT em paypal.com é o lugar do SPF.
2Um registro, com v=DMARC1 primeiroDois registros no mesmo nome: os servidores de destino descartam os dois (RFC 9989 §4.10).
3Tags, separadas por ;p é a política; rua e ruf dizem para onde vão os relatórios.
4Nada aqui? Suba um nível_dmarc.mail.google.com é NXDOMAIN: vale o registro de google.com.

O registro de paypal.com como o Google Public DNS o devolveu em 24 de outubro de 2026; mail.google.com não tem um próprio.

Lendo o resultado: a visão do servidor de destino

A resposta vem primeiro, em uma frase. Abaixo dela, as provas: o registro como os servidores de destino o leem, cada tag colorida sobre os caracteres exatos e, sobre o azul-marinho, o caminho que um servidor de destino faz para este domínio, terminando no que ele faz com os e-mails que falham.

Sem pontuação: uma política em none é uma fase, não uma falha, e a escada sob o caminho diz o que o próximo passo exige.

Verificação DMARC de paypal.com: rejeita e-mails que falham, com a visão do servidor de destino e a escada de aplicação — Uma verificação DMARC de paypal.com: o veredito, o registro dividido em tags, a visão do servidor de destino com cada consulta DNS e o que acontece com e-mails que falham, e a escada de aplicação. Selecione um número para ver o que cada parte mostra.

Para que serve o DMARC?

O DMARC diz aos servidores de e-mail de destino o que fazer com mensagens que usam o seu domínio na linha From:, mas não provam que vieram de você, e para onde enviar relatórios sobre elas (RFC 9989 §4.7).

A prova é o SPF ou o DKIM, alinhado com o domínio do From:: o SPF passando para um domínio de retorno da mesma organização, ou uma assinatura DKIM com d= do seu domínio. Uma aprovação alinhada basta (RFC 9989 §5.3.5); todo o resto falha no DMARC, e a política do registro decide: entregar, pasta de spam ou rejeitar.

Os relatórios são a outra metade. Os servidores de destino que respeitam rua enviam um resumo diário de cada servidor que enviou como o seu domínio, e é assim que você acha os remetentes legítimos esquecidos antes de aplicar a política.

Duas mensagens, uma linha From:

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

A sua fatura, enviada por um serviço de e-mailpor um serviço configurado com DKIM personalizado, então assina com d=example.com

SPFpass · bounces.esp.example (não alinhado)
DKIMpass · d=example.com (alinhado)
DMARCpass: um resultado alinhado basta

Entregue

Uma fatura falsificada de 203.0.113.9um servidor que example.com nunca autorizou

SPFfail · 203.0.113.9 não está na lista
DKIMnone · sem assinatura
DMARCfail → p=reject

Rejeitado

550 5.7.1 Email rejected per DMARC policy for example.com

O relatório agregado de amanhã para dmarc@example.com: 1 mensagem de 203.0.113.9, SPF fail, DKIM none, disposição reject.

Passar não promete entrega (os filtros do servidor de destino ainda decidem), e uma falha em p=reject é um pedido, não uma ordem (RFC 9989 §5.4, §7.4). Endereços da RFC 5737; o texto da resposta é o exemplo da própria RFC 9989.

Tags do registro DMARC explicadas

Um registro DMARC é uma lista de pares tag=valor em um registro TXT em _dmarc. mais o domínio: v=DMARC1 primeiro e, depois, as tags de política, alinhamento e relatórios em qualquer ordem (RFC 9989 §4.7).

A RFC 9989 (maio de 2026) substituiu a RFC 7489. Ela acrescentou np, psd e t e removeu pct, rf e ri: os servidores de destino atuais os ignoram, enquanto os que ainda seguem a RFC 7489 os leem, então um registro com pct=25 significa coisas diferentes para servidores diferentes.

As tags que você não publica assumem os padrões, e o verificador mostra isso também: um sp ausente significa que os subdomínios recebem p.

Todas as tags, pelo que fazem

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

VersãoPolíticaTeste e sufixoAlinhamentoRelatóriosRemovida

Tag	O que define	Padrão	Situação	Vista em
v	VersãoDMARC1	obrigatória, primeira	RFC 9989	192
p	Política do domínionone · quarantine · reject	none se faltar e rua for válido	RFC 9989	192
sp	Política dos subdomínios existentesnone · quarantine · reject	p	RFC 9989	39
np	Política dos nomes que não existemnone · quarantine · reject	sp e, depois, p	nova na RFC 9989	2
t	Modo de teste: um nível abaixo da políticay · n	n	nova na RFC 9989	0
psd	Sufixo público (y) ou domínio organizacional (n)y · n · u	u	nova na RFC 9989	1
adkim	Alinhamento do DKIMr · s	r	RFC 9989	20
aspf	Alinhamento do SPFr · s	r	RFC 9989	24
rua	Para onde vão os relatórios agregadosmailto:…	sem relatórios	RFC 9989	186
ruf	Para onde vão os relatórios de falhamailto:…	sem relatórios	RFC 9989	120
fo	Quando enviar relatórios de falha0 · 1 · d · s	0	RFC 9989	96
pct	Parte dos e-mails que falham à qual a política se aplica0–100	–	removida	70
rf	Formato do relatório de falhaafrf	–	removida	9
ri	Intervalo do relatório, em segundos86400	–	removida	14

Vista em: quantos dos 192 registros DMARC publicados por 196 domínios conhecidos têm a tag (lidos em 24 de outubro de 2026; 69 das 70 tags pct dizem pct=100). Padrões e situação da RFC 9989 §4.7 e do Apêndice C.

Política DMARC: p=none, quarantine ou reject

p=none pede aos servidores de destino que entreguem os e-mails que falham como de costume e só os reportem; quarantine pede que os tratem como suspeitos, em geral na pasta de spam; reject pede que os recusem durante a conversa SMTP.

None é uma fase, não uma falha: a RFC 9989 §7.4 sugere pelo menos um mês nela com os relatórios chegando, e mais o mesmo tempo em quarantine, antes de reject. Domínios cujas pessoas escrevem em listas de e-mail devem parar em quarantine.

Os grandes provedores de caixa de e-mail também dividem: gmail.com e outlook.com publicam p=none para o próprio domínio e sp=quarantine para os subdomínios, enquanto google.com, yahoo.com e microsoft.com publicam reject.

Onde uma mensagem falsificada vai parar

Entreguep=none

apache.orggmail.comsamsung.com

23 de 192

Pasta de spamp=quarantine

github.comapple.comamazon.com

30 de 192

Rejeitadop=reject

google.compaypal.commicrosoft.com

139 de 192

Os servidores de destino decidem no fim: podem entregar e-mails que falham em p=reject, e não devem rejeitar só pela política (RFC 9989 §5.4, §7.4). Um estudo de um fornecedor mostra o quanto o resto da web está atrasado: entre os 1,8 milhão de domínios mais importantes, no início de 2026, a EasyDMARC encontrou 29,2% em p=none e 22,9% em quarantine ou reject.

O DMARC é mesmo necessário?

Sim, se você envia em massa para Gmail, Yahoo ou Outlook.com: os três exigem um registro DMARC, e p=none basta para cumprir a regra. A aplicação (quarantine ou reject) é o que impede que outras pessoas enviem como o seu domínio, e os logotipos BIMI a exigem.

O Gmail exige o registro desde 1 de fevereiro de 2024 de quem envia mais de 5.000 mensagens por dia para contas do Gmail; o Yahoo desde fevereiro de 2024, sem citar volume; o Outlook.com desde 5 de maio de 2025, acima de 5.000 por dia. Sem registro, o Gmail responde 4.7.31 (e 4.7.32 quando o From: não está alinhado) e o Outlook.com rejeita com 550 5.7.515.

Para um domínio que não envia nada, o DMARC é a proteção mais barata que existe: p=reject, um MX nulo e v=spf1 -all, como o example.com publica (M3AAWG).

O que cada provedor de caixa de e-mail pede de quem envia em massa

Gmail1 de fev. de 20245.000+ por dia para contas do Gmail4.7.31 · 4.7.32

Yahoofev. de 2024nenhum limite publicadoo DMARC precisa passar

Outlook.com5 de mai. de 20255.000+ por dia550 5.7.515

Entreguep=nonecumpre a regra dos três provedores

Pasta de spamquarantinebarra a maior parte das falsificações · logotipos BIMI possíveis

Rejeitadorejectbarra as falsificações na porta · BIMI

✓Exigido: um registro, p=none ou mais rígidoiProteção: quarantine ou reject

Das páginas de remetentes de cada provedor, lidas em 24 de outubro de 2026. Uma taxa de spam abaixo de 0,3% e o cancelamento de inscrição em um clique também são regras, mas o DNS não as mostra; a visão Requisitos do verificador diz quais partes ele consegue provar.

Como corrigir falhas de DMARC: encaminhamento, listas de e-mail, o domínio do fornecedor

Ache a origem que falha nos seus relatórios agregados e corrija-a no remetente: assine-a com DKIM do seu próprio domínio ou passe-a para um domínio de retorno dentro da sua organização. Três causas cobrem a maioria das falhas.

O encaminhamento mantém a assinatura DKIM, mas quebra o SPF, então o DKIM garante a aprovação. As listas de e-mail que editam a mensagem quebram os dois. E um serviço de e-mail que assina com o próprio domínio passa no DKIM para ele mesmo, não para você: ative o DKIM personalizado dele (em geral CNAMEs como s1._domainkey) e um domínio de retorno personalizado.

Três falhas, o que o relatório mostra e a correção

Encaminhamento

SPF192.0.2.80 não está no SPF de example.com
DKIMassinatura intacta

O relatório mostraspf=fail dkim=pass → pass

Assine tudo com DKIM; o DKIM sobrevive ao encaminhamento. O ARC (RFC 8617) ajuda os encaminhadores a atestar.

Lista de e-mail

SPFenvia o servidor da lista
DKIMcorpo alterado: o hash falha

O relatório mostraspf=fail dkim=fail → fail

As listas que reescrevem o From: resolvem isso; domínios cujas pessoas escrevem em listas ficam em quarantine (RFC 9989 §7.4).

O domínio de um fornecedor

SPFpass para bounces.esp.example: não alinhado
DKIMpass para esp.example: não alinhado

O relatório mostradkim=pass(esp.example) → fail

Ative o DKIM personalizado do fornecedor: s1 e s2 de paypal.com são CNAMEs para o SendGrid, que assina como paypal.com.

Endereços da RFC 5737; esp.example é um espaço reservado. Os CNAMEs do SendGrid são os seletores reais de paypal.com (24 de outubro de 2026).

DMARC para subdomínios: sp e np

Um subdomínio sem registro próprio recebe a política do domínio organizacional: sp para subdomínios que existem, np para nomes que não existem, cada um recorrendo a p (RFC 9989 §4.7).

Um subdomínio que publica o próprio registro o usa para si. Mas um registro entre um nome e o seu domínio organizacional nunca é usado para esse nome: a árvore de berkeley.edu mostra isso, onde o sp=none de eecs.berkeley.edu não chega a www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np é o ganho fácil: nomes que não existem não enviam e-mail de verdade, então np=reject bloqueia falsificações vindas deles mesmo com p ainda em none. Os servidores da RFC 7489 não conhecem np e usam sp.

A árvore de berkeley.edu, como um servidor de destino a lê

berkeley.edup=reject; np=reject; psd=n; rua=…registro próprio · psd=n: o domínio organizacionalRejeitado

www.berkeley.edusem registroexiste → sp, ausente → pRejeitado

eecs.berkeley.edup=reject; sp=none; rua=…registro próprio → pRejeitado

www.eecs.berkeley.edusem registrobusca: o registro de eecs.berkeley.edu é pulado (não é o domínio organizacional) → o p de berkeley.eduRejeitado

nosuch-x7.berkeley.eduNXDOMAINnão existe → npRejeitado

O sp=none de eecs.berkeley.edu nunca é aplicado: um registro entre um nome e o seu domínio organizacional não é usado para ele (RFC 9989 §4.10.1). O verificador o sinaliza como um registro que não é usado.

Lido em 24 de outubro de 2026 pelo Google Public DNS. nosuch-x7.berkeley.edu é um nome inventado; o NXDOMAIN dele é real.

Lendo os relatórios DMARC (rua)

Um relatório agregado é um arquivo XML diário de cada servidor de destino que lista todos os servidores que enviaram e-mail como o seu domínio, quantas mensagens e se SPF, DKIM e DMARC passaram (RFC 9990).

Leia por origem: os seus servidores e serviços devem mostrar uma aprovação alinhada; um serviço conhecido que falha precisa do DKIM personalizado; um endereço desconhecido que falha em p=reject é falsificação, barrada. Um serviço de relatórios (dmarcian, Valimail, EasyDMARC, Postmark e outros) transforma milhares de arquivos nessa lista.

Relatórios para um endereço em outro domínio só chegam se esse domínio concordar: ele publica yourdomain._report._dmarc.its-host com v=DMARC1 (RFC 9990 §4). O verificador pergunta por você e dá o registro exato quando ele falta.

Um relatório, lido linha a linha

<org_name>google.com</org_name>1

<date_range>23 de out., 00:00 UTC – 24 de out., 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

1Quem reportouUm arquivo por servidor de destino por dia (RFC 9990: pelo menos a cada 24 horas).
2A política que ele achouO que leu em _dmarc.example.com.
3E-mail encaminhado, salvo pelo DKIMO SPF falhou no encaminhador; a assinatura alinhada passou no DMARC.
4Falsificação, barradaUm servidor desconhecido, nada alinhado, recusado.

paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autorizado: os relatórios fluem

Serviços de relatórios que o verificador reconhecedmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 mais

O XML está resumido e inventado (endereços de documentação, RFC 5737); o registro de autorização é o real de paypal.com, lido em 24 de outubro de 2026.

Verificador DMARC: perguntas frequentes

O que é DMARC?

O DMARC é um registro DNS que diz aos servidores de e-mail de destino o que fazer com mensagens que usam o seu domínio na linha From:, mas falham no alinhamento de SPF e DKIM: entregar, colocar em quarentena ou rejeitar. Ele também indica para onde enviar relatórios sobre essas mensagens. É publicado como um registro TXT em _dmarc mais o seu domínio e definido pela RFC 9989, que substituiu a RFC 7489 em maio de 2026.

O que mostra um verificador de registro DMARC?

Ele lê o registro TXT em _dmarc mais o domínio, e o dos domínios acima quando não há nenhum, como faz um servidor de destino. Este mostra o registro tag por tag com os padrões, a política do domínio, dos subdomínios e dos nomes que não existem, se os endereços de relatório aceitam os relatórios, e o registro SPF e as chaves DKIM do domínio, sem dar pontuação.

Como testar o DMARC?

Verifique o domínio acima para ver a política publicada: esse é o teste de DMARC que o DNS consegue responder. Para ver se uma mensagem real passa, envie uma para uma caixa que você controla e leia o cabeçalho Authentication-Results, ou cole os cabeçalhos no Analisador de Cabeçalho de E-mail. Um validador DMARC confere a sintaxe do registro; só uma mensagem mostra se SPF ou DKIM ficaram alinhados.

Com qual política DMARC devo começar?

Comece com p=none e um endereço rua, para que os servidores de destino enviem relatórios diários sem mudar a entrega. Corrija cada remetente legítimo que falhar, em geral ativando o DKIM personalizado dele, e depois passe para quarantine e, por fim, reject. A RFC 9989 sugere pelo menos um mês em p=none e mais o mesmo tempo em quarantine. Um domínio que não envia e-mail pode ir direto para p=reject.

O p=none protege o meu domínio?

Não. p=none pede aos servidores de destino que tratem os e-mails que falham como de costume, então uma mensagem falsificada é julgada só pelos filtros de spam deles. O que ele dá são relatórios, e cumpre a regra de envio em massa do Gmail, do Yahoo e do Outlook.com. Trate-o como uma fase de monitoramento: a proteção começa em quarantine, e reject barra o e-mail falsificado antes de chegar a alguém.

O que significa t=y em um registro DMARC?

t=y é o modo de teste da RFC 9989: os servidores de destino aplicam um nível abaixo da política publicada, então p=reject age como quarantine e p=quarantine como none. Não tem efeito em p=none e não muda os relatórios. Os servidores que ainda seguem a RFC 7489 não conhecem a tag e aplicam a política como está escrita. Remova t=y quando os relatórios mostrarem todos os remetentes legítimos alinhados.

A tag pct ainda é usada?

A RFC 9989 removeu pct, junto com rf e ri, porque valores diferentes de 0 e 100 eram aplicados de forma inconsistente. Os servidores atuais a ignoram e aplicam a política a todos os e-mails que falham. Os que ainda seguem a RFC 7489 fazem amostragem: pct=25 em quarantine manda um quarto dos e-mails que falham para o spam e entrega o resto. pct=100 é inofensivo; para uma fase de teste, use t=y.

Por que o meu endereço rua está "não autorizado"?

Quando os relatórios vão para uma caixa de outro domínio organizacional, esse domínio precisa concordar publicando um registro TXT chamado yourdomain._report._dmarc.its-host com o valor v=DMARC1 (RFC 9990 §4). Sem ele, os servidores de destino que verificam ignoram o endereço. O registro vai no DNS do destino, não no seu: os serviços de relatórios publicam um curinga para todos os clientes, então em geral é erro de digitação ou a caixa de um parceiro.

Os subdomínios precisam do próprio registro DMARC?

Em geral, não. Um subdomínio sem registro recebe a política do domínio organizacional: sp para subdomínios que existem, np para nomes que não existem, ambos recorrendo a p. Publique um em um subdomínio só quando ele precisar de uma política diferente. Um registro em um nome intermediário, como team.example.com para www.team.example.com, não é usado para o nome mais fundo.

O que acontece se um domínio publica dois registros DMARC?

Os servidores de destino descartam os dois, então nenhuma política DMARC vale e nenhum relatório é enviado, mesmo que um dos dois diga reject (RFC 9989 §4.10). Em geral acontece quando se adiciona um registro novo sem apagar o antigo, ou quando a hospedagem do DNS cria um padrão. Mantenha um só registro em _dmarc e apague o outro; o verificador mostra qual parece ser o pretendido.

Por que o DMARC falha quando o SPF passa?

O DMARC precisa que o SPF passe para um domínio alinhado com o endereço do From:. A maioria dos serviços de e-mail envia com o próprio domínio de retorno, então o SPF passa para eles, não para você, e isso não conta. O mesmo vale para o DKIM assinado com o domínio do serviço. Configure o DKIM personalizado ou o domínio de retorno personalizado do serviço para que o domínio aprovado seja o seu.

O verificador não mostra registro, mas acabei de adicionar um. Por quê?

Confira primeiro o campo host: a maioria dos painéis de DNS quer só _dmarc, e digitar _dmarc.example.com ali cria _dmarc.example.com.example.com. Depois espere a resposta antiga expirar: se o nome já foi consultado, os resolvedores guardam o NXDOMAIN pelo TTL negativo da zona, em geral de 5 minutos a uma hora. Um SERVFAIL ou tempo esgotado aparece como "não foi possível verificar", nunca como sem registro.