Alinhamento DMARC: o que é, por que falha e como corrigir

O alinhamento DMARC costuma ser esquecido. A equipe publica SPF, DKIM e DMARC, mas o Gmail ainda classifica algumas mensagens como spam ou as rejeita. Para revisar o conjunto, consulte nosso guia de e-mail empresarial e volte aqui para investigar autenticação e alinhamento.

Passar na autenticação não basta: o domínio validado por SPF ou DKIM precisa estar alinhado ao domínio visível de From. Se nenhum mecanismo fornece um resultado válido e alinhado, o DMARC falha; isso, sozinho, não comprova falsificação. Esses problemas aparecem em plataformas de envio, CRMs, suporte, encaminhamento e configurações DNS incompletas.

Veremos como o alinhamento funciona, por que corrigir apenas o SPF pode não bastar e quais cabeçalhos analisar. Também explicaremos quando o DKIM pode permitir que o DMARC passe após encaminhamento, sem garantir que qualquer rota preserve a assinatura.

O que é alinhamento DMARC?

O alinhamento compara o domínio autenticado por SPF ou DKIM com o domínio visível de From. O DMARC passa se o SPF passa com alinhamento ou se o DKIM passa com alinhamento. Um resultado válido e alinhado basta; o DMARC falha quando nenhum dos mecanismos o fornece.

A regra vem da RFC 7489. O DMARC se apoia em SPF e DKIM, sem autenticar o e-mail de forma independente. Ele verifica se o domínio autenticado está alinhado ao que o destinatário vê.

A comparação funciona assim:

Em resumo: SPF ou DKIM válido com um domínio não alinhado não basta sozinho. Para o DMARC, pelo menos um precisa passar e estar alinhado a From.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

Por que o SPF passa sem fornecer alinhamento DMARC

O alinhamento por SPF falha quando o Return-Path pertence a um domínio do fornecedor não alinhado ao seu. O IP pode estar autorizado e o SPF passar, mas um domínio de devoluções do SendGrid, Mailchimp, HubSpot ou Shopify pode não estar alinhado. O DMARC ainda pode passar se o DKIM fornecer um resultado válido e alinhado.

É um caso comum. Plataformas de envio gerenciam devoluções, listas de supressão e eventos; algumas usam um Return-Path próprio por padrão.

From visível: billing@example.com
Return-Path: bounces+123@sendgrid.net

O SPF pode passar porque o SendGrid autoriza o IP para sendgrid.net. Esse resultado não fornece alinhamento DMARC: sendgrid.net não está alinhado a example.com.

Para alinhar o SPF, configure o domínio de devoluções ou Return-Path personalizado do fornecedor. Não confunda essa função com personalização de links ou domínio de rastreamento: eles não alteram necessariamente o remetente do envelope.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

O CNAME é ilustrativo. O fornecedor precisa ativar a função e usar realmente bounces.example.com no remetente do envelope; confirme isso em mensagens reais. No modo relaxado, esse domínio está alinhado a example.com.

O encaminhamento traz outra dificuldade. Uma universidade, um revendedor ou uma caixa pessoal pode encaminhar do próprio IP, que o SPF avalia para o domínio de envelope usado naquele salto. Por isso os guias de encaminhamento de e-mails do domínio para o Gmail e encaminhamento com aliases abordam falhas SPF. O SPF é útil, mas não garante que o DMARC passe após encaminhamento.

Por que verificar o alinhamento DKIM

O DKIM pode resistir a alguns encaminhamentos melhor que o SPF. Para permitir que o DMARC passe, a assinatura precisa continuar válida e alinhada, com os dados assinados preservados após a canonicalização. Dizer apenas que a mensagem não mudou de forma importante não basta.

Por isso é recomendável configurar DKIM alinhado, principalmente com intermediários. Não é uma exigência universal do protocolo quando o SPF já passa alinhado. Uma ferramenta que assina com seu próprio domínio pode passar no DKIM sem contribuir para o alinhamento do seu domínio.

From visível: newsletter@example.com
Assinatura DKIM: d=mailchimpapp.net

O DKIM pode passar, mas o domínio assinante não está alinhado. O DMARC falha se o SPF também não passar com alinhamento.

Configure a autenticação de domínio em cada plataforma. Isso pode exigir publicar os registros DKIM indicados pelo fornecedor e ativar o uso deles, não apenas esperar após a publicação.

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

Depois de configurar e verificar a assinatura, a plataforma pode usar d=example.com ou um subdomínio alinhado no modo relaxado, como d=mail.example.com. O DKIM pode então fornecer alinhamento mesmo se o SPF falhar por encaminhamento, desde que a assinatura continue válida.

As diretrizes do Google citadas exigem que SPF ou DKIM passe alinhado a From para remetentes em massa e recomendam configurar ambos adequadamente. Confira os requisitos atuais e sua aplicação; erros de autenticação podem contribuir para restrições, mas o alinhamento não garante a caixa de entrada.

Alinhamento relaxado e estrito

No modo relaxado, compara-se o domínio organizacional; no estrito, exige-se correspondência exata do domínio completo. O relaxado é o padrão, mas a escolha depende dos remetentes e riscos reais, não de uma regra universal.

As tags aspf para SPF e adkim para DKIM controlam o modo no DMARC.

Exemplo:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

O modo estrito pode complicar a operação. Se um aplicativo assina com mail.example.com e From usa example.com, o DKIM deixa de fornecer alinhamento estrito; o DMARC ainda pode passar pelo SPF válido e alinhado.

Ative o modo estrito por uma necessidade concreta e depois de revisar todos os fluxos. No modo relaxado também, confirme que cada remetente autorizado fornece um resultado válido e alinhado.

Como investigar o alinhamento DMARC

Analise os cabeçalhos recebidos: Authentication-Results, o domínio d= da assinatura DKIM, smtp.mailfrom para SPF e o resultado dmarc associado a header.from. Confie apenas em Authentication-Results gerado pelo destinatário que avalia a mensagem, não em cabeçalhos adicionados pelo remetente.

Quando uma mensagem parece legítima, mas falha no DMARC, esses cabeçalhos e a assinatura podem ajudar a identificar os domínios usados. Compare-os com a configuração e os logs do serviço.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

Leia os dados nesta ordem:

1. Confira header.from, o domínio visível avaliado pelo DMARC.
2. Confira o domínio SPF em smtp.mailfrom. Se pertence ao fornecedor e não está alinhado, o SPF não fornece alinhamento DMARC.
3. header.i não substitui o domínio d= da assinatura, usado para alinhamento DKIM e que pode diferir da identidade i. Verifique a assinatura real; um domínio não alinhado do fornecedor não fornece alinhamento.
4. Se nenhum resultado bem-sucedido está alinhado a From, o DMARC falha mesmo que SPF e DKIM passem para outros domínios.

Você também pode consultar o DNS:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

No encaminhamento, uma falha SPF pode ser esperada, mas não deve ser ignorada automaticamente. Confira se o DKIM passa com alinhamento e se os dados assinados foram preservados após a canonicalização; DKIM válido sem alinhamento não salva o DMARC.

Ao configurar um domínio, o guia de configuração do TrekMail e como criar e-mail com seu domínio ajudam a organizar SPF, DKIM e DMARC. Mantenha um SPF válido por domínio real do envelope e respeite o limite de mecanismos e modificadores que provocam consultas DNS, incluindo avaliações aninhadas. Remova registros antigos somente após confirmar que são desnecessários; não exclua todos os MX ou seletores indiscriminadamente.

Padrões frequentes de falha de alinhamento

Fornecedores externos, encaminhamento, subdomínios e registros DNS antigos ou duplicados são pontos comuns de investigação. Identificar um padrão orienta a análise, mas não comprova sozinho a causa.

Revise estes casos:

1. O marketing usa seu próprio domínio de devoluções: SPF passa sem alinhamento; o DMARC pode passar com DKIM válido e alinhado.
2. O fornecedor assina com seu domínio: DKIM passa sem alinhamento; SPF válido e alinhado ainda pode permitir que o DMARC passe.
3. Um encaminhamento faz o SPF falhar: o DKIM precisa continuar válido e alinhado para fornecer o resultado restante.
4. O modo estrito impede o alinhamento de um subdomínio autorizado; confira se outro mecanismo fornece alinhamento.
5. Há DNS antigos: confirme quais registros e serviços continuam em uso antes de alterar; um registro obsoleto não comprova que a plataforma ainda envia ou assina.

O erro 4.7.32 do Gmail, quando indica que From não está alinhado a SPF ou DKIM, aponta um problema específico de alinhamento. Questões de reputação ou envio também podem coexistir. Consulte as diretrizes de envio do Google e sua aplicação atual.

Corrigir o alinhamento com o TrekMail

O TrekMail pode reunir gestão das caixas, verificações DNS e opções de envio conforme o plano. Centralizar pode facilitar a coordenação entre cinco painéis, mas configurações corretas e testes de cada remetente continuam necessários.

Estas são opções práticas.

Gestão dispersa e centralizada

Com SMTP gerenciado nos planos pagos que o incluem, publique os DNS indicados e teste a autenticação alinhada em mensagens reais. Com SMTP próprio no Nano ou em planos compatíveis, configure o provedor real, seja SES, SendGrid, Mailgun ou outro. O objetivo é um resultado válido e alinhado, não apenas um indicador positivo no painel.

Referências úteis:

Meus e-mails chegam ao spam trata de SPF com falha e DKIM válido no encaminhamento, que só passam no DMARC se o DKIM também estiver alinhado. A documentação de configurações IMAP & SMTP apresenta os pontos de conexão para testar acesso dos clientes, uma verificação distinta do alinhamento do envio.

A oferta descrita apresenta Starter a partir de $3.50 por mês e teste gratuito de 14 dias nos planos pagos que exige cartão de crédito para começar. O Nano é oferecido sem custo com SMTP próprio, até 10 domínios e 5 GB de armazenamento compartilhado sob suas condições. Confira preços, limites e recursos atuais na página de preços do TrekMail. A cópia IMAP não substitui a alteração de MX nem migra todos os aplicativos, e comparar modelos de preço não garante economia.

Lista final para alinhamento DMARC

Uma implantação controlada busca SPF ou DKIM válido e alinhado para cada remetente autorizado, ou ambos quando possível. Isso ajuda a avaliar restrições, mas não elimina todos os riscos de encaminhamento nem garante entrega.

1. Liste os remetentes: hospedagem das caixas, CRM, cobrança, suporte, loja, formulários e marketing.
2. Confirme o domínio visível de From em cada serviço.
3. Confira SPF e o alinhamento do domínio real do Return-Path, não apenas sua presença.
4. Configure e verifique DKIM do fornecedor alinhado ao seu domínio, principalmente nas rotas com encaminhamento.
5. Mantenha aspf=r e adkim=r, salvo necessidade testada que justifique o modo estrito.
6. Envie testes ao Gmail e confira Authentication-Results gerado pelo destinatário e o domínio real da assinatura DKIM.
7. Considere manter p=none enquanto valida os fluxos; ela não solicita restrições pelo DMARC, mas os filtros locais continuam ativos.
8. Aplique restrições depois de comparar relatórios parciais com inventários, logs e testes de fluxos críticos pouco frequentes, avaliando as falhas restantes e as exceções locais.

O alinhamento é uma condição de autenticação DMARC, não uma classificação infalível entre mensagens legítimas e falsificadas nem uma garantia de conteúdo seguro. Para coordenar vários domínios, avalie o TrekMail conforme os planos e sua operação, sem presumir economia em relação à cobrança por usuário.