Deliverability

Como corrigir falhas de DMARC

Quando e-mails legítimos falham no DMARC, a causa é quase sempre uma entre poucas situações previsíveis: um resultado SPF ou DKIM ausente ou desalinhado, encaminhamento que quebra o SPF, ou um remetente terceirizado que nunca foi autenticado para o seu domínio. A solução raramente é afrouxar sua política. É encontrar a origem e autenticá-la corretamente.

Como sei o que está falhando?

Comece pelos seus relatórios, porque eles dizem exatamente qual origem está falhando e por quê. Seus relatórios agregados separam os e-mails por IP de envio e mostram os resultados de SPF e DKIM junto com o alinhamento de cada um. Uma origem mostrando pass na verificação bruta mas fail após o alinhamento é o padrão mais comum, e aponta direto para o problema. Se você ainda não se sente confortável lendo esses relatórios, como ler um relatório DMARC explica cada campo.

Depois que você consegue ver qual origem está falhando, quase sempre é uma das causas abaixo.

Causa 1: Uma lacuna de alinhamento

Essa é a principal. SPF ou DKIM passa, mas para um domínio que não corresponde ao seu endereço From visível, então o DMARC conta como falha. Normalmente significa que um serviço de envio se autentica com o próprio domínio em vez do seu.

A solução é trazer o serviço para o alinhamento. Para SPF, isso significa enviar com um Return-Path (domínio de bounce) no seu próprio domínio. Para DKIM, significa assinar com uma chave publicada no seu domínio, para que o domínio de assinatura corresponda ao seu From. A maioria das plataformas de e-mail oferece suporte a domínio personalizado exatamente para isso: você publica um ou dois CNAMEs e o alinhamento se encaixa. O conceito é explicado em como o DMARC funciona.

Causa 2: Encaminhamento

O encaminhamento quebra silenciosamente o SPF. Quando uma mensagem é encaminhada, o servidor de encaminhamento a envia adiante, e esse servidor não está no seu registro SPF, então a verificação SPF falha no destino final. Não há muito o que fazer sobre as regras de encaminhamento de outras pessoas.

A boa notícia é que o DKIM geralmente sobrevive ao encaminhamento, porque a assinatura viaja com a mensagem. É exatamente por isso que o DMARC passa com SPF ou DKIM: enquanto seu DKIM estiver sólido e alinhado, e-mails encaminhados ainda passam no DMARC mesmo quando o SPF cai. A solução prática para falhas de encaminhamento é garantir que o DKIM esteja configurado corretamente e alinhado, e depois parar de se preocupar com a coluna SPF para e-mails encaminhados.

Causa 3: Um remetente terceirizado que você esqueceu

Quase toda organização envia e-mails por mais serviços do que lembra: um CRM, um help desk, uma ferramenta de faturamento, uma plataforma de marketing, um serviço de pesquisa. Cada um precisa estar autenticado para o seu domínio, ou seus e-mails falham no DMARC. Novas origens aparecendo nos seus relatórios geralmente são um desses.

Resolva um de cada vez. Para cada serviço legítimo, siga as instruções dele para configurar SPF e DKIM no seu domínio (o texto geralmente diz "authenticate your domain" ou "use a custom sending domain"). Depois confirme nos seus próximos relatórios que a origem passou a mostrar aprovação e alinhamento. Mantenha uma lista atualizada, porque essa é a parte que muda conforme as equipes adotam novas ferramentas.

Causa 4: SPF amplo demais ou acima do limite de consultas

Duas armadilhas específicas de SPF. Se o seu registro SPF ultrapassou 10 consultas DNS (um limite rígido na especificação), ele pode falhar completamente, derrubando e-mails que de outra forma estariam corretos. E um registro permissivo demais pode aprovar e-mails que você não pretendia autorizar. Audite seu registro SPF, consolide entradas include: se estiver perto do limite e remova serviços que você não usa mais.

O que você não deve fazer

Não corrija falhas enfraquecendo sua política de volta para p=none e deixando assim. Isso faz os relatórios pararem de incomodar você, mas também para de proteger qualquer pessoa, então o problema de spoofing que você estava resolvendo fica totalmente aberto de novo. Trate uma falha como um sinal para autenticar uma origem, não como motivo para recuar. A forma legítima de aliviar é recuar o p= um nível e continuar lendo os relatórios, o que o que é uma política DMARC cobre.

Juntando tudo

Leia o relatório, encontre a origem que está falhando, decida se ela é legítima e então autentique-a ou reconheça que é spoofing que você agora está bloqueando. Trabalhe na lista até que todo remetente real passe e esteja alinhado, e sua política possa ficar tranquilamente em reject. Se você ainda está configurando tudo, como configurar o DMARC cobre a base, e o guia de autenticação da Bird tem os registros específicos do domínio. A maioria das falhas parece alarmante e acaba sendo uma correção de alinhamento de cinco minutos quando você sabe qual origem investigar.

Coloque em prática.

Continue com a documentação, guias e exemplos sobre este tópico. Os recursos estão em inglês.

Obtenha um resumo de implementação

Construa na mesma rede.

Uma chave de API de teste é sua imediatamente. A produção é desbloqueada quando adicionar um método de pagamento e verificar um remetente.

Sua próxima ideia.
Pronta para conectar.