Publicar um registro DMARC em modo de observação é a parte fácil, e a maioria das empresas para por aí. O registro existe, os relatórios chegam — e ninguém os lê, porque avançar parece arriscado.

O receio é legítimo: uma política restritiva mal configurada bloqueia mensagens legítimas da própria empresa, e o efeito aparece imediatamente. Mas ficar permanentemente em observação também tem custo: o domínio continua podendo ser usado por terceiros para enviar mensagens em seu nome, e provedores de destino tratam domínios sem política efetiva com menos confiança.

Este guia mostra como fazer a travessia com segurança. Ele pressupõe que os registros já estão publicados — se esse não for o caso, o ponto de partida é o artigo sobre e-mails caindo no spam.

O que a política realmente faz

Uma recapitulação curta, porque ela explica o risco.

A política do DMARC diz ao servidor de destino o que fazer quando uma mensagem que se apresenta como sendo do seu domínio falha na verificação. Existem três níveis:

Política	O que o destino faz	Quando usar
p=none	Entrega normalmente e envia relatórios	Fase de observação e diagnóstico
p=quarantine	Encaminha para spam	Depois de corrigir as falhas legítimas
p=reject	Recusa a mensagem	Quando todas as origens estão mapeadas

O ponto que gera o risco: a verificação não distingue falsificação de configuração incompleta. Uma mensagem legítima enviada por uma ferramenta que você esqueceu de autorizar falha exatamente como falharia uma tentativa de fraude — e uma política restritiva trata as duas da mesma forma.

É por isso que a ordem importa: mapear tudo primeiro, endurecer depois.

Alinhamento: o conceito que causa mais surpresa

Vale isolar este ponto, porque ele explica falhas que parecem inexplicáveis.

Passar no SPF ou no DKIM não basta. O DMARC exige que o domínio verificado corresponda ao domínio que o destinatário vê no remetente.

O caso típico: uma ferramenta de terceiros envia em seu nome usando a infraestrutura dela. Tecnicamente, a verificação passa — mas usando o domínio do fornecedor, não o seu. Do ponto de vista do DMARC, isso não é alinhamento, e a mensagem é reprovada.

A correção normalmente é oferecida pelo próprio fornecedor: configurar um subdomínio seu apontando para a infraestrutura dele, de modo que a verificação aconteça no seu domínio. É um procedimento comum e documentado pela maior parte das plataformas — mas alguém precisa executá-lo, e é o passo mais esquecido em implantações de DMARC.

Há ainda o grau de alinhamento, que pode ser configurado como estrito ou relaxado. O relaxado é o padrão e o recomendado na maior parte dos casos, porque aceita subdomínios do mesmo domínio principal. O estrito exige correspondência exata e costuma quebrar configurações legítimas sem trazer ganho proporcional.

Os relatórios: onde está a informação que falta

Esta é a razão de existir a fase de observação, e é a etapa que quase todo mundo pula.

O DMARC permite receber relatórios periódicos dos provedores de destino, informando quais origens enviaram mensagens usando o seu domínio e se elas passaram na verificação. Eles chegam em formato técnico, compactado, e não foram feitos para leitura direta — mas existem serviços que os interpretam e apresentam de forma legível.

O que os relatórios revelam:

• Ferramentas legítimas esquecidas. É o achado mais comum: sistemas que enviam em nome da empresa e que ninguém lembrava — emissor de nota fiscal, plataforma de vendas, sistema interno, formulário do site.
• Configurações incompletas, com origens que passam em um mecanismo e falham no outro.
• Tentativas de falsificação, com origens desconhecidas usando o seu domínio.
• Efeito de encaminhamento, que merece explicação própria.

O primeiro item é a razão pela qual não se deve endurecer a política sem ler os relatórios: você provavelmente não sabe todas as origens que enviam em nome do seu domínio. Empresas com alguns anos de operação costumam descobrir três ou quatro que ninguém mapearia de memória.

Encaminhamento: a falha que não é falha

Ao ler os relatórios pela primeira vez, quase todo mundo encontra falhas que parecem preocupantes e não são.

Quando alguém encaminha uma mensagem sua, o servidor que faz a entrega final deixa de ser um dos autorizados no SPF — e a verificação por esse mecanismo falha. Não há nada de errado com a mensagem: é uma limitação conhecida do funcionamento do SPF.

O DKIM, por assinar a própria mensagem, tende a sobreviver ao encaminhamento — desde que o conteúdo não seja alterado. É por isso que ter DKIM corretamente configurado é o que torna seguro endurecer a política: mesmo quando o SPF falha por encaminhamento, a assinatura mantém a mensagem válida.

A conclusão prática: antes de avançar de política, confirme que o DKIM está assinando todas as origens legítimas, e não apenas a principal.

A travessia, passo a passo

Um roteiro conservador que evita bloqueios acidentais:

Fase 1 — Observar e mapear

1. Mantenha a política em observação e configure o recebimento de relatórios.
2. Aguarde ao menos algumas semanas, para cobrir ciclos mensais de envio — sistemas de cobrança e relatórios periódicos só aparecem no período em que rodam.
3. Liste todas as origens que aparecem nos relatórios.
4. Classifique cada uma: legítima e autorizada, legítima e não autorizada, desconhecida.

Fase 2 — Corrigir

1. Autorize as origens legítimas que estavam faltando, ajustando SPF e configurando DKIM para cada uma.
2. Peça aos fornecedores a configuração que permite alinhamento pelo seu domínio.
3. Descontinue origens que não deveriam mais existir — ferramentas antigas que ninguém usa continuam autorizadas e são uma exposição.
4. Confirme, em novos relatórios, que as falhas legítimas desapareceram.

Fase 3 — Endurecer gradualmente

1. Avance para quarentena, que envia as falhas para o spam em vez de recusá-las — o erro ainda é recuperável.
2. Se a ferramenta permitir, aplique a política a uma fração do tráfego primeiro, ampliando aos poucos.
3. Acompanhe os relatórios e eventuais reclamações internas por algumas semanas.
4. Só então avance para rejeição.

O passo mais importante dessa fase é o segundo: aplicar a política gradualmente a uma porcentagem do tráfego permite descobrir problemas afetando poucas mensagens em vez de todas. Nem toda implantação usa esse recurso, e ele reduz bastante o risco.

Subdomínios: a porta que fica aberta

Um ponto frequentemente esquecido e explorado em tentativas de fraude.

A política definida para o domínio principal pode não se aplicar automaticamente aos subdomínios da forma que você espera. É possível — e recomendável — definir explicitamente uma política para subdomínios.

Isso importa porque subdomínios inexistentes também podem ser usados em tentativas de falsificação. Um domínio com política restritiva no nível principal e permissiva nos subdomínios deixa uma porta aberta.

A recomendação: defina a política de subdomínios explicitamente e, para os subdomínios que não enviam e-mail, torne isso claro na configuração. Subdomínios que enviam legitimamente — como o de campanhas de marketing, tratado no artigo sobre entregabilidade em automação de marketing — precisam da configuração completa.

Erros que causam bloqueio

1. Avançar sem ler os relatórios. É a causa número um de e-mails legítimos bloqueados.
2. Ir direto para rejeição, pulando a quarentena. O erro deixa de ser recuperável.
3. Esquecer origens sazonais. Um sistema que envia apenas no fechamento do mês não aparece em relatórios de duas semanas.
4. Configurar alinhamento estrito sem necessidade, quebrando subdomínios legítimos.
5. Publicar mais de um registro DMARC, o que invalida a configuração — vale a mesma regra do SPF.
6. Não monitorar depois de endurecer. Novas ferramentas contratadas passam a falhar silenciosamente.

O último merece rotina: toda nova ferramenta que envia e-mail em nome da empresa precisa ser autorizada antes de entrar em uso. Com política restritiva ativa, uma contratação feita pelo time de marketing sem avisar a TI resulta em mensagens recusadas.

Manutenção contínua

Depois da travessia, o trabalho não termina — mas fica leve:

• Leitura mensal dos relatórios, procurando origens novas ou desconhecidas.
• Revisão trimestral do SPF, removendo fornecedores descontinuados.
• Autorização prévia de qualquer nova ferramenta de envio.
• Verificação após trocas de provedor, que alteram origens de envio.
• Confirmação de que os relatórios continuam chegando — se pararem, você perdeu a visibilidade sem perceber.

Conclusão

Ficar permanentemente em modo de observação é a situação mais comum e a menos útil: o domínio continua exposto a uso indevido e os relatórios se acumulam sem serem lidos.

A travessia segura tem uma ordem definida: observar por tempo suficiente para capturar ciclos completos, mapear todas as origens, corrigir as legítimas que faltam, avançar para quarentena e só então rejeitar. O recurso de aplicar a política a uma fração do tráfego reduz bastante o risco de cada etapa.

E o pré-requisito que sustenta tudo: DKIM configurado em todas as origens legítimas, porque é ele que mantém a mensagem válida quando o SPF falha por encaminhamento. Conheça as soluções de e-mail corporativo da TBF Host e verifique se a sua configuração atual cobre todas as origens de envio.

Perguntas frequentes

O que significa p=none no DMARC?

É a política de observação: o servidor de destino entrega a mensagem normalmente mesmo quando a verificação falha, mas envia relatórios informando o que aconteceu. Serve para mapear todas as origens que enviam em nome do domínio antes de aplicar qualquer restrição.

Como sair de p=none sem bloquear meus e-mails?

Observando por algumas semanas para capturar ciclos completos de envio, mapeando todas as origens que aparecem nos relatórios, autorizando as legítimas que faltam, avançando para quarentena — onde o erro ainda é recuperável — e só então para rejeição. Se possível, aplicando a política a uma fração do tráfego primeiro.

Por que meus e-mails legítimos falham no DMARC?

As causas mais comuns são falta de alinhamento, quando uma ferramenta de terceiros passa na verificação usando o domínio dela em vez do seu, e origens legítimas não autorizadas no SPF ou sem DKIM configurado. Encaminhamentos também geram falhas de SPF, mas essas não indicam problema real.

O que são os relatórios DMARC e como usá-los?

São relatórios periódicos enviados pelos provedores de destino, informando quais origens enviaram mensagens usando o seu domínio e se passaram na verificação. Chegam em formato técnico compactado, e existem serviços que os interpretam. Eles revelam ferramentas legítimas esquecidas, configurações incompletas e tentativas de falsificação.

Por que falhas aparecem nos relatórios quando alguém encaminha meu e-mail?

Porque no encaminhamento o servidor que faz a entrega final deixa de ser um dos autorizados no SPF, e a verificação por esse mecanismo falha. Não há nada de errado com a mensagem. O DKIM, por assinar o conteúdo, tende a sobreviver ao encaminhamento — por isso ele é essencial antes de endurecer a política.

Devo usar alinhamento estrito ou relaxado?

O relaxado é o padrão e o recomendado na maior parte dos casos, porque aceita subdomínios do mesmo domínio principal. O estrito exige correspondência exata e costuma quebrar configurações legítimas sem trazer ganho proporcional de proteção.

Preciso configurar DMARC para subdomínios?

É recomendável definir a política de subdomínios explicitamente, inclusive para os que não enviam e-mail. Subdomínios inexistentes também podem ser usados em tentativas de falsificação, e um domínio com política restritiva no nível principal e permissiva nos subdomínios deixa uma porta aberta.

O que fazer depois de endurecer a política?

Manter uma rotina leve: leitura mensal dos relatórios procurando origens novas, revisão trimestral do SPF removendo fornecedores descontinuados, autorização prévia de qualquer nova ferramenta de envio, verificação após trocas de provedor e confirmação de que os relatórios continuam chegando.