Verifique um registro DMARC e leia a política, o alinhamento e os endereços de relatório em palavras simples
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Um verificador de DMARC lê o registro TXT em _dmarc seguido de um domínio e diz o que os receptores fazem com o e-mail que falha no SPF e no DKIM. As 3 políticas são none, quarantine e reject; só as 2 últimas barram e-mail falsificado. Endereços de relatório em outro domínio precisam de um registro de permissão lá.
Esta página foi traduzida automaticamente do original em inglês. Nenhuma pessoa revisou ainda a tradução; a versão em inglês é a que deve ser considerada. Ler o original em inglês
Digite o domínio no campo Domínio e toque em Verificar DMARC.
Leia o título: ele informa a política aplicada ao e-mail que falha para esse domínio.
Leia O que este registro diz para ver a política, o alinhamento e os endereços de relatório em palavras simples.
Confira nos achados os endereços de relatório em outro domínio que não aceitaram receber relatórios.
Toque em Copiar ao lado do registro para copiá-lo.
Digite um domínio e a página pede a um resolvedor público de DNS sobre HTTPS o registro TXT em _dmarc. seguido desse nome. O registro é lido tag por tag e depois explicado em frases: o que acontece com o e-mail que falha, o que vale para os subdomínios, com que rigor o SPF e o DKIM precisam bater com o endereço From e para onde vão os relatórios.
As regras vêm da RFC 9989, publicada em maio de 2026, que substituiu a RFC 7489 como padrão do DMARC. Duas mudanças importam ao ler registros antigos. A tag pct foi removida: receptores antigos ainda a usam para agir só sobre parte do e-mail que falha, os novos a ignoram. Uma tag t=y agora significa modo de teste, em que os receptores aplicam um passo a menos que a política. As duas são sinalizadas em palavras.
Quando um subdomínio não tem registro próprio, os receptores procuram o registro do domínio organizacional. Esta página faz isso com a busca na árvore de DNS que a seção 4.10 da RFC 9989 define, consultando _dmarc em cada nome mais curto, no máximo 8, e mostra cada nome consultado. Nenhuma lista de sufixos públicos é usada, então nada depende de uma cópia dessa lista estar atualizada.
Os endereços de relatório em outro domínio têm a permissão verificada. A seção 4 da RFC 9990 pede aos receptores que só enviem relatórios para outro domínio quando esse domínio publica um registro TXT no domínio da política seguido de ._report._dmarc. e do host que recebe os relatórios. A falta dele é o motivo mais comum para um serviço de DMARC não receber nada.
A aba do gerador escreve um registro a partir das suas escolhas e informa o host em que publicá-lo. Ela deixa de fora as tags iguais ao padrão e não escreve pct.
O que ela não faz: ela lê o registro, não o seu e-mail, então não sabe dizer se as suas mensagens passam. Isso os relatórios diários informam.
O domínio que você digita é enviado ao resolvedor que você escolher, porque a consulta precisa dele. Nada mais sai do seu dispositivo.
Uma política p=none pede aos receptores que entreguem normalmente o e-mail que falha no DMARC e só enviem relatórios. E-mail falsificado usando o domínio continua chegando às caixas de entrada. Os donos a usam por algumas semanas para achar nos relatórios todos os remetentes legítimos, e depois passam para quarantine e por fim reject.
Não necessariamente. Quando um subdomínio como mail.example.com não tem registro, os receptores usam o registro do domínio organizacional, example.com, aplicando a política sp= dele se houver e p= caso contrário. Um subdomínio pode publicar o próprio registro para mudar isso.
Três causas comuns: o registro não tem endereço rua=; o endereço está em outro domínio que não publicou o registro de permissão em seudominio._report._dmarc.dominiodeles; ou o próprio registro é inválido, por exemplo dois registros DMARC no mesmo nome, que os receptores descartam. Este verificador testa as três.
A RFC 9989, que substituiu a RFC 7489 em maio de 2026, removeu a tag pct. Receptores que seguem o novo padrão a ignoram e aplicam a política a todo o e-mail que falha; os antigos ainda a respeitam. A nova tag t=y é a substituta para testar com cuidado uma política mais rígida.
Quarantine pede ao receptor que trate o e-mail que falha como suspeito, o que na prática significa a pasta de spam ou lixo eletrônico. Reject pede ao receptor que recuse a mensagem durante a entrega, então ela nunca chega ao destinatário. As duas contam como aplicação da política; reject é a proteção mais forte contra e-mail falsificado.
Só para o resolvedor de DNS público que você escolher, Cloudflare ou Google, porque consultar um registro DNS precisa do nome. O resolvedor vê os nomes consultados e o seu endereço IP. Nada mais sai do seu dispositivo, e a aba do gerador não envia nada.
Ainda com dúvidas? Pergunte sobre Verificador de DMARC e qualquer pessoa que saiba pode responder. Não é preciso ter conta.