Como configurar o DMARC sem interromper e-mails legítimos

Se você procura como configurar o DMARC, a orientação inicial é esta: não vá direto para p=reject. Comece com uma política de monitoramento, confirme que cada remetente autorizado passa em SPF ou DKIM com o alinhamento necessário e aumente as restrições por etapas. Isso pode reduzir a falsificação sem colocar desnecessariamente em risco faturas, redefinições de senha ou mensagens de uma ferramenta SaaS que alguém esqueceu de mencionar.

Muitos guias apresentam um cenário mais simples que a realidade. Um domínio envia pelo Microsoft 365, a cobrança usa um aplicativo externo, o marketing trabalha com outra plataforma e a copiadora do depósito ainda envia documentos digitalizados. Esquecer um remetente pode transformar uma medida de segurança em interrupção. Para configurar o e-mail do domínio, consulte como configurar e-mail no seu domínio e o guia mais abrangente de e-mail empresarial.

Este guia trata da operação do DMARC: observar, reunir evidências, corrigir o alinhamento e só então aplicar restrições. O processo exige atenção aos riscos reais, não uma receita automática.

O que o DMARC realmente faz

O DMARC publica no DNS uma política que informa aos servidores destinatários o tratamento solicitado para mensagens que usam seu domínio no remetente visível, mas não passam na autenticação com alinhamento. Ele se apoia em SPF e DKIM. O DMARC passa quando pelo menos um desses mecanismos passa na verificação e está alinhado ao domínio visível de From.

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Ele permite publicar uma política para mensagens que falham no DMARC e solicitar relatórios sobre o uso do seu domínio como remetente. A especificação básica é a RFC 7489. Uma autenticação bem-sucedida não garante que o conteúdo seja seguro.

Para entender como configurar o DMARC, comece por esta regra:

• O SPF pode passar e o DMARC falhar se o domínio autenticado não estiver alinhado a From e o DKIM também não fornecer um resultado válido e alinhado.
• O DKIM pode passar e o DMARC falhar pelo mesmo motivo, caso o SPF não forneça o resultado válido e alinhado que falta.
• O DMARC passa se SPF ou DKIM passar na verificação com o alinhamento necessário. Um dos dois basta.

As orientações do Google citadas exigem SPF, DKIM e um registro DMARC com política mínima p=none para remetentes em massa. Para passar no DMARC, SPF ou DKIM precisa passar com alinhamento a From. Confira os requisitos atuais e a quem se aplicam nas perguntas frequentes sobre as diretrizes de envio do Google.

O que verificar antes de configurar o DMARC

Antes de publicar uma política DMARC, confira a configuração de envio. SPF incorreto, DKIM ausente ou assinaturas com outro domínio podem causar falhas no DMARC. Encontrar esses problemas é útil; aplicar restrições antes de resolvê-los pode interromper mensagens legítimas.

Comece por três verificações.

1. SPF: publique um único registro SPF válido para cada domínio realmente usado no remetente do envelope. Respeite o limite de 10 mecanismos ou modificadores que provocam consultas DNS, incluindo avaliações aninhadas; não é um limite do total de consultas DNS.
2. DKIM: ative-o nas plataformas de envio compatíveis. Use chaves de 2048 bits quando o provedor e a configuração permitirem.
3. Inventário: liste todos os serviços que enviam com seu domínio: plataforma de e-mail, CRM, cobrança, suporte, formulários, scanners e ferramentas de marketing.

Para domínios no TrekMail, consulte os registros DNS necessários e como adicionar um domínio. As verificações disponíveis podem detectar registros publicados e erros comuns, como SPF duplicado, mas não substituem a análise de mensagens reais e das respostas DNS externas.

Exemplo: o aplicativo de cobrança envia de billing@yourdomain.com, mas assina com o domínio do fornecedor e usa o return-path dele. SPF e DKIM passam para esses domínios, porém nenhum está alinhado ao seu. O DMARC falha para seu domínio.

Esse desalinhamento explica muitas interrupções após a ativação de restrições DMARC.

Etapa 1: publicar uma política DMARC de monitoramento

Em uma implantação gradual, costuma ser útil começar observando. Uma política p=none solicita relatórios sem pedir quarentena ou rejeição pelo DMARC. Os relatórios não são garantidos e os destinatários ainda podem aplicar filtros locais.

Crie um registro TXT em _dmarc.yourdomain.com com este valor:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

O mesmo registro no formato de arquivo de zona, não um registro adicional:

_dmarc  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

O exemplo segue o formato da RFC 7489. Use um endereço ou alias dedicado e monitorado, com controles de acesso e tratamento adequados. Os relatórios agregados são arquivos XML que podem se acumular rapidamente. Um destino externo pode exigir autorização DNS no domínio que recebe os relatórios.

Após a publicação, confira as respostas DNS e a autenticação de mensagens enviadas por cada serviço. As perguntas frequentes sobre e-mails que chegam ao spam também ajudam a investigar falhas, distinguindo os efeitos do encaminhamento de outros problemas.

Etapa 2: ler os relatórios e identificar os remetentes

Essa etapa costuma ser ignorada. Os relatórios trazem dados dos destinatários participantes, não um inventário completo de todas as mensagens. Eles ajudam a investigar serviços autorizados, configurações incorretas e possíveis falsificações, mas não classificam sozinhos o tráfego como legítimo ou abusivo.

Os relatórios DMARC normalmente mostram:

• Os IPs de origem que enviaram mensagens com seu domínio
• Os resultados do SPF
• Os resultados do DKIM
• O alinhamento desses resultados ao domínio de From
• O tratamento aplicado pelo destinatário

Separe dois grupos para investigar.

Primeiro, remetentes autorizados que falham no alinhamento e precisam de ajustes. Segundo, fontes ainda não identificadas. Um IP desconhecido pode pertencer a um encaminhador ou a uma infraestrutura compartilhada; isso, por si só, não comprova falsificação.

Os casos abaixo são ilustrativos; os resultados dependem da configuração e da mensagem:

Com muitos domínios, cada ferramenta SaaS nova exige revisar o envio. Por isso algumas agências avaliam a hospedagem de e-mail para múltiplos domínios e uma gestão mais organizada das caixas. Mudar de plataforma não elimina essas tarefas.

Etapa 3: corrigir o alinhamento, não apenas a autenticação

Configurar corretamente o DMARC exige um resultado válido e alinhado. SPF ou DKIM pode passar com outro domínio sem contribuir para o DMARC, mas basta que o outro mecanismo passe com alinhamento. No modo relaxado, o domínio autenticado precisa compartilhar o domínio organizacional com From; não basta qualquer relação entre domínio pai e filho.

A RFC 7489 define o alinhamento relaxado pelo mesmo domínio organizacional entre o domínio autenticado pelo SPF ou assinante do DKIM e o domínio de RFC5322.From. As perguntas frequentes do Google indicam que um mecanismo válido e alinhado basta para o DMARC, embora remetentes em massa precisem configurar os dois métodos.

Estas são as correções mais comuns:

• Plataformas de marketing: configure a assinatura DKIM com seu domínio.
• Tratamento de devoluções: configure um return-path ou domínio de devoluções próprio se o fornecedor permitir e confira o alinhamento.
• Microsoft 365: ative o DKIM no domínio personalizado antes das restrições, se esse for o mecanismo escolhido para alinhamento.
• Envio gerenciado do TrekMail: publique exatamente os registros SPF e DKIM indicados para o serviço de saída que você realmente utiliza.

A configuração deve corresponder ao serviço de envio real. Planos cobrados por usuário também podem oferecer ferramentas DNS. O TrekMail propõe separar as caixas do mecanismo de envio, com SMTP gerenciado nos planos pagos que o incluem ou SMTP próprio no Nano, conforme as condições do plano. Configure e verifique o provedor SMTP escolhido.

Na oferta descrita, o Nano usa seu provedor SMTP e os planos pagos incluem SMTP gerenciado. O TrekMail apresenta preços a partir de $3.50 por mês, teste de 14 dias nos planos pagos sujeito às suas condições e Nano sem custo nem cartão conforme a oferta aplicável. Confira os requisitos do teste e os recursos atuais na página de preços do TrekMail.

Etapa 4: avaliar uma política de quarentena

Depois que os remetentes autorizados passam com alinhamento e os fluxos relevantes foram validados, você pode avaliar a quarentena. Ela já é uma política restritiva: solicita tratamento especial para mensagens que falham no DMARC. O destinatário decide a aplicação; não há garantia de uma pasta de spam específica, de recuperação da mensagem ou de adequação a todos os domínios.

Substitua a política anterior por esta, sem publicar as duas:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Por que avaliar a quarentena antes da rejeição?

• Ela pode reduzir a exposição a algumas tentativas de falsificação.
• Pode permitir investigar erros com um tratamento menos restritivo, sem garantir a recuperação das mensagens.
• Permite testar uma etapa restritiva, com avaliação de riscos e acompanhamento dos fluxos críticos.

Por quanto tempo observar? Depende dos fluxos. Algumas semanas podem servir de referência inicial para domínios pequenos; 30 dias para domínios com muitos fornecedores também são apenas uma referência, não uma comprovação de prontidão.

Confira ainda sistemas pouco usados: um plugin do WordPress, um ambiente de testes do CRM, uma copiadora antiga ou um fornecedor que envia mensalmente. Processos trimestrais ou excepcionais podem exigir mais tempo e testes específicos. A quarentena não oferece uma margem de segurança garantida.

Etapa 5: passar à rejeição após validar os fluxos

A política p=reject solicita ao destinatário recusar mensagens que falham no DMARC, em vez de apenas tratá-las como suspeitas. Pode reduzir a falsificação direta do domínio, mas não bloqueia todas as formas de fraude.

A política dessa etapa normalmente tem este formato:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

Segundo a RFC 7489, p=reject solicita a rejeição de mensagens que falham no DMARC. Destinatários podem aplicar exceções e políticas locais; não há garantia de bloqueio universal nem de entrega das mensagens legítimas na caixa de entrada.

Antes de avançar, confirme estes pontos:

• O provedor principal passa em SPF ou DKIM com alinhamento
• As ferramentas de marketing e transacionais também passam em um mecanismo alinhado
• Você revisou várias semanas de relatórios e testou os fluxos críticos pouco frequentes
• Você entende as falhas restantes e suas consequências

Depois, continue analisando os relatórios disponíveis e testando mudanças. O DMARC faz parte da gestão contínua do e-mail.

Erros comuns que interrompem mensagens

Além das políticas, é preciso conhecer os remetentes. Um serviço esquecido, SPF duplicado, DKIM desativado ou a autenticação padrão de um fornecedor podem causar falhas quando as restrições são aplicadas. A política de monitoramento, sozinha, não cria essas falhas.

• Aplicar restrições antes de ter SPF ou DKIM válido e alinhado
• Publicar vários registros SPF em vez de consolidar as autorizações em um único registro válido
• Supor que passar no SPF significa passar no DMARC
• Esquecer fornecedores de baixo volume cujas mensagens podem ser críticas
• Ir diretamente da ausência de DMARC para p=reject
• Enviar relatórios para uma caixa que ninguém acompanha

Com aliases e encaminhamento, o SPF pode falhar e o DKIM ainda permitir que o DMARC passe, desde que a assinatura continue válida e alinhada e os dados assinados sejam preservados após a canonicalização. Não ignore essas falhas automaticamente. Consulte o encaminhamento com aliases de e-mail e o e-mail seguro para empresas para ampliar a análise operacional.

Lista prática para configurar o DMARC

Esta lista resume uma implantação gradual. Ela organiza as verificações, mas não garante uma transição sem incidentes.

1. Revise todos os sistemas que enviam com seu domínio.
2. Publique um SPF válido para cada domínio de envelope correspondente.
3. Ative e verifique o DKIM em cada plataforma de envio compatível.
4. Publique v=DMARC1; p=none; rua=mailto:....
5. Investigue os relatórios e compare-os com o inventário de remetentes.
6. Confirme um mecanismo válido e alinhado para cada remetente autorizado.
7. Avalie p=quarantine após testar os fluxos.
8. Revise novamente os relatórios e o funcionamento real.
9. Passe para p=reject quando os testes e a avaliação de riscos justificarem.

Conclusão: configurar o DMARC com uma implantação controlada

Uma sequência comum começa com p=none, cruza os relatórios com o inventário, corrige autenticação e alinhamento e depois avalia p=quarantine e p=reject. Ela pode reduzir riscos ao aplicar restrições contra falsificação, mas exige testes e acompanhamento.

Com um domínio, a coordenação pode ser simples; com dezenas ou centenas, os processos precisam ser mais organizados. Conforme o plano e a oferta atual, o TrekMail oferece domínios personalizados, caixas IMAP, catch-all, encaminhamento, ferramentas de migração e SMTP próprio ou incluído. A cópia por IMAP não substitui a mudança de MX nem migra automaticamente todos os aplicativos. Confira limites e preços: essas ferramentas não dispensam a configuração do DMARC nem garantem economia em relação à cobrança por usuário.

Essa é a abordagem operacional de como configurar o DMARC: observar, verificar os remetentes e depois aplicar restrições. Baseie as decisões nos relatórios disponíveis e em testes reais, não em suposições.