Um remetente pode provar o controle do próprio domínio. Mesmo assim, ele pode exibir o seu domínio no endereço From. A autenticação bem-sucedida, por si só, não estabelece permissão para usar essa identidade exibida.
Por que SPF e DKIM podem passar enquanto DMARC falha?
Ambas as verificações podem autenticar domínios que não correspondem ao domínio visível do From.
SPF verifica se o servidor conectado está autorizado para o domínio do remetente do envelope, usado para avisos de falha de entrega. DKIM valida uma assinatura criptográfica associada a um domínio de assinatura, identificado pela tag d da assinatura.
O remetente do envelope é fornecido durante a conversa SMTP. Ele é separado do cabeçalho From exibido pelo cliente de e-mail do destinatário.
Por exemplo, um remetente que controla attacker.example pode passar SPF e DKIM para esse domínio. O remetente pode colocar billing@example.com no From. Nenhum dos resultados valida example.com, então DMARC falha.
Um domínio organizacional é o limite administrativo que contém um domínio e seus subdomínios, como example.com para news.example.com.
O que conta como alinhado?
O alinhamento relaxado exige um domínio organizacional compartilhado. O alinhamento estrito exige domínios idênticos.
A RFC 9989 define como os receptores descobrem esse limite.
| Domínio autenticado | Domínio do From | Alinhamento |
|---|---|---|
foo.example.com | news.example.com | Relaxado, porque ambos compartilham example.com |
news.example.com | news.example.com | Estrito, porque os domínios são idênticos |
foo.example.net | news.example.com | Nenhum, porque os domínios organizacionais diferem |
A tag adkim controla o alinhamento DKIM. A tag aspf controla o alinhamento SPF. Cada uma aceita r para relaxado ou s para estrito, com relaxado como padrão.
Use o alinhamento estrito somente quando você precisar de domínios idênticos, porque ele exclui correspondências válidas entre subdomínios irmãos. Um serviço que assina como foo.example.com não consegue satisfazer o alinhamento estrito para o From em news.example.com.
A especificação relata que quase todos os proprietários de domínio consideram o alinhamento relaxado suficiente. Seus requisitos de correspondência de domínio determinam se o alinhamento relaxado é apropriado.
DMARC precisa que ambos os métodos estejam alinhados?
Não: um passe alinhado de SPF ou DKIM é suficiente.
O receptor avalia os métodos de forma independente. Um resultado aprovado, mas não alinhado, não pode fornecer o passe DMARC.
O encaminhamento pode quebrar SPF ao alterar o servidor conectado. DKIM pode sobreviver se o encaminhador preservar o conteúdo assinado. Uma assinatura intacta de um domínio alinhado então permite que a mensagem passe DMARC apesar da falha de SPF.
Se o encaminhamento alterar o conteúdo assinado, DKIM também pode falhar. Como corrigir falhas de DMARC explica o diagnóstico.
Por que um serviço de envio pode quebrar o alinhamento SPF?
O alinhamento SPF falha quando o serviço usa um domínio de remetente do envelope que não se alinha com o seu domínio visível do From.
Se o serviço usa seu próprio domínio de bounce não relacionado, SPF pode passar para esse domínio. DMARC rejeita esse resultado como não alinhado. Adicionar o serviço a um registro SPF no seu domínio não altera o domínio que o receptor verifica.
Configure um return path personalizado, o domínio usado para avisos de falha de entrega, sob o seu próprio domínio. Com alinhamento relaxado, bounce.example.com pode corresponder ao From em example.com.
DKIM oferece uma rota separada: configure o serviço para assinar usando um domínio alinhado. Você pode confirmar ambos os resultados nos relatórios agregados, que resumem as verificações do receptor.
Como você configura o return path com Bird?
Você publica o alias de return path de Bird sob o seu domínio de envio.
Publique esse alias como um registro CNAME. O alias de return path fornece a configuração SPF de Bird, então você não precisa de um registro SPF separado na raiz do domínio para envios de Bird.
O campo return_path.name de API aceita de 1 a 63 letras, dígitos ou hífens, com uma letra ou dígito em cada extremidade. Um rótulo mais longo ou que comece com hífen é inválido.
Bird anexa o seu domínio de envio. Por exemplo, send em mail.example.com se torna send.mail.example.com. Esse return path pode se alinhar com o From em mail.example.com no modo relaxado.
O guia de domínio de bounce cobre o registro. Você também publica o registro DKIM. Bird aceita uma política DMARC válida no domínio de envio ou no seu domínio organizacional. Uma política de monitoramento de p=none, que não expressa preferência de tratamento para falhas, é suficiente.
Como a especificação encontra domínios organizacionais?
A RFC 9989 pesquisa a hierarquia de domínio em busca de registros que estabeleçam a política aplicável e o limite do domínio. Essa pesquisa é chamada de DNS tree walk.
A especificação substitui a abordagem da Public Suffix List descrita pela RFC 7489. Essa lista identifica sufixos de registro compartilhados como com e co.uk.
A distinção afeta o alinhamento relaxado porque o domínio organizacional descoberto determina se nomes relacionados correspondem. Ela também afeta qual política pai se aplica a um subdomínio. Uma especificação publicada não estabelece qual método de descoberta um receptor específico implementa.
Uma tag de porcentagem pode controlar a aplicação?
A tag de porcentagem pct não fornece aplicação parcial confiável. A RFC 9989 a exclui.
O Apêndice A.6 descreve o tratamento inconsistente de porcentagens intermediárias. Uma configuração de pct=50, portanto, não garante que o tratamento mais rigoroso afete exatamente metade das mensagens com falha.
Os valores excepcionais eram zero e cem, correspondendo a nenhuma aplicação baseada em porcentagem e aplicação total. Alguns intermediários também tratavam pct=0 como um sinal para reescrever o endereço From visível e evitar falhas subsequentes.
Use relatórios para corrigir falhas legítimas antes de alterar a política por meio de none, quarantine e reject. O valor none não expressa preferência de tratamento. O valor quarantine marca falhas como suspeitas. O valor reject identifica uso não autorizado do domínio. O guia de política explica a implantação.
Um passe alinhado prova que a mensagem é segura?
Um passe alinhado prova o uso autorizado do domínio do From, sem estabelecer se a mensagem é desejada ou segura.
Um receptor pode rejeitar ou colocar em quarentena uma mensagem aprovada usando suas próprias regras de filtragem. Ele também pode aceitar uma mensagem com falha quando outras evidências justificam a entrega.
Autorização de domínio e reputação do remetente, a avaliação do receptor sobre o tráfego de um remetente, respondem a perguntas diferentes. Verifique ambas ao investigar a entrega.
Em resumo
A autenticação precisa corresponder ao domínio visível.
SPF e DKIM podem passar para domínios não relacionados, então DMARC exige um passe alinhado para o domínio no From.
Qualquer método alinhado pode fornecer um passe.
Uma assinatura DKIM alinhada e intacta pode preservar um passe DMARC quando o encaminhamento quebra SPF.
Relaxado e estrito usam regras de correspondência diferentes.
O alinhamento relaxado aceita um domínio organizacional compartilhado. O alinhamento estrito exige domínios idênticos.
Descoberta de domínio e aplicação são mecanismos separados.
A RFC 9989 usa um DNS tree walk para descobrir limites de domínio. Ela exclui a tag de porcentagem, considerada não confiável, do seu formato de política.