DMARC

Definição

DMARC (Domain-based Message Authentication, Reporting, and Conformance) é um mecanismo escalável de autenticação de e-mail que permite ao dono de um domínio publicar uma política legível por máquina no DNS, declarando o que os servidores receptores devem fazer quando uma mensagem que chega falha nas checagens de alinhamento de SPF ou DKIM, e habilitando esses servidores a enviar relatórios estruturados de volta para o dono do domínio. Os três valores possíveis de política — none, quarantine e reject — dão ao dono do domínio um controle gradual sobre como o e-mail não autenticado que se diz vindo do seu domínio será tratado pela infraestrutura global de recepção^[1].

O DMARC foi desenvolvido em colaboração por participantes da indústria como PayPal, Google, Microsoft, Yahoo, ReturnPath e outros stakeholders do ecossistema de e-mail, e foi publicado pela primeira vez como IETF RFC 7489 em março de 2015. A especificação é mantida pelo grupo de trabalho da DMARC.org. Ele estende e coordena dois padrões anteriores de autenticação: SPF (RFC 7208) e DKIM (RFC 6376), que utiliza como sinais de entrada — sem substituí-los.

Como funciona

A política DMARC é publicada como um registro DNS TXT em _dmarc.<domínio>. Um registro típico tem essa cara: v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s. As tags principais são:

• v=DMARC1 — identificador de versão
• p= — política: none (apenas monitora), quarantine (entrega para spam/lixo) ou reject (descarta totalmente a mensagem)
• rua= — URI de destino dos relatórios agregados; recebe resumos diários em XML dos resultados de autenticação enviados pelos provedores de caixa postal participantes
• ruf= — URI dos relatórios forenses; recebe relatórios em nível de mensagem, com dados redigidos, para falhas individuais
• pct= — percentual das mensagens às quais a política se aplica (permite rollout faseado)
• adkim= e aspf= — modo de alinhamento: s (estrito, exige correspondência exata de domínio) ou r (relaxado, aceita correspondência por subdomínio)

A inovação crítica que o DMARC traz é o alinhamento de identificadores. Um pass de SPF ou DKIM só é considerado conforme com DMARC se o domínio autenticado bater com o domínio do cabeçalho RFC5322.From — o endereço “From:” que o usuário vê no e-mail. Isso fecha a brecha deixada por SPF e DKIM operando de forma independente: uma mensagem pode passar SPF em outro domínio (o envelope sender) e passar DKIM para um domínio assinante terceirizado, e ainda assim ser fraudulenta se o cabeçalho From mostrar um domínio diferente. O DMARC exige que pelo menos um entre SPF e DKIM produza um pass alinhado.

Os relatórios agregados (RUA) são entregues como arquivos XML compactados, em geral em até 24 horas após o fim do período de relatório, por provedores como Google (Gmail), Microsoft (Outlook/Exchange Online Protection), Yahoo Mail, Apple iCloud Mail, Comcast e outros. Eles trazem, por IP de origem, contagens de mensagens, resultados de SPF, resultados de DKIM e disposição DMARC. Ferramentas como DMARCIAN, Valimail, Postmark DMARC Digests e Google Postmaster Tools entregam dashboards que parseiam e visualizam esses relatórios^[2].

Onde você encontra

DMARC aparece sempre que existe envio de e-mail em alto volume ou alta criticidade. Desde fevereiro de 2024, Google e Yahoo passaram a exigir que remetentes que enviam mais de 5.000 mensagens por dia para endereços Gmail ou Yahoo Mail tenham um registro DMARC publicado, com p=none no mínimo — uma mudança de política do setor que, na prática, tornou o DMARC obrigatório para envios em massa. A Microsoft anunciou requisitos parecidos para as caixas Outlook.com em 2025.

Para plataformas de concurso que disparam votos por confirmação de e-mail em escala, o DMARC tem dois papéis. Primeiro, protege a reputação do domínio remetente ao instruir os servidores receptores a rejeitar mensagens forjadas — impedindo que terceiros falsifiquem o endereço From da plataforma em campanhas de phishing, o que prejudicaria a entregabilidade do domínio. Segundo, os relatórios agregados de DMARC oferecem um canal de monitoramento operacional: o dono do domínio consegue ver, em todos os provedores participantes, qual fração das mensagens passa SPF e DKIM, e detectar erros de configuração antes que virem falhas em massa de e-mails de confirmação.

Provedores de e-mail como SendGrid, Mailgun, Amazon SES, Postmark e SparkPost publicam guias para configurar DMARC junto da sua própria infraestrutura de envio. Ferramentas de diagnóstico DNS como MXToolbox DMARC Lookup, DMARC Inspector da DMARCIAN e o checador da EasyDMARC permitem validar políticas publicadas.

Exemplos práticos

Uma empresa de concurso começa a enviar e-mails de confirmação a partir de um novo subdomínio, confirm.votes.example.com. O domínio pai votes.example.com tem p=reject no registro DMARC. Como os registros SPF e DKIM do novo subdomínio ainda não foram configurados, os e-mails de confirmação falham no alinhamento DMARC e são rejeitados pelo Gmail. O administrador diagnostica o problema pelos relatórios agregados, que mostram 100% de falha DMARC no subdomínio, adiciona o include SPF e os registros DNS de selector DKIM apropriados e ajusta temporariamente a política DMARC do subdomínio (sp=none) durante o rollout.

Uma marca roda um concurso de envio de fotos com R$ 250.000 em prêmios. Um fraudador tenta enviar e-mails de phishing usando o domínio do concurso da marca como endereço From, levando os eleitores para uma página falsa de confirmação para roubar credenciais. Como a política DMARC do domínio é p=reject, Gmail, Outlook e Yahoo Mail descartam as mensagens fraudulentas antes da entrega, protegendo tanto os participantes quanto a reputação de remetente da marca.

Conceitos relacionados

DMARC depende de SPF Record e de DKIM como suas entradas de autenticação — um pass DMARC exige que pelo menos um deles esteja alinhado com o domínio do cabeçalho From. Em operações de concurso, o efeito combinado de SPF, DKIM e DMARC sobre a entrega na caixa de entrada é o principal fator técnico que determina se as mensagens de Voto por confirmação de e-mail chegam até os eleitores. O padrão BIMI, que permite exibir o logo da marca em clientes de e-mail compatíveis como sinal de confiança, exige p=quarantine ou p=reject no DMARC como pré-requisito.

Fontes

1. IETF RFC 7489 — DMARC: https://www.rfc-editor.org/rfc/rfc7489
2. DMARC.org: https://dmarc.org
3. Wikipedia — DMARC: https://en.wikipedia.org/wiki/DMARC