Os chamados de falha de DMARC às vezes chegam quando a parte difícil parece resolvida. SPF e DKIM estão publicados. A política DMARC finalmente usa p=quarantine ou p=reject. Então uma mensagem legítima é encaminhada e não chega ao destino esperado. Não é necessariamente falsificação ou spam: ela pode ter seguido uma rota que a configuração não tratava corretamente.
Essa é uma dificuldade da falha de DMARC durante o encaminhamento. A mensagem pode ser legítima, mas o salto intermediário altera o contexto de entrega e o destinatário pode deixar de confiar nela. Quem só verifica a presença de SPF e DKIM pode achar o comportamento aleatório. Examinar a rota, as assinaturas e o alinhamento ajuda a identificar causas concretas e escolher a correção.
Para a configuração geral, comece por e-mail empresarial. Se você já usa encaminhamento, veja também encaminhamento de e-mail.
O que uma falha de DMARC realmente significa
Uma falha de DMARC significa que a mensagem não obteve SPF aprovado e alinhado nem uma assinatura DKIM válida e alinhada com o domínio do From visível. Autenticação sozinha não basta. DMARC verifica a relação entre o domínio autenticado e o apresentado ao destinatário, conforme o modo de alinhamento configurado.
DMARC se apoia em SPF e DKIM. O princípio básico descrito na especificação histórica RFC 7489 é que basta uma destas condições:
- SPF passa e seu domínio se alinha com o domínio do From no cabeçalho.
- Uma assinatura DKIM passa e seu domínio se alinha com o domínio do From no cabeçalho.
Parece simples. Na prática, a investigação de uma falha de DMARC se complica quando três conceitos são confundidos:
- Autenticação: SPF ou DKIM passou?
- Alinhamento: o domínio aprovado se alinha com o domínio do From no cabeçalho?
- Preservação no encaminhamento: as alterações do intermediário invalidaram a assinatura?
SPF pode passar e ainda ocorrer uma falha de DMARC. DKIM pode passar e ainda ocorrer uma falha de DMARC. Se nenhuma identidade aprovada está alinhada com o domínio necessário, DMARC falha.
Por que o encaminhamento pode causar falhas de DMARC
O encaminhamento pode provocar uma falha de DMARC porque muda a rota e, às vezes, o conteúdo. SPF depende da conexão; DKIM depende da integridade dos dados assinados. Um encaminhamento pode afetar uma verificação, e certas modificações ou configurações podem afetar ambas.
Veja uma rota comum:
- Um remetente envia a partir de
sender.com. - Uma caixa de correio ou um gateway intermediário recebe a mensagem.
- Esse sistema a encaminha automaticamente para Gmail, Outlook ou outro destino.
O destinatário final já não vê o IP original como cliente SMTP. Ele vê o IP do serviço de encaminhamento.
Essa mudança pode explicar o início de uma falha de DMARC.
SPF costuma ser afetado primeiro
SPF, definido na RFC 7208, verifica se o IP conectado está autorizado a enviar pelo domínio do remetente do envelope.
Após o encaminhamento, a conexão vem do intermediário. Se ele mantém o remetente do envelope e seu IP não está autorizado, SPF falha. SRS pode reescrever esse remetente e permitir SPF para o domínio do intermediário, mas isso não garante alinhamento DMARC com o From original.
Rota original:
sender.comenvia pelo IP A autorizado. SPF passa.
Rota encaminhada: o intermediário envia pelo IP B. O destinatário verificasender.comem relação ao IP B, não autorizado neste exemplo. SPF falha.
Essa falha de SPF não garante uma falha de DMARC. Se uma assinatura DKIM válida e alinhada sobreviver, DMARC pode continuar passando. Por isso, teste DKIM nas rotas indiretas reais.
DKIM pode preservar a autenticação da mensagem
DKIM, definido na RFC 6376, assina cabeçalhos selecionados e o corpo. A validade da assinatura não depende do IP que encaminha a mensagem. Assim, DKIM pode fornecer uma via de aprovação DMARC quando SPF deixa de servir.
Para isso, as duas condições precisam ser atendidas:
- A assinatura continua válida após o encaminhamento.
- O domínio
d=se alinha com o domínio do From visível.
Se uma delas falha e SPF não passa com alinhamento, pode ocorrer outra falha de DMARC.
Alguns intermediários fazem alterações que podem invalidar a assinatura:
- Adicionar
[EXTERNAL]ao assunto - Acrescentar avisos ou rodapés jurídicos
- Reescrever delimitadores MIME
- Mudar quebras de linha ou espaços
A canonicalização relaxada tolera algumas alterações de formato, não todas. O resultado depende dos dados assinados e das modificações realizadas. Uma falha de DMARC em uma mensagem encaminhada não prova falsificação: também pode indicar um problema de implementação.
A falta de alinhamento também causa falhas sem encaminhamento
Uma falha de DMARC não exige encaminhamento. Ela pode ocorrer quando um serviço SaaS autentica com seu próprio domínio e nenhuma identidade aprovada se alinha com o seu. A mensagem pode ser legítima e mesmo assim falhar DMARC.
Vale revisar esse ponto em cada serviço externo.
Exemplo:
- From:
billing@yourcompany.com - Return-Path:
bounce.vendor-mail.com - DKIM:
d=vendor-mail.com
SPF pode aprovar uma identidade de vendor-mail.com. DKIM pode passar para vendor-mail.com. Neste exemplo, DMARC mostra uma falha de DMARC porque nenhuma identidade autenticada se alinha com yourcompany.com.
Configure autenticação de domínio personalizada conforme as opções do fornecedor. Uma via aprovada e alinhada basta para DMARC; DKIM alinhado é especialmente útil nos encaminhamentos. Uma assinatura do fornecedor não provoca a falha se outra via atende aos requisitos.
Se você está reorganizando uma configuração com muitos aliases, leia alias de domínio ou caixa de correio. Documentar o caminho de cada endereço ajuda a localizar problemas de autenticação.
Como diagnosticar a falha pelos cabeçalhos
Os cabeçalhos permitem investigar muitos casos de falha de DMARC sem adivinhar. Comece por Authentication-Results acrescentado por um servidor receptor confiável, não por qualquer cabeçalho copiado. Compare resultados e domínios de SPF, DKIM e From.
Peça os cabeçalhos completos ao destinatário e procure algo assim:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=pass header.i=@sender.com header.s=mail;
dmarc=pass header.from=sender.comEsse resultado é compatível com encaminhamento que fez SPF falhar enquanto DKIM manteve a aprovação DMARC. Confirme a rota nos cabeçalhos; o resultado sozinho não comprova chegada à caixa de entrada.
Este resultado exige investigação:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=fail header.i=@sender.com;
dmarc=fail header.from=sender.comPode ser uma falha de DMARC relacionada ao encaminhamento: a conexão mudou e DKIM deixou de validar. Verifique se o intermediário modificou a mensagem ou se a assinatura já era inválida antes desse salto.
| Resultado do cabeçalho | O que pode indicar | O que fazer |
|---|---|---|
spf=fail, dkim=pass, dmarc=pass | Resultado compatível com encaminhamento | Confirme a rota e monitore; não altere a política apenas por SPF. |
spf=fail, dkim=fail, dmarc=fail | Encaminhamento com modificações ou DKIM inválido | Investigue assinatura, canonicalização e alterações na mensagem. |
dkim=pass com domínio d= não alinhado | Possível desalinhamento de fornecedor ou relay | Revise todas as vias e configure DKIM personalizado se necessário. |
spf=permerror | SPF inválido, duplicado ou com consultas excessivas | Audite autorizações e consultas; considere subdomínios. O achatamento exige manter os IPs atualizados. |
arc=pass | Cadeia ARC criptograficamente válida | Avalie a confiança nos intermediários; não comprova alinhamento nem aceitação. |
Como reduzir falhas em mensagens encaminhadas
Você não pode impedir todos os encaminhamentos. Para reduzir a falha de DMARC em mensagens legítimas, projete e teste essas rotas: DKIM válido e alinhado, SPF mantido e intermediários que preservem os dados assinados. Nenhuma combinação garante o tratamento final do destinatário.
1. Inclua DKIM em todas as rotas de envio
Para manter uma via DMARC durante o encaminhamento, configure DKIM alinhado em cada fluxo legítimo: newsletters, suporte, faturamento e outras mensagens. Verifique a validade após os intermediários relevantes.
A assinatura precisa se alinhar com o From visível. Se a mensagem vem de yourdomain.com, pode usar yourdomain.com ou um subdomínio compatível com o modo configurado. O alinhamento estrito exige correspondência exata.
No TrekMail, comece pelos registros DNS obrigatórios. Estado amarelo ou vermelho merece revisão; estado correto também não substitui um teste de encaminhamento.
2. Avalie a canonicalização DKIM relaxada
A canonicalização simples tolera menos mudanças de formato. Certas alterações podem invalidar DKIM e contribuir para uma falha de DMARC. A relaxada admite determinadas mudanças de espaços e normalização de cabeçalhos previstas na especificação; ela não é o mesmo que alinhamento DMARC relaxado.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
c=relaxed/relaxed; h=from:to:subject:date:message-id; ...Isso não preserva necessariamente a assinatura quando um rodapé é acrescentado ao corpo. É uma tolerância de formato, não uma autorização para alterar livremente o conteúdo.
3. Revise as identidades usadas pelos fornecedores
Se o CRM, suporte ou newsletter assina com d=vendor.com, confira o alinhamento e se existe outra via aprovada e alinhada. Sem nenhuma, uma falha de DMARC pode ocorrer mesmo sem encaminhamento. Configure DKIM e remetente do envelope personalizados conforme o serviço; teste especialmente DKIM alinhado nas rotas indiretas.
4. Mantenha SPF dentro dos limites
SPF não falha apenas no encaminhamento. A RFC 7208 limita a 10 os termos que exigem consultas DNS durante a avaliação, incluindo os termos correspondentes aninhados. Ultrapassar o limite, não apenas atingi-lo, pode gerar permerror e remover SPF como via aprovada para DMARC.
dig +short TXT example.com
dig +short TXT _dmarc.example.comSe você acumulou Google, Microsoft, Mailgun, SendGrid, Zendesk e três provedores antigos em SPF, veja quais ainda enviam. Retire autorizações obsoletas após verificar e use subdomínios quando fizer sentido, sem remover remetentes legítimos às cegas.
5. Entenda os limites de SRS e ARC
SRS reescreve o remetente do envelope e pode permitir SPF para o domínio do intermediário, normalmente sem alinhamento com o From original. ARC preserva resultados anteriores que o destinatário pode avaliar conforme sua confiança nos seladores. Não transforma automaticamente falha DMARC em aprovação nem garante entrega. Esses mecanismos também não substituem DKIM bem configurado.
As recomendações do Google para encaminhamento contemplam um tratamento diferente do alinhamento DMARC e recomendam cabeçalhos ARC nos serviços de encaminhamento. Isso não muda a regra de aprovação do protocolo. Para operações em 2025 e 2026, confira sempre o escopo atual das regras do destinatário.
Se você administra muitas caixas encaminhadas, compare os recursos atuais da plataforma. O TrekMail oferece encaminhamento e orientação DNS conforme a configuração; consulte usar seu próprio SMTP e teste o alinhamento com o fornecedor escolhido.
Abordagem antiga e abordagem atual para vários domínios
Uma forma de lidar com a falha de DMARC era acumular ferramentas até perder o inventário de assinaturas. Outra separa claramente hospedagem de caixas, envio e estado do DNS para identificar e corrigir problemas. A visibilidade depende de manter essa documentação.
| Abordagem antiga | Abordagem atual |
|---|---|
| Cobrança por usuário pode incentivar aliases e encaminhamentos improvisados | Hospedagem multidomínio com tarifa fixa pode facilitar caixas reais, conforme as condições |
| Um SPF enorme para todos os serviços adicionados | DNS mantido, autorizações necessárias e subdomínios quando apropriado |
| Fornecedor assina com seu domínio sem revisar alinhamento | Cada remetente tem uma via autenticada e alinhada |
| Sem visibilidade até os usuários reclamarem | Verificações de DNS podem revelar erros a investigar |
| Caixas são transferidas por exportações e suposições | Migração IMAP integrada pode copiar dados das caixas; DNS e autenticação são revisados separadamente |
Esse é o enfoque operacional do TrekMail conforme seus recursos atuais: hospedar vários domínios, compartilhar armazenamento e comparar condições sem cobrança por usuário, com SMTP gerenciado ou externo. Veja hospedagem de e-mail multidomínio e imapsync para migração. IMAP não transfere DNS, reputação ou aplicativos.
O que fazer quando chega um chamado de DMARC
Diante de uma falha de DMARC, não mude automaticamente de reject para none. Primeiro determine se houve encaminhamento, DKIM inválido ou falta de alinhamento. Se um ajuste for necessário para proteger tráfego legítimo, faça inventário, analise os relatórios disponíveis, teste e prepare um plano de reversão.
- Obtenha os cabeçalhos completos e confirme qual servidor receptor confiável acrescentou os resultados.
- Verifique se SPF falhou na conexão de um intermediário conhecido.
- Confira se DKIM passou ou falhou e qual domínio
d=assinou. - Verifique o alinhamento da assinatura com o From visível.
- Procure
arc=passe avalie a confiança na cadeia se houve intermediário. - Revise SPF por excesso de consultas ou autorizações obsoletas.
No TrekMail, comece por adicionar um domínio para revisar registros e por não estou recebendo e-mails se a mensagem não aparece e não há rejeição visível.
Conclusão: investigue o projeto antes de tratar a falha como um mistério
Uma falha de DMARC recorrente não prova que a infraestrutura seja irrecuperável. Pode indicar dependência de SPF nas rotas indiretas, DKIM inválido ou não alinhado, ou alterações nos intermediários. Relatórios agregados ajudam, mas são parciais e não demonstram sozinhos a causa de cada mensagem.
A correção começa pelo básico: identidades alinhadas, testes de DKIM após cada rota relevante e manutenção de SPF. Inclua encaminhamentos e listas de discussão nos testes, em vez de presumir que preservam a mensagem.
Se você procura esse modelo, compare os recursos e condições atuais do TrekMail: hospedagem multidomínio com tarifa fixa, armazenamento compartilhado, migração IMAP de caixas, catch-all e opções de envio sem cobrança por usuário. A fonte anuncia planos pagos a partir de $3.50 por mês com cobrança anual e teste gratuito de 14 dias; confira o requisito de cartão. Nano é oferecido gratuitamente sem cartão. Consulte preços ou TrekMail. Preços e condições podem mudar.
Em resumo: se há encaminhamento no seu ambiente, a falha de DMARC merece testes específicos. Corrigir as causas identificadas pode melhorar a operação, mas passar DMARC não garante chegada à caixa de entrada.
