Um registo DMARC bloqueia mesmo o spoofing ou apenas as campanhas que a equipa de marketing continua a enviar a partir de um router mal alinhado? DMARC (Domain-based Message Authentication, Reporting and Conformance) é um registo DNS que indica aos servidores recetores, Gmail, Outlook, Yahoo, que política aplicar a um email que falha o alinhamento SPF ou DKIM. Publicado sozinho, sem os dois protocolos que supervisiona, não bloqueia nada. No final de 2025, 83,9% dos domínios analisados pela Red Sift não tinham qualquer registo DMARC publicado, numa amostra de 73,3 milhões de domínios. De seguida detalha-se a sintaxe exata do registo, as três políticas disponíveis e a leitura dos relatórios rua.
O que é o DMARC?
Um domínio que publica SPF e DKIM sem _dmarc deixa que cada servidor recetor decida por conta própria como agir perante uma falha de autenticação. Alguns rejeitam a mensagem, outros entregam-na na mesma marcando-a como suspeita, outros não alteram nada. O DMARC fecha essa ambiguidade: o proprietário do domínio fixa ele próprio a política, num registo TXT publicado no host _dmarc.oseudominio.com. O standard está documentado na RFC 7489 desde 2015, mas a sua adoção continua desigual. As grandes empresas cotadas ultrapassam os 85% de cobertura nas análises por país, enquanto a média mundial fica abaixo dos 15% (Red Sift, 2025). A diferença deve-se sobretudo à complexidade percebida da sintaxe, raramente à sua dificuldade real.
Porque é que o DMARC é importante
Um domínio sem política DMARC deixa que qualquer pessoa envie um email assinado com o seu nome, sem qualquer mecanismo a avisar o destinatário. É o vetor principal do phishing por usurpação de marca, aquele que leva um contabilista a clicar numa fatura falsa supostamente enviada pelo seu próprio fornecedor. O painel de um SaaS de email marketing pode mostrar uma boa capacidade de entrega sem dizer nada sobre o que um terceiro envia fora dessa plataforma: a capacidade de entrega medida internamente e a superfície de exposição ao spoofing externo continuam a ser duas medidas diferentes. Um domínio visado por uma campanha de spoofing vê também a sua reputação de envio degradar-se junto dos filtros do Gmail e do Outlook, um sinal que depois surge nas métricas do Google Postmaster Tools, mesmo quando nenhum email fraudulento sai realmente da infraestrutura da empresa. Os filtros baseiam-se no nome de domínio visível, não no IP de envio.
Como o DMARC se apoia no SPF e no DKIM
O DMARC não substitui nem o SPF nem o DKIM. Supervisiona-os, apoiando-se nos seus resultados. O SPF verifica se o servidor emissor está autorizado a enviar em nome do domínio indicado no envelope MAIL FROM. O DKIM assina o conteúdo da mensagem com uma chave criptográfica, o que permite detetar qualquer alteração em trânsito. Um email pode falhar num e passar no outro: o DMARC exige que pelo menos um dos dois tenha êxito e, sobretudo, que o domínio verificado por esse protocolo corresponda ao domínio mostrado no cabeçalho From, aquele que o destinatário vê. Essa correspondência tem um nome, o alinhamento.
O alinhamento pode ser estrito ou relaxado, definido pelas etiquetas aspf e adkim do registo DMARC. No modo relaxado, o valor predefinido, um subdomínio como newsletter.empresa.com alinha-se com empresa.com. No modo estrito, só é aceite uma correspondência exata. A maioria das plataformas de envio terceiras publica os seus próprios registos SPF e assina com as suas próprias chaves DKIM, seja um router transacional ou um CRM externo. Sem uma configuração explícita do subdomínio de envio no DNS, esses emails falham o alinhamento mesmo quando são perfeitamente legítimos. É a causa mais frequente de uma taxa de rejeição DMARC que sobe logo depois de se adicionar uma nova ferramenta de marketing, sem que nenhuma campanha de phishing tenha qualquer responsabilidade nisso.
Criar um registo DMARC: sintaxe e exemplo
Configurar um registo DMARC começa sempre por escolher o host DNS certo. O registo publica-se como um TXT normal, no host _dmarc da zona DNS do domínio, nunca no domínio raiz. Eis um exemplo comentado, pensado para uma implementação progressiva:
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@empresa.com; ruf=mailto:ruf@empresa.com; aspf=r; adkim=r; sp=none
Cada etiqueta tem um papel preciso. v fixa a versão do protocolo, sempre DMARC1. p define a política aplicada ao domínio. pct fixa a percentagem de mensagens não conformes abrangidas por essa política. rua indica o endereço que recebe os relatórios agregados diários. ruf indica o endereço dos relatórios forenses, raramente respeitado pelos grandes fornecedores de correio. sp fixa a política aplicada aos subdomínios que não têm registo próprio.
Para criar e verificar o registo:
- Identificar todos os emissores legítimos do domínio (ESP, CRM, faturação, apoio técnico) e confirmar que cada um publica SPF ou assina com DKIM.
- Criar um endereço dedicado aos relatórios rua.
- Publicar o registo TXT em _dmarc com p=none durante pelo menos duas a quatro semanas, apenas observando.
- Ler os primeiros relatórios agregados para identificar as fontes que falham o alinhamento e corrigi-las uma a uma.
- Subir a política por etapas, pct=25, depois pct=50, depois pct=100, antes de passar a quarantine e depois a reject.
Um registo mal formado ou com uma etiqueta duplicada geralmente não impede a sua publicação no DNS. O mesmo acontece com um endereço rua inválido: bloqueia é, silenciosamente, a receção dos relatórios, o que torna a monitorização impossível sem que nenhum alerta avise o administrador.
As três políticas DMARC e a implementação progressiva
Para a etiqueta p são possíveis três valores. none não altera nada na entrega, apenas o relatório rua regista a falha. quarantine envia o email não conforme para a pasta de spam do destinatário ou equivalente. reject bloqueia o envio com uma rejeição SMTP devolvida ao remetente, antes de chegar à caixa de entrada.
Passar diretamente a p=reject sem uma fase de observação bloqueia também emails legítimos não alinhados, uma lista de distribuição que reescreve o cabeçalho From, um router CRM externo mal configurado, um serviço de faturação subcontratado. A implementação recomendada começa com none em observação, sobe gradualmente até quarantine e termina na rejeição completa. Uma política reject a 100% abre também caminho ao BIMI, o logótipo de marca mostrado na caixa de entrada do Gmail e do Yahoo.
Ler os relatórios DMARC: rua e ruf
Os relatórios rua chegam em XML comprimido. Cada fornecedor de correio que recebeu mensagens do domínio envia geralmente um por dia, com a lista dos IPs emissores, o volume processado, o resultado do alinhamento SPF e DKIM e a política aplicada. A leitura manual continua viável para um domínio com dois ou três emissores. A partir de uma dezena de subdomínios ativos e várias plataformas de envio, o volume de linhas XML torna pouco realista uma leitura linha a linha sem uma ferramenta de parsing dedicada.
Os relatórios ruf, por sua vez, detalham um email concreto que falhou, cabeçalhos completos incluídos. O Gmail e o Yahoo não os enviam, por razões ligadas à privacidade dos dados pessoais contidos nesses cabeçalhos. Apenas uma minoria de fornecedores de correio mais pequenos ainda os respeita. O guia completo para ler um relatório DMARC agregado sem enganos detalha o parsing XML campo a campo.
O que o DMARC não cobre
O DMARC protege exatamente o domínio publicado no registo, nada mais. Um email enviado a partir de empresa-suporte.com em vez de empresa.com, um domínio visualmente parecido registado por um atacante, passa completamente ao lado de todo o dispositivo: nenhum SPF, DKIM ou DMARC cobre um domínio que a empresa não possui. Este typosquatting continua a ser o ponto cego mais frequente das implementações DMARC, incluindo as já configuradas em p=reject. A lista completa das limitações, desde o conteúdo da mensagem até à proteção de domínios não registados, merece ser conhecida antes de se anunciar internamente que um domínio está agora protegido.
Quem deve publicar um registo DMARC em 2026
Desde 1 de fevereiro de 2024, o Google exige uma autenticação SPF e DKIM alinhada e um registo DMARC pelo menos em p=none, para qualquer remetente que envie 5.000 ou mais mensagens em 24 horas para contas Gmail pessoais. A Microsoft seguiu a partir de 5 de maio de 2025 no Outlook.com, Hotmail e Live.com: acima do mesmo limiar, os emails não autenticados são rejeitados ao nível SMTP com o Enhanced Status Code 550 5.7.15, em vez de redirecionados para a pasta de spam. A complaint rate comunicada através dos feedback loops dos fornecedores de correio deve manter-se abaixo de 0,3%, com um limiar recomendado abaixo de 0,1% para evitar uma filtragem mais rigorosa.
O Google esclarece que o limiar de 5.000 mensagens é avaliado numa janela móvel de 24 horas: um remetente que o ultrapasse uma única vez fica sujeito às mesmas exigências que se o atingisse todos os dias.
Abaixo desse limiar, nada obriga legalmente a publicar DMARC. Mas um domínio B2B ativo, mesmo com pouco volume, continua a ser um alvo preferencial para a usurpação: a fatura fraudulenta dirigida a um fornecedor não se preocupa com o volume de envio da vítima. Mais uma ferramenta na pilha, dirão alguns ao descobrir que também é preciso vigiar a taxa de hard bounce e a reputação de envio associadas ao domínio. O DMARC não substitui nada do que já existe. Sobretudo, consome dados que já estão no Google Postmaster Tools. Limpar a lista de distribuição, uma prática elementar de list hygiene, antes de apertar a política rumo ao DMARC reject, evita confundir um endereço que rejeita com uma falha de alinhamento mal diagnosticada, uma confusão que atrasa a implementação em várias semanas na maioria dos casos observados.
Há quanto tempo não é lido o relatório rua deste domínio?
