O que é DMARC? Alinhamento, Políticas e as RFCs de 2026

O que é DMARC? É um registro DNS que avisa aos servidores de email receptores o que fazer quando uma mensagem diz vir do seu domínio no campo From, mas falha na autenticação, e onde enviar relatórios sobre isso. DMARC não autentica nada por si só. Ele verifica que SPF ou DKIM passaram e que o domínio que validaram bata com o domínio que o leitor vê.

Essa correspondência é chamada de alinhamento, e é a parte que a maioria das equipes erra. Uma mensagem pode passar em SPF, passar em DKIM, e ainda assim falhar em DMARC.

DMARC é uma camada de política em cima de SPF e DKIM

SPF lista quais IPs podem enviar por um domínio. DKIM assina a mensagem para que um receptor possa verificar que ela não foi alterada e que o domínio que a assinou aprovou. Nenhum dos dois olha para o endereço From que um humano lê.

DMARC fecha essa brecha. Ele faz uma única pergunta: o domínio visível no cabeçalho From se alinha com o domínio que passou em SPF ou DKIM? Se sim, a mensagem passa. Se não, o receptor aplica sua política.

O registro fica em _dmarc.seudominio.com.br como um registro TXT. Um mínimo e válido se parece com isto:

_dmarc.exemplo.com.br.  IN  TXT  "v=DMARC1; p=none; rua=mailto:relatorios-dmarc@exemplo.com.br"

Três tags fazem o trabalho real. p é a política, rua é para onde os relatórios agregados vão, e adkim / aspf definem o quão rigoroso o alinhamento é. Tudo o mais é opcional.

O alinhamento é onde as boas configurações falham

SPF autentica o envelope sender, o domínio Return-Path. DKIM autentica o domínio na tag d= da assinatura. DMARC precisa que pelo menos um desses bata com o domínio From, ou exatamente (estrito) ou no nível do domínio organizacional (relaxado, o padrão).

Aqui está a falha que vemos com mais frequência nas traces. Uma equipe envia por um provedor terceirizado, o provedor assina com seu próprio domínio (d=provedor-email.net) e usa seu próprio domínio bounce. SPF passa, DKIM passa, e DMARC falha porque nenhum domínio bata com exemplo.com.br.

A solução é um domínio de envio customizado: uma chave DKIM publicada sob seu domínio, e idealmente um return-path customizado em um subdomínio. Todo provedor sério suporta isso. Poucos ativam por padrão.

As três políticas: none, quarantine, reject

A tag p tem três valores, e eles não são uma escada que você sobe em um cronograma.

• p=none: o receptor entrega normalmente e envia relatórios. Use-a pelas primeiras 2 a 4 semanas, enquanto você faz o inventário dos remetentes.

• p=quarantine: o receptor roteia falhas para spam ou lixo eletrônico. Use-a quando os relatórios mostram que todas as fontes legítimas estão alinhadas.

• p=reject: o receptor recusa falhas no estágio SMTP. Use-a quando quarantine rodar limpo por um ciclo de envio completo.

p=none é monitoramento, não proteção. Um domínio em none por dois anos tem uma caixa de conformidade e sem defesa contra spoofing. Pule a tentação de deixá-lo lá porque "nada quebrou".

p=reject é o destino para qualquer domínio que envia apenas mail que você controla. Domínios com muito tráfego de mailing list ou forwarders legados precisam de mais cuidado, porque encaminhamento frequentemente quebra SPF e pode quebrar DKIM se o intermediário editar o corpo.

Por que as regras do Gmail e Yahoo tornaram isso urgente

Desde fevereiro de 2024, as diretrizes de remetente do Google exigem que quem envie mais de 5.000 mensagens por dia para contas Gmail publique um registro DMARC, com SPF e DKIM em vigor. A política pode ser none. O Google também pede aos remetentes em massa que mantenham a taxa de spam reportada pelos usuários em Ferramentas do Postmaster abaixo de 0,30%, e recomenda ficar abaixo de 0,10%.

O Yahoo Sender Hub afirma o mesmo requisito principal: uma política DMARC válida de pelo menos p=none, com o domínio From alinhado ao domínio SPF ou DKIM. O alinhamento relaxado é aceitável.

Note o que está e o que não está nessas regras. O requisito é um registro publicado e alinhamento passar, não enforcement. Esse é um piso. Não é uma linha de chegada.

Os relatórios agregados são o produto, a política é a chave

O endereço rua recebe relatórios XML diários de cada receptor que honra DMARC. Cada relatório lista IPs de origem, contagens de mensagens, os resultados de SPF e DKIM, e se o alinhamento se manteve. É assim que você encontra o remetente esquecido: a velha exportação de CRM, a ferramenta de cobrança que um contratante conectou em 2022, o formulário de marketing em um subdomínio que ninguém possui.

XML bruto é ilegível em volume. Rotule rua para uma caixa de correio que um parser possa ingerir, ou para um serviço de relatórios DMARC hospedado, e olhe para os dados agrupados por origem. O que você quer ver é cada fonte legítima mostrando 100% alinhada, e tudo o mais claramente desconhecido.

Um rollout prático roda nesta ordem:

1. Publique p=none com um endereço rua.

2. Colete 2 a 4 semanas de relatórios. Construa o inventário do remetente.

3. Corrija cada fonte legítima desalinhada com um domínio DKIM customizado ou return-path.

4. Mude para p=quarantine. Fique atento a tickets de suporte sobre mail desaparecido.

5. Mude para p=reject quando quarantine mostrar zero falhas legítimas.

Entregue cada passo separadamente. Mudar a política e adicionar um novo provedor de envio na mesma semana torna qualquer regressão impossível de atribuir.

DMARCbis muda as tags, não seu registro

Em 2026 o IETF publicou RFC 9989, RFC 9990, e RFC 9991, que obsoletam RFC 7489. RFC 9989 é a spec DMARC principal. Relatórios agregados e de falha se mudaram para seus próprios documentos.

As mudanças práticas para um dono de registro são pequenas:

• pct, rf, e ri foram removidos.

• t (testing mode) substitui pct como chave tudo-ou-nada: t=y relata sem enforcer.

• np define uma política para subdomínios inexistentes, o que bloqueia spoofing de endereços como abc123.exemplo.com.br.

• psd marca domínios de sufixo público, e um tree walk DNS substitui a velha busca Public Suffix List.

Registros v=DMARC1 existentes permanecem válidos. Nada quebra se você não mudar nada hoje. Suporte do provedor pelas novas tags será lançado de forma desigual, então uma tag nova que parece não fazer nada geralmente significa que o receptor ainda não a implementou.

A tag np é a que vale a pena adotar cedo. Definir np=reject enquanto p ainda está none fecha o caminho de abuso de subdomínio falso sem comprometer o resto do seu mail a enforcement.

Subdomínios, e por que o padrão herda

Um registro DMARC no domínio organizacional se aplica a subdomínios também, a menos que você o sobrescreva com sp. Essa herança é útil e também uma armadilha.

Se marketing envia de news.exemplo.com.br através de um provedor separado, ele herda a política pai. Mude o pai para p=reject antes que esse provedor tenha alinhado DKIM e o newsletter cai no chão. Publique um registro _dmarc.news.exemplo.com.br separado quando um subdomínio tem sua própria frota de remetentes e seu próprio ritmo de rollout.

Uma arquitetura mais limpa separa fluxos por subdomínio desde o início. Mail transacional em um, lifecycle em outro, mail humano na raiz. Cada um recebe suas próprias chaves DKIM, sua própria reputação, e seu próprio registro DMARC.

Leia o cabeçalho Authentication-Results antes de adivinhar

Quando uma mensagem falha, o servidor receptor registra por quê. No Gmail, "Mostrar original" expõe o cabeçalho Authentication-Results, e ele diz mais do que qualquer painel.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provedor-email.net;
  dkim=pass header.d=provedor-email.net;
  dmarc=fail (p=NONE) header.from=exemplo.com.br

Leia da esquerda para a direita. SPF passou para bounce.provedor-email.net. DKIM passou para provedor-email.net. DMARC falhou porque o cabeçalho From diz exemplo.com.br e nenhum domínio que passou bata com isso.

A nota (p=NONE) mostra a política que o receptor viu. Em none essa mensagem foi entregue assim mesmo. Em reject teria rejeitado com um erro 5.7.x, e o remetente teria ficado sabendo de um cliente.

Dois checks pegam a maioria desses casos. Confirme que o valor header.d no resultado DKIM é seu domínio. Depois confirme que o domínio smtp.mailfrom é seu domínio ou um subdomínio dele.

SPF tem um limite de lookups que DMARC expõe

SPF permite dez lookups DNS por avaliação. Cada include: por um provedor gasta alguns deles, e includes aninhados gastam mais. Ultrapasse dez e SPF retorna um erro permanente, que conta como falha.

Equipes com cinco ou seis ferramentas de envio atingem isso sem notar, porque falhas de SPF eram invisíveis antes de relatórios DMARC. Uma vez que relatórios rua chegam, o padrão é óbvio: uma origem de repente falhando SPF em todos os receptores no dia em que alguém adicionou outro include:.

Essa é mais uma razão para confiar em alinhamento DKIM como o caminho primário. DKIM sobrevive a maioria dos encaminhamentos, não tem orçamento de lookups, e é atado à mensagem em vez de ao IP conectador. Mantenha SPF válido, mas não construa seu passe DMARC só nele.

O que DMARC não vai fazer

DMARC previne spoofing de domínio exato. Ele não pára domínios parecidos (examp1e.com.br), não julga conteúdo, e não corrige uma má reputação de remetente. Um domínio perfeitamente alinhado que envia a listas compradas ainda cai em spam.

Também não substitui monitoramento. Alinhamento pode quebrar silenciosamente: uma mudança de DNS remove um seletor DKIM, um provedor gira as chaves, uma nova ferramenta começa a enviar sem seu conhecimento. Relatórios é como você descobre antes de seus usuários.

Trate o registro DMARC como qualquer outra config em produção. Ele pertence a version control, mudanças passam por review, e a caixa de correio rua precisa de um dono.

Antes de publicar o registro

Passe por isso uma vez. Leva menos de uma hora para um domínio único.

• Liste cada sistema que envia mail como seu domínio: produto, cobrança, suporte, CRM, marketing, convites de calendário.

• Confirme que cada um assina DKIM com seu domínio, não do fornecedor.

• Defina um return-path customizado onde o provedor permite.

• Escolha um destino rua que alguém vá ler.

• Comece em p=none, e coloque a data em que você planeja revisar no calendário.

• Verifique spam rate no Google Postmaster Tools semanalmente durante o rollout.

Para onde ir daqui

Se você nunca olhou seus relatórios, publique p=none com um endereço rua hoje e leia o que chega em duas semanas. O primeiro relatório quase sempre nomeia pelo menos um remetente que ninguém lembrava. O próximo passo concreto é decidir qual daqueles você mantém.