Verificador de DMARC
Consulte o registo DMARC de um domínio e veja a política, a política de subdomínios, o endereço de relatórios e o que corrigir. A mesma análise classifica o SPF, o DKIM e o resto da segurança de e-mail do domínio.
Começar a verificação
- Verificação baseada em DNS
- Análise Não Intrusiva
O que é um registo DMARC?
Um registo DMARC é um registo DNS TXT em _dmarc seguido do seu domínio, que começa por v=DMARC1. Indica aos servidores recetores o que fazer com o e-mail cujo domínio From não é validado por um resultado pass alinhado de SPF ou DKIM, e para onde enviar relatórios. A sua etiqueta de política, p, é none (apenas monitorização), quarantine ou reject.
Este verificador de DMARC lê o registo do domínio. Se não existir, consulta o registo do domínio organizacional, tal como fazem os servidores recetores, e indica quando a política é herdada. Depois, executa a análise completa de segurança de e-mail para o SPF, o DKIM e os restantes registos.
O DMARC foi definido no RFC 7489. Em maio de 2026, o RFC 9989 substituiu-o como especificação Standards Track, acrescentando as etiquetas np e t e tornando pct histórica. O verificador lê as etiquetas do RFC 7489.
Como a verificação DMARC pontua o registo
O registo começa com 100 e perde pontos por cada fragilidade. 80 ou mais é bom, 50 a 79 é um aviso e abaixo de 50 é mau. O DMARC vale 25 dos 100 pontos da classificação global de segurança de e-mail, mais do que qualquer outro registo.
p=reject- Pontuação máxima.
p=quarantine- Retira 10 pontos.
p=none- Retira 40 pontos: os servidores recetores não tomam qualquer ação sobre o e-mail com falha.
- pct inferior a 100
- Retira 15 pontos: apenas parte do e-mail com falha fica sujeita à política.
- Sem rua
- Retira 10 pontos: não são pedidos relatórios agregados.
- sp=none com um p mais restritivo
- Retira 5 pontos: os subdomínios ficam menos protegidos do que o domínio.
- Registo herdado
- Pontuado a partir do sp do domínio organizacional, ou de p sem sp: reject 100, quarantine 75 e none 50, menos 15 quando pct é inferior a 100.
Problemas comuns de DMARC e como corrigi-los
Estes são os problemas que este verificador deteta, com a alteração que corrige cada um.
Sem registo DMARC
Sem DMARC, os servidores recetores aplicam as suas próprias regras ao e-mail que falha o SPF e o DKIM, e não recebe relatórios sobre quem envia e-mail em nome do seu domínio.
Correção: Publique um registo TXT em _dmarc para o domínio, começando em modo de monitorização com um endereço para relatórios agregados.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
p=none que nunca avança
p=none pede aos servidores recetores que não tomem qualquer ação, pelo que o e-mail falsificado continua a ser entregue. É uma fase para recolher relatórios, não uma proteção.
Correção: Use os relatórios agregados para corrigir o SPF e o DKIM de todos os remetentes legítimos e, depois, passe para p=quarantine e, mais tarde, para p=reject. Para domínios cujos utilizadores enviam mensagens para listas de correio, o RFC 9989 sugere pelo menos um mês em p=none e igual período em p=quarantine antes de p=reject.
Sem endereço de relatórios rua
Sem rua, os servidores recetores não enviam relatórios agregados (RFC 7489, secção 6.3), pelo que não consegue ver que serviços falham antes de aplicar uma política.
Correção: Adicione rua=mailto: com uma caixa de correio que consulte ou com o endereço de um serviço de relatórios DMARC. Uma caixa de correio noutro domínio organizacional tem de autorizar primeiro o seu domínio (RFC 7489, secção 7.1).
pct inferior a 100
pct aplica a política apenas a parte do e-mail com falha. O RFC 9989 tornou pct histórica porque os servidores recetores aplicavam de forma inconsistente valores diferentes de 0 e 100.
Correção: Remova pct, para que a política se aplique a todo o e-mail com falha, ou use t=y enquanto testa uma política mais restritiva.
Política de subdomínios mais fraca
sp=none com p=quarantine ou p=reject deixa os subdomínios expostos à falsificação, incluindo subdomínios que nunca usa para e-mail.
Correção: Remova sp para que os subdomínios sigam p, ou defina-o com o mesmo nível.
Etiquetas DMARC
As etiquetas são separadas por ponto e vírgula. As etiquetas que um servidor recetor não reconhece são ignoradas.
v=DMARC1- A versão. Tem de ser a primeira etiqueta.
p=- A política para o e-mail que falha o DMARC: none, quarantine ou reject.
sp=- A política para subdomínios. Sem ela, os subdomínios seguem p.
rua=- Para onde são enviados os relatórios agregados, como endereços mailto: separados por vírgulas.
ruf=- Para onde são enviados os relatórios de falhas sobre mensagens individuais. Muitos grandes fornecedores de caixas de correio não os enviam.
adkim= / aspf=- Alinhamento DKIM e SPF: r (flexível, a predefinição) aceita um subdomínio do domínio From, s (estrito) exige uma correspondência exata.
fo=- Que falhas originam relatórios de falhas: 0, 1, d ou s. Ignorado sem ruf.
pct=- A percentagem de e-mail com falha a que a política se aplica, 100 por predefinição. O RFC 9989 tornou-a histórica.
np= / t=- Adicionados pelo RFC 9989: uma política para subdomínios inexistentes e t=y para testar uma política sem a aplicar na totalidade.
Exemplo de registo
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
Fontes
Mais ferramentas de autenticação de e-mail
- Verificador de SPFConsulte o registo SPF de um domínio e o respetivo número de consultas DNS.
- Verificador de DKIMEncontre chaves públicas DKIM em seletores comuns.
- Verificador de BIMIVerifique um registo BIMI e o respetivo requisito DMARC.
- Verificador de MTA-STSVerifique a política MTA-STS, o respetivo modo e o TLS-RPT.
- Gerador de registos SPFCrie um registo SPF e conte as respetivas consultas DNS.
- Gerador de registos DMARCCrie um registo DMARC com as etiquetas certas.
- Analisador de segurança de e-mailClassifique todos os registos de autenticação de e-mail de uma só vez.
Para além dos registos DNS
Estes registos impedem que terceiros enviem e-mail em nome do seu domínio exato. Não impedem o phishing a partir de domínios semelhantes nem de contas comprometidas, que enviam e-mail autenticado. O Vigilbase OS liga as ferramentas de segurança que já paga, incluindo Microsoft 365, Google Workspace, Proofpoint e Mimecast. O agente Vigil investiga incidentes de alta severidade e os analistas da Vigilbase tratam das exceções.
Perguntas
Perguntas frequentes sobre o verificador de DMARC
O que faz um verificador de DMARC?
Consulta o registo TXT em _dmarc seguido do domínio e verifica a política, a política de subdomínios, o pct e o endereço dos relatórios agregados. Este verificador também segue o recurso ao domínio organizacional que os servidores recetores utilizam e executa a análise completa de segurança de e-mail.Analisador de segurança de e-mailCompare as verificações públicas de segurança
O que é uma consulta DMARC?
Uma consulta DNS TXT a _dmarc seguido do domínio, por exemplo _dmarc.example.com. Se nada estiver publicado aí, os servidores recetores usam o registo do domínio organizacional. Pode executar uma nesta página ou com dig TXT _dmarc.example.com.Sobre a autenticação de e-mail
Qual é a diferença entre p=none, p=quarantine e p=reject?
none pede aos servidores recetores que não tomem qualquer ação e apenas enviem relatórios, quarantine pede-lhes que tratem o e-mail com falha como suspeito, por exemplo entregando-o no spam, e reject pede-lhes que o rejeitem. Os servidores recetores combinam a política com as suas próprias verificações quando decidem.Sobre a autenticação de e-mail
Porque é que o verificador indica que o meu registo DMARC é herdado?
O domínio não tem um registo DMARC próprio, por isso os servidores recetores aplicam o registo do domínio organizacional, usando a respetiva política sp, ou p quando não existe sp (RFC 7489, secção 6.6.3). Publique um registo no subdomínio se este precisar de uma política diferente.Sobre a autenticação de e-mail
Devo usar p=reject?
Só quando os seus relatórios mostrarem que todos os remetentes legítimos passam. O RFC 9989 exige que os domínios que publicam p=reject assinem o seu e-mail com DKIM em vez de dependerem apenas do SPF, e aconselha os domínios cujos utilizadores enviam mensagens para listas de correio a não publicar p=reject (secção 7.4).Sobre a autenticação de e-mailAnalisador de segurança de e-mail
O RFC 7489 continua a ser a norma do DMARC?
Não. O RFC 9989, publicado em maio de 2026 na categoria Standards Track, torna obsoleto o RFC 7489. Mantém v, p, sp, rua, ruf, adkim, aspf e fo, acrescenta np, psd e t, e torna pct, rf e ri históricas. Os relatórios agregados e de falhas passaram para o RFC 9990 e o RFC 9991.Sobre a autenticação de e-mail
Os relatórios DMARC podem ser enviados para outro domínio?
Sim, mas, a menos que o endereço de relatórios partilhe o seu domínio organizacional, o domínio que recebe os relatórios tem de publicar um registo TXT com v=DMARC1 no nome composto pelo seu domínio, por _report._dmarc e pelo domínio dele, por exemplo example.com._report._dmarc.example.net. Sem esse registo, os servidores recetores não conseguem confirmar o acordo e não enviam relatórios para lá (RFC 7489, secção 7.1; RFC 9990, secção 4).Sobre a autenticação de e-mail
Posso fazer uma consulta DMARC através de uma API?
Sim. Envie um POST com {"target":"example.com"} para https://vigilbase.com/api/v1/agent/tools/email-security/execute. A resposta contém o resultado completo de segurança de e-mail, com a análise DMARC em result.details.records.dmarc.Execute uma verificação através da API públicaAutenticação da API e limites de pedidos
