Uma política p=none não bloqueia nenhuma mensagem, ao passo que uma política p=reject mal preparada bloqueia mensagens legítimas. Entre as duas, o DMARC deixa de fora o nome de apresentação e os domínios semelhantes; uma conta comprometida também lhe escapa. Em suma: o protocolo trava a falsificação exata do domínio do remetente e mais nada, enquanto a sua implementação expõe a e-mails de clientes perdidos e a remetentes terceiros esquecidos. As limitações compensam-se com outras ferramentas; os riscos controlam-se com uma implementação progressiva.
O painel da ferramenta de emailing mostra «tudo OK» e as campanhas acabam no spam: a autenticação é um dos primeiros sítios a examinar. Quanto à fraude, o FBI contabiliza 3,05 mil milhões de dólares de perdas ligadas ao Business Email Compromise (24 768 queixas) no relatório IC3 2025, contra 2,77 mil milhões em 2024 (21 442 queixas).
O que o DMARC controla
O DMARC apoia-se no SPF e no DKIM. Uma mensagem passa no controlo se um dos dois passar e se o domínio autenticado estiver alinhado com o do cabeçalho From, campo definido pela RFC 5322. Este alinhamento é o ponto que as equipas descobrem em último lugar: um SPF válido para o domínio de um prestador não basta quando o endereço apresentado usa o seu. Em caso de falha, o destinatário aplica a política publicada pelo proprietário do domínio: quarantine envia para o spam, reject recusa a mensagem, none não faz nada.
Duas definições fixam o rigor desse alinhamento. Por defeito é «relaxed»: mail.exemplo.pt alinha com exemplo.pt, porque partilham o mesmo domínio organizacional. No modo «strict», definido por adkim=s para o DKIM e aspf=s para o SPF, os dois nomes têm de ser idênticos. O modo strict fecha portas; também parte qualquer prestador que assine com um subdomínio, o que raramente se descobre antes da passagem a reject.
A própria norma delimita o seu âmbito. Desde maio de 2026, é a RFC 9989 (via Standards Track do IETF) que define o DMARC e substitui as RFC 7489 (março de 2015) e 9091 (2021). A sua secção 2.2 precisa que o DMARC não trata os domínios visualmente próximos nem o abuso do nome legível do remetente, e a secção 2.4 deixa os ataques por display name fora do âmbito: o texto de 2015 já dizia o mesmo.
Display name e domínios semelhantes: dois pontos cegos documentados
Uma mensagem apresentada como «Apoio ao Cliente Banco X» e enviada de apoio@banco-x-seguranca.com passa no DMARC sem dificuldade. O domínio de envio pertence ao atacante; publicou lá o seu próprio SPF e a sua própria chave DKIM, por isso SPF, DKIM e DMARC estão todos em verde. O controlo incide sobre o domínio técnico; o nome que o cliente de e-mail põe em destaque não é examinado.
Os domínios semelhantes (typosquatting, hífenes acrescentados, extensão diferente) seguem a mesma lógica: o seu registo protege o seu domínio, não os que se parecem com ele. A resposta passa por vigiar os registos de domínios próximos do seu e por filtragem à receção.
Uma conta comprometida passa em todos os controlos
Uma caixa cujas credenciais vazaram envia a partir da infraestrutura certa, com a assinatura certa. A porta de entrada é muitas vezes um phishing ou um vazamento de dados; o DMARC não tem então nada a assinalar, porque a mensagem é autêntica. A autenticação multifator e o alerta de ligações invulgares ficam a montante, fora do perímetro do protocolo.
Reencaminhamentos e listas de distribuição: o alinhamento quebra pelo caminho
Quando um alias de empresa ou uma lista de distribuição retransmite uma mensagem, o IP do relé não consta do SPF do domínio de origem; o SPF falha, portanto, em geral. Resta o DKIM, que sobrevive enquanto o conteúdo assinado não for alterado. Uma lista Mailman ou Listserv que acrescente um rodapé invalida a assinatura: a mensagem legítima falha nos dois controlos.
A RFC 9989 (secção 7.4) dá o exemplo de um banco cujos clientes indicaram um endereço de antigo aluno, do tipo jones@alumni.example.edu, que reencaminha para outra caixa: a mensagem chega a partir do IP do relé, ausente do SPF do remetente (RFC 5321 de 2008, MailFrom), salvo reescrita. As assinaturas DKIM (RFC 6376 de 2011) mantêm-se em geral válidas enquanto o corpo da mensagem não for alterado. Uma lista de distribuição que acrescente um rodapé invalida-as.
A RFC 9989 (secção 7.4, que remete para a RFC 7960 de 2016 sobre listas de distribuição) tira daqui duas indicações: um domínio em p=reject não deve contar só com o SPF e deve assinar com DKIM; um domínio cujos utilizadores escrevem para listas de distribuição públicas não deveria publicar p=reject. O protocolo ARC (Authenticated Received Chain, RFC 8617 de julho de 2019) serve para preservar o resultado de autenticação original, desde que o relé o tenha ativado.
Subdomínios: quem prevalece, o domínio ou o subdomínio?
O subdomínio prevalece assim que publica o seu próprio registo; caso contrário, herda do domínio principal. A RFC 9989 formula-o em duas regras. O destinatário procura primeiro um registo no domínio exato do From e depois sobe a árvore DNS (DNS tree walk, secção 4.10, limitado a 8 consultas DNS): um registo próprio do subdomínio prevalece, portanto, sobre o do domínio principal. E, sem a etiqueta sp=, a política p= do domínio principal aplica-se aos subdomínios.
Consequência prática: um _dmarc.newsletter.exemplo.pt que ficou em p=none depois de um teste deixa esse perímetro em simples monitorização enquanto exemplo.pt está em reject. No sentido inverso, um sp=none no domínio principal abre todos os subdomínios sem registo; útil durante a auditoria, a retirar depois. A etiqueta sp= é ignorada num registo publicado num subdomínio. Desde a RFC 9091, retomada pela RFC 9989, uma etiqueta np= regula ainda o caso dos subdomínios que não existem no DNS.
p=none, o modo de monitorização que dá uma falsa sensação de segurança
O registo existe e a verificação de conformidade passa; nada é bloqueado. A Google precisa na sua página de implementação, consultada a 27 de outubro de 2026, que em p=none as mensagens são entregues normalmente. Um domínio que lá fica durante anos continua a aceitar mensagens falsificadas.
p=reject: os e-mails legítimos que desaparecem
Depois de passar a reject, um domínio vê recusado qualquer remetente cujo SPF e DKIM não estejam alinhados. Os recursos humanos enviam os recibos de vencimento por uma ferramenta externa, o apoio passa por um helpdesk e a faturação por um módulo SaaS: cada um escreve em nome do domínio e será recusado no dia da passagem se não estiver alinhado. A Google diz-o sem rodeios: as mensagens que falham no controlo são rejeitadas e nunca entregues. Em quarantine, vão parar, na melhor das hipóteses, à pasta de spam. Os relatórios rua do dia seguinte listam então os IP cujas mensagens falharam, incluindo os que ninguém tinha inventariado. Daí o interesse de passar por quarantine e de assinalar a fase de ensaio com t=y antes de qualquer reject.
Os prestadores de envio criam a armadilha mais frequente. Num IP partilhado ou dedicado, o SPF valida o domínio do prestador; o alinhamento DMARC depende então de uma assinatura DKIM em nome do seu domínio, salvo Return-Path personalizado. Sem ela, a campanha falha logo na primeira passagem a reject. A chave DKIM publica-se sob um seletor dedicado, da forma seletor._domainkey.exemplo.pt; a assinatura deve levar o domínio do From.
Erros de TXT e limite de 10 consultas DNS do SPF
Um erro de configuração basta para neutralizar o DMARC sem alerta. O DNS não o assinala: o registo publica-se sem validação, pelo que uma gralha na zona só se revela na leitura dos relatórios, alguns dias depois. Um registo cortado em duas cadeias mal juntas, umas aspas tipográficas coladas de um processador de texto ou um ponto e vírgula esquecido entre duas etiquetas são suficientes. Dois registos DMARC no mesmo nome? A RFC 9989 descarta então todos os registos encontrados nesse local (secção 4.10). Um v=DMARC1 mal escrito faz ignorar o registo inteiro; uma etiqueta desconhecida é ignorada sem alerta; um erro em rua= priva de relatórios sem partir nada de visível. Um endereço de relatórios alojado noutro domínio exige ainda um registo de autorização nesse domínio (RFC 9990).
Quanto ao SPF, a RFC 7208 (secção 4.6.4) limita a avaliação a 10 consultas DNS: include, a, mx, ptr, exists e redirect contam, ip4 e ip6 não. As consultas sem resultado estão limitadas a 2. Acima disso, o resultado é permerror (limite já presente na RFC 4408 de abril de 2006) e o SPF deixa de contribuir para o DMARC. Cada ferramenta acrescentada por um include aproxima o domínio desse limiar.
Limites e riscos num quadro
| Caso | Porquê | O que fazer |
|---|---|---|
| Display name falsificado | O DMARC controla o domínio do From; o nome apresentado escapa-lhe | Filtragem antiphishing à receção, sensibilização |
| Domínio semelhante | Domínio de terceiros com os seus próprios SPF, DKIM e DMARC | Vigilância de domínios próximos, registos defensivos |
| Conta comprometida | A mensagem é autêntica | MFA, alertas de ligação |
| Reencaminhamento, lista de distribuição | O SPF falha; o DKIM falha se o conteúdo mudar | DKIM em todos os fluxos, ARC |
| Subdomínio | Herança de p=; um registo próprio prevalece |
Inventário, sp= assumido |
p=none duradouro |
Nenhuma ação sobre as mensagens que falham | Calendário de passagem a quarantine |
p=reject cedo demais |
Remetente terceiro não alinhado | Inventário, relatórios rua, ensaio em t=y |
| SPF acima de 10 consultas | permerror, o SPF deixa de contar | Retirar os include inúteis, assinar com DKIM |
| Erro no TXT | Registo ou etiqueta ignorados | Um único registo, revisão da sintaxe |
Passar de none a reject sem perder e-mails
O percurso faz-se em três tempos: inventariar os remetentes, observar em none e depois endurecer por patamares via quarantine antes de reject. Tudo começa pelo inventário dos remetentes: ferramenta de emailing, CRM, helpdesk, vencimentos, faturação, servidores aplicacionais. As equipas esquecem sempre um; os relatórios agregados rua servem para o encontrar, já que listam cada IP que enviou em nome do domínio com o respetivo resultado SPF e DKIM.
Os passos são sempre os mesmos: p=none, leitura dos relatórios, quarantine e depois reject. Na ajuda do Google Workspace, a Google recomenda configurar SPF e DKIM pelo menos 48 horas antes de publicar o DMARC, ficar em p=none durante uma semana com leitura diária dos relatórios e passar depois a quarantine numa pequena percentagem de mensagens: 10 % para uma organização pequena, 1 % para uma grande (página «Implementação DMARC recomendada»). Um registo inicial parece-se com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@exemplo.pt, publicado em TXT em _dmarc.exemplo.pt. Atenção: a etiqueta pct= da RFC 7489 já não existe na RFC 9989, que nota que era aplicada de forma muito desigual fora dos valores 0 e 100 e a substitui por t=y (ensaio) ou t=n. A própria RFC 9989 recomenda publicar p=none durante pelo menos um mês, apoiando-se nos relatórios agregados.
O tempo de cada passo depende do número de fluxos: com poucas fontes de envio, uma semana de relatórios pode chegar para as inventariar; com 20 ferramentas, os remetentes esquecidos descobrem-se relatório após relatório. Durante a subida, um sp= distinto permite endurecer o domínio principal enquanto os subdomínios não auditados ficam em none.
Gmail, Yahoo e a entregabilidade
Desde 1 de fevereiro de 2024, a Google exige aos remetentes de mais de 5000 mensagens por dia para o Gmail um SPF e um DKIM válidos, mais uma política DMARC; pode ficar em none. A taxa de spam apresentada no Google Postmaster Tools deve manter-se abaixo de 0,30 %, com um objetivo abaixo de 0,10 % (diretrizes da Google para remetentes). A Yahoo, que aplica as suas regras aos remetentes em massa desde fevereiro de 2024, também pede um DMARC no mínimo em none, com um domínio From alinhado com SPF ou DKIM (boas práticas da Yahoo). O detalhe do lado do Gmail encontra-se no artigo sobre os requisitos do Gmail para remetentes.
O DMARC abre, portanto, a porta da caixa de entrada sem fixar a reputação do remetente. Essa reputação depende da taxa de queixas e das devoluções: um domínio em reject que envia para uma lista cheia de endereços mortos alimenta as devoluções definitivas e prejudica a sua entregabilidade. Passar uma amostra da lista por uma ferramenta de verificação antes da próxima campanha mostra essa taxa antes de o Gmail a medir.
O seu próximo relatório rua contém uma fonte de envio que ninguém na equipa reconhece?
