Um mercado pode entregar as palavras de um comerciante sem estar autorizado a autenticar o domínio do comerciante. Distinguir quem escreveu o conteúdo comercial, cujo domínio aparece em De e qual serviço opera o fluxo de correio. Essas funções podem pertencer a três partes diferentes. Um nome de exibição de comerciante familiar não resolve a questão da identidade do domínio.
Escolha a identidade do autor pretendida
Para uma notificação de pedido originada na plataforma, use a identidade aprovada da plataforma e deixe claro o relacionamento com o comerciante no conteúdo. Para uma rota com marca comercial, verifique o controle do domínio comercial e a delegação específica necessária para autenticação antes de ativá-la. Não aceite o domínio digitado por um comerciante como prova de controle nem copie a configuração de outro vendedor no novo locatário.
O mapa trabalhado separa avisos de pedidos de plataforma, respostas de comerciantes e atualizações de suporte. Atribua cada um a um proprietário nomeado de integração ou serviço. Registre se De é de propriedade da plataforma ou do comerciante, qual locatário pode acionar emails e quem pode alternar ou revogar a configuração de assinatura. Um endereço de resposta pode direcionar a conversa para um comerciante sem tornar esse endereço o DMARC identidade do autor.
Teste um caso permitido e um não alinhado
O caso fictício do comerciante apresenta seller.test em From enquanto assina como market.test. Mesmo assumindo que a assinatura seja verificada, ela falha estritamente DKIM alinhamento com vendedor.teste. A ordem da plataforma e as identidades de suporte no mapa de rotas correspondem aos seus respectivos domínios De; essas são configurações assumidas, não testes observados. Isto ilustra por que a assinatura bem-sucedida pela plataforma não autoriza, por si só, o uso da identidade de um vendedor.
Selecione um design honesto e compatível: um From de propriedade da plataforma com atribuição clara do comerciante ou uma configuração de domínio do comerciante devidamente verificada. Este último requer autoridade documentada e acesso com escopo definido. Registre o inquilino aprovado, domínio, seletor, proprietário de prova e revogação DNS . Estas são recomendações para avaliar um sistema, não afirmações de que um determinado mercado ou EmailAuth as implementa.
Mantenha a autoridade do inquilino no teste de aceitação
Um passe criptográfico não pode revelar se a conta do vendedor errada teve permissão para selecionar o domínio. Adicionar testes de aplicação negativos: um segundo comerciante não deve enviar como o primeiro comerciante, uma delegação expirada não deve permanecer utilizável e a remoção de um comerciante deve fechar o caminho de envio relevante. Execute esses testes somente em um ambiente de teste autorizado e preserve os resultados reais do sistema separadamente dessas identidades hipotéticas.
Inventariar IPs compartilhados como evidência de infraestrutura, não como identidade do comerciante. Uma gama de plataformas pode transportar muitos inquilinos, incluindo os comprometidos. Não coloque todas as mensagens desse intervalo na lista de permissões apenas porque uma notificação de pedido é legítima.
Planeje o fim do relacionamento
Defina como as mensagens na fila, as respostas e as conversas de suporte abertas serão tratadas quando um comerciante sai. Revogue a delegação exata sem perturbar comerciantes não relacionados. Preserve apenas os relatórios e as evidências de auditoria que a plataforma está autorizada a reter. As divulgações ao consumidor, os contratos comerciais, os termos de partilha de dados e a responsabilidade de pagamento necessitam de uma revisão qualificada; nem DKIM nem este mapa de rotas os julgam.
Mapa de rota fictício
As identidades explícitas a seguir são entradas ilustrativas e não configurações reais do cliente. Esses domínios e funções responsáveis são hipotéticos, e não aprovações de clientes ou mensagens assinadas fornecidas. Nenhum teste criptográfico ou entrega foi executado.
- Notificação de pedido da plataforma: líder de mensagens da plataforma; De pedidos.market.test; envelope e assinante DKIM requests.market.test.
- Mensagem do comerciante: líder de integrações do comerciante; Do vendedor.teste; envelope e signatário DKIM market.test.
- Suporte à plataforma: Líder de suporte ao cliente; De support.market.test; envelope e signatário DKIM support.market.test.
Verifique a concessão antes do resultado da assinatura
Suponha que o comerciante A tenha aprovado uma configuração de domínio com escopo definido, mas o comerciante B possa selecioná-la por meio do seletor de remetente da plataforma. Uma assinatura alinhada corretamente no e-mail resultante não repararia a falha de autorização do aplicativo. Mantenha a rota, preserve as evidências de diagnóstico permitidas e teste o limite real do locatário/objeto com contas de teste autorizadas. Não envie uma mensagem de representação ao vivo apenas para demonstrar o problema.
Orientação multilocatário da OWASP, seções 1, 3 e 5, dá suporte ao contexto de locatário confiável e à autorização de recursos, incluindo trabalho atrasado. RFC 9989 Seções 4.4 e 5.3.5 distinguir o alinhamento DKIM do veredicto completo da mensagem: outros caminhos de autenticação alinhados devem ser avaliados. As seções 7.4 e 8 exigem DKIM válido para p=reject implantação em vez de depender SPF sozinho. Não foi realizada nenhuma operação de outorga comercial, teste de seleção ou assinatura.