O cliente recebe um e-mail com o logotipo da sua empresa, o endereço financeiro@suaempresa.com.br no remetente e um boleto anexado. O valor é plausível, o texto é educado e a data de vencimento é amanhã. Ele paga. Dias depois, liga para cobrar a nota fiscal de um serviço que nunca contratou.
Esse golpe não exige invadir nada. Basta que o domínio da empresa não diga aos provedores de e-mail como tratar uma mensagem falsificada. É exatamente isso que o DMARC faz. Este guia explica o que é, como ele se encaixa com SPF e DKIM, o que Gmail e Outlook já exigem, o que mudou no padrão em 2026 e, principalmente, como chegar à política de rejeição sem derrubar o e-mail legítimo da própria empresa.
O que é DMARC?
DMARC é a sigla de Domain-based Message Authentication, Reporting and Conformance, algo como autenticação, relatório e conformidade de mensagens com base no domínio. Na prática, é uma linha de texto publicada no DNS do domínio, no endereço _dmarc.suaempresa.com.br, que faz duas coisas.
A primeira é dar uma instrução: quando chegar uma mensagem que diz vir do seu domínio e não passar na verificação, o provedor deve entregá-la normalmente, mandá-la para o spam ou recusá-la. A segunda é pedir relatórios: os provedores passam a enviar ao dono do domínio um resumo de quem mandou e-mail em nome dele e se essas mensagens passaram ou falharam.
O DMARC não funciona sozinho. Ele se apoia em dois registros mais antigos, SPF e DKIM, e acrescenta a peça que faltava a eles: a ligação com o endereço que o destinatário vê no campo "De".
Qual a diferença entre SPF, DKIM e DMARC?
Os três costumam ser citados juntos, e com razão: o DMARC depende dos outros dois. Mas cada um prova uma coisa diferente.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| O que prova | Que o servidor que enviou está autorizado pelo domínio | Que a mensagem foi assinada pelo domínio e não foi alterada | Que o domínio do "De" bate com o domínio que passou no SPF ou no DKIM |
| Onde fica | Registro TXT no domínio | Chave pública em registro TXT, assinatura no cabeçalho | Registro TXT em _dmarc.dominio |
| O que ele não resolve | Não olha o endereço que o destinatário vê | Sozinho, não diz o que fazer quando falha | Não autentica nada por conta própria |
| Sem ele | Qualquer servidor parece autorizado | Mensagem alterada no caminho passa despercebida | O provedor decide sozinho, e o golpista usa o seu "De" |
Elaborado pela Alliance Comunicação com base na RFC 9989 (IETF, 2026).
O ponto que costuma passar despercebido está na primeira linha da tabela. SPF e DKIM podem passar para um domínio qualquer, inclusive o do golpista, enquanto o campo "De" mostra o seu. O DMARC é o que exige que os dois domínios coincidam. Sem ele, um e-mail perfeitamente autenticado para golpe-qualquer.com pode exibir financeiro@suaempresa.com.br no remetente.
Como o DMARC funciona por dentro?
Quando uma mensagem chega, o provedor do destinatário lê o domínio do campo "De" e busca o registro DMARC dele. Em seguida, verifica se o SPF ou o DKIM passaram e se o domínio que passou está alinhado com o do "De". Basta um dos dois alinhado para o DMARC passar.
O alinhamento pode ser relaxado ou estrito. No modo relaxado, que é o padrão, um subdomínio conta: uma mensagem assinada por news.suaempresa.com.br se alinha com suaempresa.com.br. No estrito, os domínios precisam ser idênticos. Se a mensagem falha, o provedor consulta a política publicada e decide.
Os relatórios agregados fecham o ciclo. Eles chegam em formato XML no endereço indicado no registro e mostram, por servidor de origem, quantas mensagens passaram e quantas falharam. É a leitura desses relatórios que permite endurecer a política sem susto.
Por que o boleto falso com o seu domínio é problema seu?
Porque o prejuízo do golpe recai sobre a relação com o cliente. Ele recebeu uma mensagem que exibia o seu domínio e pagou acreditando nisso. Mesmo que a empresa não tenha culpa pela fraude, quem atende a reclamação, explica o ocorrido e lida com a desconfiança é ela.
O DMARC em p=reject fecha a porta mais simples desse golpe: a falsificação direta do domínio. Ele não impede que o golpista registre um domínio parecido, como suaempresa-boletos.com, nem que ele invada a caixa de e-mail de um funcionário. Para esses casos, a defesa é outra, e o artigo sobre por que o clique no phishing vai acontecer mostra o que precisa falhar do lado do login.
Há um detalhe que pouca empresa considera: o golpista não precisa usar o domínio principal. Um subdomínio que não existe, como cobranca.suaempresa.com.br, também pode ser falsificado. O padrão atual tem uma instrução própria para isso, que aparece mais abaixo.
O que Gmail e Outlook já exigem de DMARC?
Além da segurança, existe a entrega. Os dois maiores provedores de e-mail pessoal passaram a exigir DMARC de quem envia em volume, e quem não cumpre vê a mensagem ir para o spam.
Repare em duas coisas. A primeira: as duas regras aceitam p=none. Cumprir a exigência dos provedores não significa estar protegido contra falsificação; significa só ter o registro publicado. A segunda: o limite de 5 mil por dia parece alto, mas uma empresa que soma e-mail marketing, notificações do sistema e faturamento chega lá mais rápido do que imagina. O artigo sobre o que o Gmail exige do e-mail marketing detalha as demais regras, como o descadastro com um clique.
O que mudou no padrão DMARC em 2026?
Por quase dez anos, o DMARC foi descrito pela RFC 7489, de 2015, um documento informativo. Em maio de 2026, o IETF publicou a RFC 9989, que substitui a 7489 e coloca o DMARC, pela primeira vez, no caminho de padrão oficial (Standards Track). Boa parte dos tutoriais ainda não foi atualizada.
- A tag pct saiu. Ela permitia aplicar a política a só uma porcentagem das mensagens. A RFC 9989 dedica um apêndice à remoção dela.
- Entrou a tag t (modo de teste). Com
t=y, o dono do domínio avisa que está testando a política, e o provedor deve aplicar um nível abaixo do publicado: quarantine vira none, reject vira quarantine. - Entrou a tag np. Ela define a política para subdomínios que não existem, justamente o caso de
cobranca.suaempresa.com.br. - O p=none ganhou nome. A RFC chama de modo de monitoramento o estado em que a política é none e o dono recebe os relatórios agregados.
Na prática, o registro continua começando com v=DMARC1, e um registro antigo bem feito segue funcionando. O que muda é a forma recomendada de fazer a transição gradual: em vez de pct=10, o caminho do padrão novo é o t=y.
Como criar o registro DMARC?
O registro é um TXT com nome _dmarc no DNS do domínio. Um ponto de partida seguro é: v=DMARC1; p=none; rua=mailto:dmarc@suaempresa.com.br. Ele não bloqueia nada, mas passa a trazer os relatórios. As tags que mais importam estão na tabela.
| Tag | Para que serve | Exemplo |
|---|---|---|
| v | Versão; precisa vir primeiro e o único valor válido é DMARC1 | v=DMARC1 |
| p | Política para o domínio: none, quarantine ou reject | p=reject |
| sp | Política para subdomínios existentes | sp=reject |
| np | Política para subdomínios que não existem (RFC 9989) | np=reject |
| rua | Endereço que recebe os relatórios agregados | rua=mailto:dmarc@suaempresa.com.br |
| adkim / aspf | Alinhamento do DKIM e do SPF: r (relaxado, padrão) ou s (estrito) | adkim=r |
| t | Modo de teste: aplica um nível abaixo da política publicada (RFC 9989) | t=y |
RFC 9989, seção 4.7 (IETF, maio de 2026).
No Google Workspace e no Microsoft 365
Nas duas plataformas, o DMARC não é configurado dentro do painel do e-mail: é um registro no DNS do domínio. O que se faz no painel é ativar a assinatura DKIM do próprio Workspace ou do Microsoft 365, que gera a chave a ser publicada no DNS. Ative o DKIM primeiro, confirme que as mensagens saem assinadas e só depois publique o DMARC.
No Registro.br ou em outro provedor de DNS
O registro vai onde o DNS do domínio está hospedado, que nem sempre é onde o domínio foi registrado. Se o domínio usa os servidores de DNS do Registro.br, a entrada TXT é criada lá; se usa Cloudflare, provedor de hospedagem ou outro serviço, é nesse painel. Na dúvida, descubra quem responde pelo DNS antes de criar o registro. O artigo sobre em nome de quem registrar o domínio mostra por que esse acesso precisa estar com a empresa.
Quem envia e-mail em nome do seu domínio?
Este é o passo que os tutoriais pulam e o que mais derruba e-mail legítimo. Antes de qualquer política mais dura, a empresa precisa saber todos os sistemas que mandam mensagem com o domínio dela no remetente. Quase sempre há mais do que se imagina:
- o e-mail corporativo (Google Workspace, Microsoft 365 ou outro);
- a ferramenta de e-mail marketing;
- o CRM, que envia propostas e sequências;
- o emissor de nota fiscal e o sistema de cobrança, que mandam boleto e NF;
- o help desk ou a plataforma de atendimento;
- a loja virtual e o sistema de pedidos;
- formulários do site que enviam confirmação;
- sistemas internos ou impressoras que disparam alertas.
Cada um desses remetentes precisa passar no SPF ou no DKIM com alinhamento. Em geral, a ferramenta oferece a configuração de domínio próprio, com um registro DKIM a publicar. Quem fica de fora vai falhar no DMARC, e quando a política virar reject, a nota fiscal ou o boleto verdadeiro deixa de chegar. O irônico é que o sistema de cobrança, o mais visado pelo golpe, é também o que mais costuma ser esquecido.
Como sair do p=none até o p=reject sem perder e-mail?
O caminho é uma escada, e cada degrau só é subido quando os relatórios mostram que nenhum remetente legítimo está falhando. Não há prazo universal: uma empresa com dois sistemas de envio chega ao reject bem antes de uma com dez.
1. Publique p=none com relatórios
Use o registro de partida e deixe os relatórios chegarem. Eles vêm em XML, difícil de ler a olho; um serviço de leitura de relatórios DMARC ou uma planilha montada pela equipe técnica ajuda a transformar em lista de remetentes.
2. Faça o inventário e corrija cada remetente
Compare os servidores que aparecem nos relatórios com a lista da seção anterior. Para cada sistema legítimo que falha, configure o domínio próprio e o DKIM. Para cada origem desconhecida, investigue: pode ser um sistema esquecido ou alguém falsificando o domínio.
3. Suba para quarantine
Quando os relatórios mostram os remetentes legítimos passando, publique p=quarantine. Para uma transição mais cautelosa, o padrão novo permite acrescentar t=y, que pede ao provedor para aplicar um nível abaixo durante o teste.
4. Chegue ao reject e trate os subdomínios
Com a quarentena estável e sem reclamação de e-mail perdido, publique p=reject. Sem sp e np, os subdomínios herdam a política principal. Se algum subdomínio legítimo precisar de sp mais branda, declare np=reject à parte, porque na falta dele os subdomínios inexistentes seguem o sp.
Como validar e testar o DMARC?
- Confira o registro publicado com
nslookupoudigno nome_dmarcdo domínio. Deve existir um único registro DMARC. - Envie uma mensagem para uma conta Gmail e abra a opção de mostrar o original. O Gmail exibe se SPF, DKIM e DMARC passaram.
- Repita com cada sistema do inventário: uma nota fiscal de teste, uma campanha de teste, um chamado do help desk.
- Acompanhe os relatórios agregados por algumas semanas antes de cada mudança de política.
- Reveja o inventário a cada ferramenta nova. Contratou um sistema que envia e-mail? Ele entra na lista antes de começar a mandar.
Quais os erros mais comuns com DMARC?
- Ficar em p=none para sempre. Cumpre a regra de Gmail e Outlook, mas não protege o cliente da falsificação.
- Ir direto para p=reject. Sem inventário, o boleto e a nota fiscal verdadeiros começam a ser recusados.
- Publicar dois registros DMARC. Se a consulta devolve mais de um, a RFC 9989 manda descartar todos, e o domínio fica como se não tivesse DMARC.
- Não ler os relatórios. O endereço do rua recebe arquivos que ninguém abre, e as falhas passam despercebidas.
- Afrouxar o sp e esquecer o np. Sem np, os subdomínios inexistentes seguem o sp, e um sp=none abre espaço para o golpista inventar um subdomínio.
- Seguir tutorial antigo com pct. A tag foi removida na RFC 9989; a transição gradual agora usa t=y.
Se a empresa não tem equipe técnica dedicada, o inventário e a leitura dos relatórios são o trabalho que mais pesa. É o tipo de projeto em que uma equipe de tecnologia e segurança acelera: mapeia os remetentes, configura o DKIM de cada sistema e conduz a escada até o reject.
Por onde começar hoje
- Rode o teste do nslookup e veja se o domínio tem DMARC e com qual política.
- Se não tiver, publique o registro de partida com p=none e um endereço para os relatórios.
- Liste todos os sistemas que enviam e-mail com o domínio, começando por cobrança e nota fiscal.
- Configure o DKIM em cada um e acompanhe os relatórios até não haver falha legítima.
- Suba para quarantine e depois para reject, com np=reject para os subdomínios inexistentes.
O DMARC é uma das poucas medidas de segurança que custam pouco e protegem o cliente, não só a empresa. E se você quer enxergar onde a comunicação digital da empresa como um todo precisa de atenção, o diagnóstico de marketing gratuito da Alliance leva cerca de 30 minutos e aponta as prioridades.