Uma falha no DMARC significa que a mensagem não obteve um resultado de autenticação válido e alinhado ao domínio de From. p=reject solicita rejeição; p=quarantine solicita tratamento restritivo. O destinatário pode aplicar exceções locais e não há garantia de uma pasta de spam específica. Investigue a configuração, sem excluir problemas de reputação que possam coexistir. Para o contexto geral, consulte e-mail empresarial para pequenas empresas.
Muitos casos envolvem alinhamento, encaminhamento que faz o SPF falhar, um fluxo sem DKIM ou SPF que excede seu limite de avaliação DNS. Leia os cabeçalhos, compare os domínios e identifique o mecanismo que não forneceu um resultado válido e alinhado.
Este guia traz uma tabela de diagnóstico, um processo de investigação e exemplos DNS que precisam ser adaptados e verificados, sem prometer uma solução definitiva para todos os casos.
O que uma falha no DMARC realmente significa?
O DMARC falha quando nenhum mecanismo fornece um resultado de autenticação válido e alinhado. SPF ou DKIM pode passar para outro domínio; se nenhum passa alinhado a From, o DMARC falha.
A especificação exige que SPF ou DKIM passe e que o domínio autenticado esteja alinhado ao domínio RFC5322 de From. Consulte a RFC 7489.
| Cenário | SPF | DKIM | DMARC | Interpretação | O que verificar |
|---|---|---|---|---|---|
| Os dois mecanismos falham | Fail | Fail | Fail | Possível erro de configuração, encaminhamento ou remetente não autorizado; não comprova abuso | Compare remetente, IP, DNS e assinatura com inventário e logs |
| Autenticação sem alinhamento | Pass, sem alinhamento | Pass, sem alinhamento | Fail | A autenticação passa, mas não está alinhada a From | Configure e verifique Return-Path próprio e DKIM alinhado |
| Mensagem encaminhada | Fail | Pass, alinhado | Pass | Possível comportamento esperado do encaminhamento | Confira assinatura válida e alinhada e preservação dos dados assinados após a canonicalização |
| Encaminhamento com alteração | Fail | Fail | Fail | Uma lista ou um relay pode ter alterado dados assinados; investigue a causa | Avalie o fluxo e exceções locais; ARC pode orientar o destinatário, não transformar falha em autenticação válida |
| SPF PermError | PermError | Fail ou ausente | Fail | Possível excesso do limite de avaliação SPF ou sintaxe incorreta | Audite o SPF; separar provedores exige usar de fato os novos domínios do envelope |
Etapa 1: verificar primeiro o alinhamento
Muitas falhas em mensagens legítimas vêm do alinhamento: o fornecedor autentica o próprio domínio, não o seu. Importa qual domínio passa, não apenas a aprovação na verificação.
Exemplo:
From do cabeçalho:
support@yourdomain.com
Return-Path:bounces.vendor.net
DKIM:d=vendor.net
A mensagem pode mostrar spf=pass e dkim=pass e ainda falhar no DMARC porque vendor.net não está alinhado a yourdomain.com.
Isso é comum em marketing, CRM, suporte e SMTP alternativo. Confira se o fornecedor oferece autenticação de domínio, Return-Path e domínio de devoluções personalizados ou DKIM com seu domínio. Um domínio de rastreamento ou links personalizados não substitui um Return-Path próprio.
Estes ajustes DNS são ilustrativos; use os valores do fornecedor real e ative e teste as funções:
Type: CNAME
Host: bounces
Value: yourvendor.example.net
Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net
Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.netO TrekMail oferece um processo de configuração DNS conforme o serviço escolhido. Consulte como adicionar um domínio e os registros DNS necessários. Se o SPF já existe, consolide autorizações válidas em um único registro por domínio real do envelope, sem adicionar um segundo SPF. O painel não comprova a autenticação de todos os fluxos.
Etapa 2: analisar os cabeçalhos originais
Abra o código-fonte da mensagem e identifique Authentication-Results, Return-Path e os domínios DKIM d=. Confie apenas nos resultados gerados pelo destinatário que avalia a mensagem; o remetente pode adicionar cabeçalhos falsos.
Use esta lista:
- Identifique o domínio visível de From.
- Confira se o SPF passou.
- Confira para qual domínio o SPF passou.
- Confira se o DKIM passou.
- Identifique o domínio assinante real do DKIM.
- Compare ambos com From.
Um exemplo de cabeçalho com falha no DMARC:
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dmarc=fail (p=reject) header.from=yourdomain.comInterprete com atenção:
O SPF passou para bounces.sendgrid.net, que compartilha o domínio organizacional sendgrid.net. A identidade DKIM indicada pertence a sendgrid.net, mas header.i não substitui o domínio d= da assinatura: verifique-o. From usa yourdomain.com. O resultado do destinatário indica que nenhum mecanismo forneceu autenticação alinhada.
Repita a verificação por fluxo. O e-mail transacional pode estar corrigido enquanto marketing, suporte ou aliases encaminhados ainda falham. Consulte também como configurar e-mail no seu domínio.
Etapa 3: investigar o encaminhamento separadamente
O encaminhamento pode fazer o SPF falhar: o relay envia de outro IP que pode não estar autorizado pelo domínio real de MAIL FROM. O DMARC ainda passa se o DKIM continuar válido e alinhado e os dados assinados forem preservados após a canonicalização.
Uma falha SPF em Google Groups, Outlook ou relays universitários não conta toda a história. Se o DKIM passa alinhado, o DMARC passa. Isso não garante conteúdo seguro nem entrega na caixa de entrada.
A RFC 7960 explica que manter o remetente original do envelope pode provocar falhas SPF; reescrevê-lo, por exemplo com SRS, não restaura o alinhamento ao From original. O DKIM pode fornecer o resultado alinhado, mas não resiste a todas as rotas. Consulte a RFC 7960.
Não adicione autorizações SPF indiscriminadamente tentando corrigir todos os encaminhamentos. Revise estes pontos:
- Assine com DKIM os fluxos de saída compatíveis e confira o alinhamento.
- Avalie o modo relaxado, que compara o domínio organizacional; o estrito exige uma necessidade concreta e testes.
- Investigue listas que alteram dados assinados e podem fazer o DKIM falhar e, sem outro resultado alinhado, o DMARC também.
Se você depende de encaminhamento, consulte a configuração de encaminhamento de e-mail e como encaminhar e-mails do domínio para o Gmail. O TrekMail oferece encaminhamento e opções SMTP conforme o plano, sem garantir preservação do DKIM nem entrega através de qualquer intermediário.
Etapa 4: auditar o SPF e erros permanentes
SPF PermError pode ocorrer quando o limite de dez mecanismos ou modificadores que provocam consultas DNS é excedido, incluindo avaliações aninhadas, ou há sintaxe e inclusões inválidas. Não é um limite do total de pacotes DNS. Um resultado permanente inutilizável não fornece SPF válido e alinhado ao DMARC.
Um SPF com muitas inclusões pode ter este formato:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~allA aparência não determina sua validade. Avalie inclusões aninhadas e redirecionamentos pelas regras SPF; contar apenas consultas visíveis não basta.
Consulte os registros com estas ferramentas:
dig +short txt yourdomain.com
nslookup -type=txt yourdomain.comEssas consultas não comprovam sozinhas um PermError. Audite os serviços ativos. Se você deixou de usar uma plataforma há seis meses, remova a autorização apenas depois de confirmar que é desnecessária. Pode ser útil avaliar provedores separados por subdomínios:
marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.comCada domínio pode ter sua própria avaliação SPF se o fornecedor o usar realmente em MAIL FROM. Criar o subdomínio não altera o envio: ative a configuração e teste SPF, DKIM e alinhamento a From antes de mover o fluxo.
A documentação do TrekMail explica como evitar SPF duplicado e consolidar autorizações em um TXT válido. Consulte a verificação do status DNS.
Etapa 5: distinguir erros de possíveis falsificações
Nem toda falha DMARC justifica autorizar uma nova fonte. Algumas correspondem a tentativas de falsificação; outras, a remetentes legítimos mal configurados ou encaminhamento. O resultado de autenticação não basta para decidir.
Se SPF e DKIM falham de um IP desconhecido, não permita nem bloqueie automaticamente. Compare inventário, logs e rotas de encaminhamento. p=quarantine e p=reject solicitam restrições, mas a aplicação depende do destinatário e de possíveis exceções locais.
Use este processo:
- Investigue o IP ou fornecedor desconhecido antes de classificar como abuso.
- Para um remetente autorizado, identifique a plataforma e confira a autenticação de domínio.
- Se faltar DKIM em uma plataforma compatível, configure-o e verifique assinatura e alinhamento.
- Se nenhum mecanismo pode passar alinhado, avalie trocar o fornecedor ou separar o fluxo com configuração ativa e testes, não apenas novos registros DNS.
As diretrizes do Google citadas explicam a aplicação de políticas DMARC quando autenticação ou alinhamento falham, conforme o caso e regras locais. Confira requisitos e aplicação atuais nas orientações de autenticação de remetentes do Google.
Padrões de falha por tipo de remetente
O tipo de sistema pode orientar a investigação, mas não comprova automaticamente a causa. Verifique o fluxo e os resultados reais.
| Tipo de remetente | Possível causa | Verificação ou correção |
|---|---|---|
| Marketing | DKIM ou domínio de devoluções sem alinhamento | Configurar e testar DKIM próprio e Return-Path personalizado |
| Suporte ou CRM | Domínios de autenticação do fornecedor não alinhados a From | Completar e verificar a autenticação de domínio |
| Encaminhamento da caixa | SPF falha após o relay | Verificar DKIM válido e alinhado e preservação dos dados assinados |
| Lista de e-mail | Encaminhamento com mudanças no corpo ou cabeçalhos assinados | Investigar falhas; ARC pode orientar exceções locais, sem garantir que o DMARC passe |
| Pequena empresa com vários serviços | Avaliação SPF excessiva ou DNS incompleto | Consolidar autorizações e avaliar domínios do envelope separados e realmente usados |
| Agência com muitos domínios | Configurações DNS inconsistentes | Padronizar o processo com valores adaptados e testes por cliente |
Resolver falhas DMARC em vários domínios
Um cliente usa Google Workspace, outro cPanel, outro SendGrid e outro encaminha tudo ao Gmail. Sem documentação dos DNS atuais, as falhas podem virar incidentes recorrentes.
Um processo comum pode ajudar: inventário, lista DNS e plano de migração para revisar domínios, encaminhamento, SMTP e autenticação. Centralizar não substitui testes por fluxo.
A oferta descrita do TrekMail apresenta planos pagos a partir de $3.50 por mês, teste gratuito de 14 dias sujeito a condições e um plano sem custo com SMTP próprio conforme a oferta atual. Domínios personalizados, caixas IMAP, catch-all, encaminhamento, cópia IMAP, API e ferramentas DNS dependem do plano e seus limites. Copiar mensagens não substitui a alteração de MX nem migra todos os aplicativos; esses recursos também não garantem economia ou menos incidentes.
Para muitos domínios de clientes, consulte hospedagem de e-mail multidomínio e compare o processo com a gestão manual em cada registrador.
Lista breve para investigar uma falha DMARC
Comece com uma mensagem que falhou, identifique os domínios autenticados, compare-os com From e teste a correção correspondente. Repita a análise para outros fluxos, inclusive os críticos pouco frequentes.
- Abra a mensagem e confira
Authentication-Resultsdo destinatário confiável. - Confira se o SPF passou e para qual domínio real do envelope.
- Confira se o DKIM passou e para qual domínio
d=. - Compare ambos com From visível.
- Se nenhum passa alinhado, corrija autenticação e alinhamento necessários.
- Se houver encaminhamento, confira DKIM válido e alinhado e preservação dos dados assinados.
- Se o SPF excede o limite, remova autorizações não usadas ou configure e teste domínios do envelope separados.
- Se os dois mecanismos falham de uma fonte desconhecida, investigue antes de classificá-la ou alterar o tratamento.
O processo se apoia em resultados confiáveis, inventário e testes, não em suposições.
Conclusão: identificar o mecanismo que causa a falha
Uma falha no DMARC pode aparecer na entrega por desalinhamento, encaminhamento com DKIM inválido, SPF PermError ou fonte não autorizada. É preciso distinguir esses casos sem presumir que todas as falhas são abuso nem que um resultado válido garante segurança.
Corrija a configuração identificada e verifique mensagens reais, em vez de adicionar DNS aleatoriamente. O TrekMail oferece armazenamento compartilhado, gestão multidomínio, SMTP próprio no Nano, SMTP gerenciado em planos compatíveis e cópia IMAP conforme a oferta atual. Isso não substitui a validação nem garante migração completa. Consulte TrekMail ou compare as condições em https://trekmail.net/pricing.
