O que é o DMARC?
O DMARC (Domain-based Message Authentication, Reporting & Conformance) é um protocolo de autenticação de e-mail que diz aos servidores de e-mail destinatários o que fazer quando as verificações de SPF ou DKIM falham. Sem o DMARC, um destinatário sabe que um e-mail falhou na autenticação, mas não tem nenhuma instrução sobre rejeitá-lo, colocá-lo em quarentena ou deixá-lo passar. O DMARC preenche essa lacuna.
Definido na RFC 7489 e exigido por Google, Yahoo e PCI DSS v4.0 para remetentes em massa e domínios voltados ao cliente.
Quem exige o DMARC?
O DMARC deixou de ser uma boa prática opcional para se tornar uma exigência de conformidade obrigatória nos setores governamental, financeiro, de saúde e de infraestrutura crítica em todo o mundo.
Mandatos governamentais
Todos os domínios do poder executivo federal devem implementar o DMARC com p=reject
Amplia as bases de referência da autenticação de e-mail, alinha-se com os requisitos de remetentes da Microsoft/Google/Yahoo
Os domínios do governo central devem implementar DMARC, SPF, DKIM e TLS. Todos os domínios, inclusive os estacionados, exigem registros DMARC
O Australian Signals Directorate afirma que o DMARC é crítico - implemente-o agora, independentemente dos controles existentes
Os departamentos federais devem implementar DMARC, SPF e DKIM. Mínimo p=none com progressão gradual até p=reject
Normas do setor
Mecanismos anti-phishing incluindo DMARC exigidos desde 31 de março de 2025 para todas as organizações que processam dados de cartão de pagamento
Recomenda o DMARC com p=reject como política-alvo. Publique registros em todos os domínios, inclusive os que não enviam e-mails
Implemente o DMARC para reduzir a chance de e-mails falsificados ou modificados provenientes de domínios válidos
Exige medidas robustas de cibersegurança, incluindo controles de segurança de e-mail. O DMARC reforça a conformidade com a NIS2 ao lado do GDPR e da PCI DSS
Norma de gestão da segurança da informação - a implementação do DMARC apoia os controles do Anexo A para a segurança das comunicações
Requisitos dos provedores de e-mail
Remetentes em massa (5.000+ mensagens/dia para o Gmail) devem ter DMARC com no mínimo p=none desde fevereiro de 2024
Remetentes em massa devem autenticar com DMARC ao lado de SPF e DKIM desde fevereiro de 2024
A partir de 5 de maio de 2025, a Microsoft rejeita e-mails que falham no DMARC provenientes de remetentes de alto volume para Outlook.com, Hotmail e Live.com
A Apple aplica políticas DMARC nos domínios do iCloud Mail, rejeitando mensagens que falham na autenticação com p=reject
60% dos sinistros de BEC têm origem em domínios sem aplicação. As seguradoras exigem cada vez mais SPF, DKIM e DMARC como condições de contratação
O e-mail foi criado sem verificação de remetente
O protocolo SMTP não tem nenhuma forma integrada de verificar se a pessoa no campo "From" realmente enviou a mensagem. Qualquer um pode enviar um e-mail alegando ser qualquer pessoa. O DMARC corrige isso.
Sem o DMARC
Com o DMARC (p=reject)
Três etapas, cada e-mail
O DMARC se apoia no SPF e no DKIM ao adicionar a aplicação de política e a geração de relatórios. Veja o que acontece quando um e-mail protegido por DMARC chega a um servidor destinatário.
O remetente publica um registro DMARC
O proprietário do domínio adiciona um registro TXT em _dmarc.domain.com no DNS. Esse registro contém a política (none, quarantine ou reject) e o endereço de relatório.
O destinatário verifica o alinhamento de SPF + DKIM
Quando um e-mail chega, o servidor destinatário verifica se o SPF ou o DKIM passa E se o domínio autenticado se alinha com o domínio do cabeçalho From. Essa verificação de alinhamento é o que diferencia o DMARC do SPF ou do DKIM sozinhos.
Política aplicada, relatório enviado
Se o alinhamento falhar, o destinatário aplica a política publicada - entregar normalmente (none), direcionar para o spam (quarantine) ou rejeitar completamente (reject). De qualquer forma, o destinatário envia um relatório agregado de volta ao proprietário do domínio.
Por dentro de um registro DMARC
Um registro DMARC é um registro DNS TXT publicado em _dmarc.yourdomain.com. Cada tag controla um comportamento específico.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=r; pct=100; fo=1 v=DMARC1 Obrigatório Identificador da versão do protocolo. Deve ser a primeira tag de cada registro DMARC.
v=DMARC1 p= Obrigatório Política para o domínio: none (monitorar), quarantine (pasta de spam) ou reject (bloquear).
p=reject rua= Endereço para receber os relatórios agregados - resumos XML dos resultados de autenticação enviados diariamente pelos destinatários.
rua=mailto:dmarc@example.com ruf= Endereço para receber os relatórios forenses - detalhes de falha por mensagem para investigar tentativas de spoofing.
ruf=mailto:forensic@example.com sp= Política de subdomínio. Substitui a política principal para subdomínios. Assume o valor de p= por padrão se não for definida.
sp=reject adkim= Modo de alinhamento DKIM: strict (s) exige correspondência exata de domínio, relaxed (r) permite alinhamento de subdomínio.
adkim=r aspf= Modo de alinhamento SPF: strict (s) exige correspondência exata de domínio, relaxed (r) permite alinhamento de subdomínio.
aspf=r pct= Porcentagem de mensagens com falha às quais a política se aplica. Use para uma implementação gradual (por exemplo, pct=10 e depois aumente).
pct=100 fo= Opções de relatório forense. Controla quando os relatórios forenses são gerados (0=ambos falham, 1=um ou outro falha, d=falha de DKIM, s=falha de SPF).
fo=1 As três políticas DMARC
Cada jornada DMARC segue o mesmo caminho: monitorar, quarentena, rejeição. Cada política se apoia na anterior. Saiba mais sobre as políticas DMARC.
p=none Os destinatários não tomam nenhuma medida em relação às mensagens com falha. Os relatórios ainda são enviados, dando a você visibilidade sobre quem envia e-mails a partir do seu domínio.
p=quarantine As mensagens com falha são direcionadas para a pasta de spam ou lixo eletrônico. Os destinatários ainda podem encontrá-las, mas elas são sinalizadas como suspeitas.
p=reject As mensagens com falha são rejeitadas no nível SMTP. O destinatário nunca as vê. Esta é a aplicação completa.
Como SPF, DKIM e DMARC
funcionam juntos
Cada protocolo resolve uma parte diferente do quebra-cabeça da autenticação de e-mail. O SPF autoriza os servidores de envio. O DKIM garante a integridade da mensagem. O DMARC os une com alinhamento e política.
-
SPFVerifica se o IP do servidor de envio é autorizado pelo registro DNS do domínio. Verifica o remetente do envelope (Return-Path).
Verificar registro SPF → -
DKIMAnexa uma assinatura criptográfica aos cabeçalhos do e-mail. O servidor destinatário verifica a assinatura em relação a uma chave pública no DNS.
Verificar registro DKIM → -
DMARCExige que o SPF ou o DKIM passe E se alinhe com o domínio do cabeçalho From. Publica a política para falhas e habilita a geração de relatórios.
Verificar registro DMARC →
Como configurar o DMARC
A implantação do DMARC segue uma abordagem em fases. Correr para a aplicação sem monitoramento faz com que e-mails legítimos sejam bloqueados. Planeje de 9 a 18 meses entre o primeiro registro e o p=reject completo.
Configurar o SPF
Publique um registro SPF TXT listando cada endereço IP e cada serviço autorizado a enviar e-mails para o seu domínio. Mantenha-o abaixo de 10 consultas DNS.
Verifique seu registro SPF →Configurar o DKIM
Ative a assinatura DKIM em cada fonte de envio - seu servidor de e-mail, Google Workspace, Microsoft 365, plataformas de marketing - para que as mensagens de saída carreguem uma assinatura criptográfica.
Descubra os seletores DKIM →Publicar o DMARC em p=none
Adicione um registro DMARC TXT em _dmarc.seudominio.com começando com p=none e um endereço rua= para receber os relatórios agregados.
Valide seu registro DMARC →Monitorar os relatórios por mais de 90 dias
Analise os relatórios agregados para identificar cada remetente, corrigir falhas de autenticação e confirmar que todos os e-mails legítimos passam no alinhamento de SPF ou DKIM.
Comece a monitorar com o DMARC Report →Aplicar com quarantine e depois reject
Passe para p=quarantine, monitore por mais de 90 dias e, em seguida, avance para p=reject. Use pct= para uma implementação gradual. A jornada completa leva de 9 a 18 meses.
Saiba mais sobre as políticas DMARC →Perguntas frequentes
O que é o DMARC em termos simples?
O DMARC é um protocolo de segurança de e-mail que permite aos proprietários de domínio dizer aos servidores de e-mail destinatários o que fazer quando um e-mail falha nas verificações de autenticação. Ele impede que invasores enviem e-mails que parecem vir do seu domínio, protegendo sua marca e seus destinatários contra phishing.
Quanto tempo leva para implementar o DMARC?
Publicar um registro DMARC em p=none leva alguns minutos. No entanto, alcançar a aplicação completa em p=reject normalmente leva de 9 a 18 meses. Cada fase (none, quarantine, reject) requer pelo menos 90 dias de monitoramento para identificar e corrigir todas as fontes de envio legítimas.
O DMARC impede todo o phishing?
O DMARC impede o spoofing direto de domínio - os invasores não podem enviar e-mails que passem na autenticação usando exatamente o seu domínio. Ele não impede ataques com domínios parecidos (por exemplo, examp1e.com) nem phishing de domínios não relacionados. O DMARC é uma camada em uma estratégia de segurança de e-mail em defesa em profundidade.
Qual é a diferença entre SPF, DKIM e DMARC?
O SPF verifica se um servidor de envio é autorizado pelo proprietário do domínio. O DKIM anexa uma assinatura criptográfica para provar que a mensagem não foi alterada em trânsito. O DMARC os une exigindo que o SPF ou o DKIM passe E se alinhe com o domínio do cabeçalho From, e então diz aos destinatários o que fazer quando a autenticação falha.
O DMARC é obrigatório?
Sim - o DMARC é obrigatório sob vários frameworks. As agências federais dos EUA devem implementar p=reject sob a CISA BOD 18-01. A PCI DSS v4.0 exige o DMARC desde março de 2025. Google, Yahoo e Microsoft exigem o DMARC para remetentes em massa. O NCSC do Reino Unido, o ASD da Austrália e o CCCS do Canadá exigem o DMARC para domínios governamentais. A EU NIS2 reforça o argumento a favor do DMARC em infraestruturas críticas. Muitas apólices de seguro cibernético agora exigem a aplicação de SPF, DKIM e DMARC como condições de contratação.
O que é um relatório agregado DMARC?
Um relatório agregado (RUA) é um arquivo XML enviado diariamente pelos servidores de e-mail destinatários. Ele resume os resultados de autenticação de todas as mensagens que alegam vir do seu domínio - mostrando quais remetentes passaram ou falharam no SPF e no DKIM, e qual política foi aplicada. O DMARC Report converte esses arquivos XML em painéis visuais.
O DMARC pode prejudicar a entrega dos meus e-mails?
Em p=none, o DMARC não pode afetar a entrega de e-mails - é apenas monitoramento. Em p=quarantine ou p=reject, as mensagens de remetentes legítimos que falham na autenticação serão afetadas. É por isso que uma abordagem em fases com mais de 90 dias de monitoramento em cada etapa é essencial antes da aplicação.
Aprovado por equipes de segurança do mundo todo
Rated 4.8/5 on G2 · 469 verified reviews
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Ryan C.
Director
"Control Centre for Email Security"
I like that we can see and check all reports on just 1 platform. We manage multiple domains, and monitoring them all in one place is essential.
eddy g.
Director
"A great solution to a common email problem."
I have been using them for the last month after my Google business email started giving DMARC errors. I didn't even know what it meant at that time. After a little googling I found that people can spoof it as well. So far so good — the best thing is it protects every email.
Comece a monitorar seus relatórios DMARC hoje
O plano gratuito inclui 1 domínio e 10.000 relatórios mensais - sem cartão de crédito.
Comece grátis - Sem cartão de crédito