Guia de política DMARC: de None a Reject em 4 passos

DMARC (Domain-based Message Authentication, Reporting, and Conformance) é a camada de política que une SPF e DKIM e diz aos servidores receptores o que fazer quando uma mensagem falha na autenticação. Sem DMARC, um provedor de e-mail pode aceitar silenciosamente, colocar em quarentena ou rejeitar e-mails não autenticados com base em suas próprias regras internas. Com DMARC, você define explicitamente a política de tratamento para o seu domínio.

Este guia percorre todo o processo de implementação do DMARC, desde a publicação do seu primeiro registro apenas de monitoramento até atingir o enforcement completo com uma política reject.

Por que DMARC é importante#

O spoofing de e-mail continua sendo um dos vetores de ataque mais comuns. Um atacante pode forjar o cabeçalho "From" de um e-mail para fazer parecer que a mensagem veio do seu domínio. Sem DMARC, os servidores receptores não têm uma forma confiável de saber qual é sua intenção para tratar essas mensagens.

DMARC resolve três problemas:

• Prevenção contra phishing: impede que atacantes enviem e-mails que parecem vir do seu domínio.
• Proteção da marca: evita que seu domínio seja usado em campanhas fraudulentas que prejudicam sua reputação.
• Visibilidade: os relatórios DMARC mostram exatamente quem está enviando e-mail usando seu domínio, incluindo serviços legítimos que você pode ter esquecido e remetentes não autorizados que você não sabia que existiam.

Os principais provedores de e-mail, incluindo Google, Microsoft e Yahoo, agora exigem DMARC para remetentes em massa. Desde 2024, o Google exige que domínios que enviam mais de 5.000 e-mails por dia para endereços do Gmail tenham uma política DMARC publicada.

Como o DMARC funciona com SPF e DKIM#

DMARC não realiza suas próprias verificações de autenticação. Em vez disso, ele avalia os resultados de SPF e DKIM e aplica um requisito adicional chamado alinhamento.

O requisito de alinhamento#

Para o DMARC passar, pelo menos uma das condições a seguir precisa ser verdadeira:

1. SPF passa E o domínio autenticado pelo SPF está alinhado com o domínio do cabeçalho "From". O SPF verifica o remetente do envelope (Return-Path). O DMARC exige que esse domínio coincida (ou seja um subdomínio) do domínio no cabeçalho "From" visível.

2. DKIM passa E o domínio assinado pelo DKIM (tag d=) está alinhado com o domínio do cabeçalho "From". O domínio na assinatura DKIM precisa coincidir (ou ser um subdomínio) do domínio do cabeçalho "From".

O alinhamento pode ser strict (correspondência exata de domínio) ou relaxed (subdomínios são permitidos). O alinhamento relaxed é o padrão e funciona para a maioria das configurações.

Por que o alinhamento importa#

Sem alinhamento, um atacante poderia configurar SPF e DKIM para attacker.com, enviar uma mensagem com From: ceo@yourcompany.com, e o e-mail passaria nas verificações de SPF e DKIM (para attacker.com), mas o destinatário veria o seu domínio. O alinhamento DMARC fecha essa brecha exigindo que o domínio autenticado coincida com o que o usuário vê.

Sintaxe do registro DMARC#

Um registro DMARC é um registro DNS TXT publicado em _dmarc.yourdomain.com. Aqui está um exemplo completo:

v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;

Referência de tags#

Tag	Obrigatória	Descrição	Valores
v	Sim	Versão do protocolo	Sempre DMARC1
p	Sim	Política para o domínio	none, quarantine, reject
rua	Não*	Destinatários dos relatórios agregados	URI mailto:
ruf	Não	Destinatários dos relatórios forenses	URI mailto:
pct	Não	Porcentagem de mensagens em que aplicar a política	1-100 (padrão: 100)
aspf	Não	Modo de alinhamento SPF	r (relaxed, padrão) ou s (strict)
adkim	Não	Modo de alinhamento DKIM	r (relaxed, padrão) ou s (strict)
sp	Não	Política para subdomínios	none, quarantine, reject
fo	Não	Opções de relatório de falhas	0, 1, d, s

*Embora rua seja tecnicamente opcional, você deve sempre incluí-lo. Sem relatórios agregados, você está publicando uma política às cegas, sem nenhuma forma de ver o que está acontecendo.

Valores de política explicados#

• none: Apenas monitorar. Mensagens que falham no DMARC são entregues normalmente. Você recebe relatórios mostrando os resultados de autenticação, mas nenhuma ação é tomada. Este é o ponto de partida.
• quarantine: Mensagens que falham no DMARC são tratadas como suspeitas. Normalmente são colocadas na pasta de spam ou lixo eletrônico do destinatário.
• reject: Mensagens que falham no DMARC são rejeitadas diretamente. O servidor receptor retorna um erro e a mensagem não é entregue.

Opções de relatório de falhas (tag fo)#

• 0 (padrão): Gera um relatório apenas se SPF e DKIM falharem no alinhamento.
• 1: Gera um relatório se SPF ou DKIM falhar no alinhamento. É mais útil para depuração e é a configuração recomendada.
• d: Gera um relatório se DKIM falhar, independentemente do alinhamento.
• s: Gera um relatório se SPF falhar, independentemente do alinhamento.

A progressão em 4 passos até o enforcement completo#

Pular direto para p=reject sem preparação é perigoso. Você pode bloquear e-mails legítimos de serviços que esqueceu que estava usando. A abordagem segura é uma progressão gradual.

Passo 1: Implantar com p=none (Monitorar)#

Comece com uma política apenas de monitoramento para coletar dados sem afetar a entrega de e-mails.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

O que fazer durante essa fase:

• Publique o registro e aguarde pelo menos 2 a 4 semanas para coletar dados suficientes nos relatórios.
• Revise os relatórios agregados para identificar todas as fontes legítimas de e-mail do seu domínio. Isso inclui seu servidor de e-mail principal, plataformas de marketing (Mailchimp, SendGrid, HubSpot), serviços de e-mail transacional, sistemas de CRM, sistemas de tickets e qualquer ferramenta SaaS que envie e-mail em seu nome.
• Para cada fonte legítima, garanta que o SPF esteja configurado (incluindo os IPs de envio do serviço no seu registro SPF) e que o DKIM esteja configurado (publicando a chave pública DKIM do serviço no seu DNS).
• Investigue qualquer fonte que você não reconheça. Pode ser um serviço legítimo esquecido ou um remetente não autorizado.

Duração: 2 a 4 semanas no mínimo. Mais tempo se você tiver uma infraestrutura de envio complexa.

Passo 2: Mudar para p=quarantine em 25% (Enforcement suave)#

Quando você tiver certeza de que todas as fontes legítimas passam no DMARC, comece o enforcement em uma pequena porcentagem do tráfego.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Isso diz aos servidores receptores para colocar em quarentena (normalmente enviar para o spam) 25% das mensagens que falham no DMARC. Os outros 75% são tratados como se a política fosse none.

O que fazer durante essa fase:

• Monitore os relatórios de perto para detectar qualquer aumento de falhas DMARC vindas de fontes legítimas.
• Se descobrir um novo remetente legítimo sem SPF ou DKIM, corrija a configuração antes de prosseguir.
• Fique atento a relatos de e-mails legítimos caindo em pastas de spam.
• Se tudo parecer limpo após 1 a 2 semanas, avance para o próximo passo.

Duração: 1 a 2 semanas.

Passo 3: Aumentar para p=quarantine em 100% (Quarentena total)#

Remova o limite de porcentagem para que a política de quarentena se aplique a todas as mensagens com falha.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

Ou simplesmente omita a tag pct, já que 100 é o padrão:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;

O que fazer durante essa fase:

• Continue monitorando os relatórios.
• Verifique se nenhum e-mail legítimo está sendo colocado em quarentena.
• Comunique-se com a sua equipe para verificar se alguém relata e-mails sumidos.
• Após 2 a 4 semanas sem problemas, você está pronto para o passo final.

Duração: 2 a 4 semanas.

Passo 4: Aplicar p=reject (Proteção total)#

Este é o estado final. Mensagens que falham no DMARC são rejeitadas por completo.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

Nesse ponto, qualquer pessoa que tente enviar e-mail a partir do seu domínio sem autenticação adequada terá suas mensagens rejeitadas. Seu domínio está totalmente protegido contra spoofing.

Manutenção contínua:

• Continue revisando os relatórios agregados pelo menos mensalmente.
• Quando adicionar um novo serviço de envio de e-mails, configure SPF e DKIM antes de enviar.
• Faça rotação das chaves DKIM periodicamente e verifique se as novas chaves passam no DMARC.
• Considere adicionar ruf para relatórios forenses se sua caixa de entrada suportar o volume.

Como ler os relatórios DMARC#

Relatórios agregados (rua)#

Os relatórios agregados são arquivos XML enviados diariamente pelos servidores receptores. Eles contêm:

• O nome da organização do servidor que envia o relatório.
• O intervalo de datas coberto.
• A política DMARC publicada por você.
• Para cada IP de origem que enviou e-mail usando seu domínio: o número de mensagens, resultados de SPF/DKIM/DMARC e desfechos de alinhamento.

Um trecho simplificado de um relatório agregado fica assim:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>1542</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

XML puro é difícil de ler em escala. A maioria das organizações usa um serviço ou ferramenta de análise de relatórios DMARC para fazer o parsing e visualização dos dados. Serviços como o monitoramento DMARC gratuito da Postmark, o dmarcian ou o EasyDMARC podem ajudar.

Relatórios forenses (ruf)#

Os relatórios forenses contêm detalhes sobre mensagens individuais que falharam no DMARC, incluindo cabeçalhos da mensagem e, às vezes, conteúdo parcial. São úteis para investigar incidentes específicos de spoofing, mas geram um volume alto e podem conter informações sensíveis. Muitos receptores não enviam mais relatórios forenses por questões de privacidade.

Armadilhas comuns no DMARC#

1. Publicar p=reject sem monitorar antes#

Este é o erro mais perigoso. Se algum serviço legítimo de e-mail não estiver corretamente configurado com SPF e DKIM, essas mensagens serão rejeitadas. Sempre comece com p=none e revise os relatórios.

2. Esquecer de remetentes terceirizados#

A causa mais comum de falhas DMARC vindas de fontes legítimas é esquecer de uma ferramenta SaaS que envia e-mail usando seu domínio. Culpados frequentes incluem:

• Plataformas de automação de marketing
• Sistemas de tickets de suporte ao cliente
• Plataformas de CRM que enviam e-mail em seu nome
• Software de faturamento e contabilidade
• Ferramentas de RH e recrutamento
• Ferramentas de calendário e agendamento

Audite todos os serviços conectados ao seu domínio antes de avançar além do p=none.

3. Registro SPF excedendo 10 lookups DNS#

O SPF tem um limite rígido de 10 mecanismos de lookup DNS (include, a, mx, redirect, exists). Se o seu registro SPF exceder esse limite, a avaliação do SPF retorna um "permerror", o que significa que o SPF efetivamente falha para todas as mensagens. Como o DMARC exige que SPF ou DKIM passe com alinhamento, um permerror de SPF coloca mais pressão sobre o DKIM.

Se você tem muitos serviços de envio, considere achatar seu registro SPF ou adotar uma estratégia de subdomínios em que serviços diferentes enviam de subdomínios diferentes.

4. Não usar rua#

Sem relatórios agregados, você não tem visibilidade sobre como o e-mail do seu domínio está sendo autenticado. Sempre inclua uma tag rua, mesmo com p=none.

5. Subdomínios sem a tag sp=#

Por padrão, se você não definir a tag sp, os subdomínios herdam a política do domínio pai. Se você usa subdomínios para diferentes finalidades (por exemplo, marketing.yourdomain.com), considere definir uma política explícita para subdomínio ou publicar registros DMARC separados para cada subdomínio.

6. Ignorar o DMARC depois de chegar ao reject#

DMARC não é uma configuração "configure e esqueça". Novos serviços de envio são adicionados, chaves expiram, registros SPF são modificados. Continue revisando os relatórios agregados mensalmente para detectar regressões.

Como verificar sua configuração DMARC#

Você pode verificar seu registro DMARC atual consultando o DNS:

dig TXT _dmarc.yourdomain.com

Para uma verificação completa que avalia seu DMARC junto com SPF, DKIM, registros MX e status em blacklist, use o Email Health Checker grátis da Nova Uptime. A ferramenta dá uma pontuação de 0 a 100, uma nota em letra (A a F) e recomendações específicas para melhorar sua política DMARC.

A ferramenta avalia o nível de rigor da sua política DMARC como parte da pontuação. Uma política p=reject com relatórios agregados ganha a pontuação mais alta, enquanto p=none ou um registro DMARC ausente resulta em deduções significativas. Isso dá uma visão clara de onde seu domínio está e quais passos tomar a seguir.

Cronograma de implementação do DMARC#

Aqui está um cronograma realista para uma implantação completa do DMARC:

Semana	Ação	Registro DMARC
1	Publicar registro de monitoramento, configurar processamento de relatórios	p=none; rua=mailto:...
2-4	Revisar relatórios, corrigir SPF/DKIM para todos os remetentes legítimos	p=none; rua=mailto:...
5-6	Enforcement suave em 25%	p=quarantine; pct=25; rua=mailto:...
7-8	Quarentena total	p=quarantine; rua=mailto:...
9-12	Enforcement total	p=reject; rua=mailto:...
Contínuo	Revisão mensal dos relatórios, manter configurações	p=reject; rua=mailto:...

Para organizações com infraestrutura de e-mail simples (um serviço de e-mail principal, uma ou duas ferramentas de marketing), isso pode ser comprimido para 4 a 6 semanas. Para empresas com dezenas de serviços de envio, reserve de 3 a 6 meses.

Pontos-chave#

• DMARC se baseia em SPF e DKIM adicionando enforcement de política e requisitos de alinhamento.
• Sempre comece com p=none e relatórios agregados. Nunca pule direto para p=reject.
• Use a tag pct para aumentar o enforcement gradualmente.
• Revise os relatórios agregados para identificar todas as fontes legítimas de e-mail antes de aplicar enforcement.
• Chegar a p=reject é o objetivo, mas exige preparação.
• Continue monitorando após a implantação. DMARC requer manutenção contínua.
• Use o Email Health Checker da Nova Uptime para verificar sua configuração DMARC e obter uma avaliação completa de autenticação de e-mail.

Uma política DMARC bem implementada é uma das proteções mais fortes que você pode implantar para seu domínio. Ela previne spoofing, gera confiança com os provedores de e-mail e dá visibilidade clara sobre quem está enviando e-mail em seu nome.

Perguntas Frequentes#

O que é uma verificação de DMARC?#

Uma verificação de DMARC checa se seu domínio tem um registro DNS DMARC válido e avalia as configurações da política. Ela confirma se a sintaxe do seu registro DMARC está correta, se sua política (none/quarantine/reject) está configurada corretamente e se os endereços de relatório estão funcionais. Faça uma verificação DMARC grátis para ver sua configuração atual.

Existe monitoramento DMARC gratuito?#

Sim. A Nova Uptime inclui monitoramento DMARC como parte do seu email health checker. Ele verifica seu registro DMARC junto com SPF, DKIM e status em blacklist em uma frequência configurável e te alerta quando algo muda. O plano grátis cobre até 5 domínios.

Quanto tempo leva para chegar ao p=reject?#

Para a maioria das organizações, a progressão de p=none para p=reject leva de 2 a 4 meses. O cronograma depende de quantas fontes legítimas de e-mail você precisa identificar e autenticar. Apressar para reject sem revisar os relatórios DMARC corre o risco de bloquear seus próprios e-mails legítimos.

O que acontece se eu definir DMARC como reject sem SPF e DKIM?#

Seus e-mails serão rejeitados pelos servidores receptores. O enforcement do DMARC exige que pelo menos um entre SPF ou DKIM passe E esteja alinhado com seu domínio do cabeçalho From. Configure SPF e DKIM primeiro, depois progrida o DMARC de none para reject de forma gradual.

Leitura relacionada#

• SPF, DKIM e DMARC: Guia Completo — Como os três protocolos funcionam juntos
• Guia de Teste e Configuração DMARC — Configuração avançada de política DMARC
• Guia de Verificação e Remoção de Blacklist de E-mail — O que fazer quando problemas de autenticação levam a entradas em blacklist
• Checklist de Entregabilidade de E-mail — 15 passos para melhorar a entrega na caixa de entrada
• Email Health Checker grátis — Verifique DMARC, SPF, DKIM e blacklists em uma só varredura