Domínios de inventário por servidor e aplicativo
A autenticação SocketLabs deve ser revisada para o servidor ou subconta que realmente envia a mensagem. Comece com uma lista de aplicativos, domínios visíveis de From e a configuração do SocketLabs que cada aplicativo usa. Inclua subdomínios From distintos, marcas de clientes e rotas alternativas. Uma marca funcional não é evidência suficiente para um servidor que envia em nome de diversas organizações.
O provedor exige domínios de envio verificados e documenta um erro quando um endereço não é permitido. Ele oferece suporte à verificação de propriedade por meio de um processo de confirmação de endereço ou recursos de autenticação DNS elegíveis, ao mesmo tempo em que observa que a configuração e o plano da conta afetam a aplicação de controles de domínio de envio. SocketLabs Envio de domínios, adição e verificação de um domínio de envio.
Permissão separada para enviar da autenticação no destinatário. Um domínio pode ter permissão para enviar sem o domínio do cliente desejado DKIM ou identidade do envelope sendo usada. Registre-os como verificações independentes e obtenha a permissão do proprietário do domínio antes de autorizar a identidade de um cliente ou parceiro.
Escolha o método DKIM com o proprietário da chave
SocketLabs documenta três métodos: uma chave TXT fornecida pelo cliente, uma chave TXT gerada pelo provedor e uma chave TXT gerenciada pelo provedor. CNAME. A escolha altera quem gerencia as chaves e como elas são mantidas nos servidores. Sua visão geral atual diz que a assinatura requer uma correspondência com a identidade De. Visão geral do SocketLabs DKIM , os três métodos de assinatura.
Registre a decisão antes do início do trabalho DNS . Para um método gerenciado pelo provedor, identifique quem pode alterar a configuração de assinatura. Para um método controlado pelo cliente, identifique o custodiante da chave privada e o processo de rotação aprovado. Uma planilha cheia de chaves não é um registro de propriedade aceitável. A planilha deve conter uma referência de evidência e uma pessoa responsável, e não material secreto.
Não escolha automaticamente o método mais complexo porque ele expõe mais controles. Prefira a abordagem suportada que atenda aos requisitos da organização e possa ser mantida por seus operadores reais. Se a política exigir um acordo específico de gerenciamento de chaves ou uma identidade de assinatura incomum, obtenha a confirmação do provedor antes de apresentar a configuração como suportada.
Configure o método de assinatura selecionado
Para assinatura CNAME , o guia oficial descreve um registro DNS delegado e verificação do lado da conta antes de ativar o recurso. O guia CNAME lista dkim. _domainkey no domínio de envio apontando para dkim._domainkey.email-od.com . Compare esse par documentado publicamente com as instruções da conta corrente; não substitua um ocupado seletor apenas porque o exemplo corresponde ao seu nome. Se o host DNS não puder suportar o sublinhado necessário no proprietário CNAME , o guia direcionará os usuários para a abordagem TXT em vez de uma ortografia inventada. Guia de assinatura CNAME do SocketLabs.
Verifique se o proprietário do seletor pretendido já é usado por outro serviço. Um CNAME não pode ser colado com segurança sobre um seletor não relacionado. Solicite uma alternativa compatível ou uma migração aprovada. Preservar o registro existente, seus serviços dependentes e a decisão de alteração no ticket de implementação.
O guia TXT distingue a geração de chaves na plataforma de trazer um par de chaves. Requer a chave pública no DNS e verifica essa chave antes de salvar as configurações relevantes. O fluxo de chave gerada mantém seu componente privado na conta. Guia de assinatura SocketLabs TXT.
Use um fluxo de trabalho de tratamento de segredos aprovado se o método selecionado envolver a importação de material privado. Publique apenas a chave pública. Registre o domínio e o seletor exatos e inspecione o valor TXT lógico resultante após qualquer divisão de string do editor DNS. O guia da chave gerada diz que a chave pública não está mais disponível no portal após a publicação e salvamento bem-sucedido DNS . Preserve o registro público e sua procedência antes de fechar o ticket de configuração, sem reter a chave privada no pacote de revisão.
Configure o domínio de rejeição como um mapeamento separado
SocketLabs implementa domínio do cliente SPF através de seu modelo de domínio de rejeição personalizado sem exigir uma adição ao visível-From existente Registro SPF. Seu guia especifica um CNAME do subdomínio de rejeição selecionado para tracking.socketlabs.com . Várias entradas de devolução podem ser configuradas; e-mail sem correspondência usa o padrão selecionado ou o substituto do provedor. Guia de rejeição personalizada do SocketLabs, configuração e vários domínios de rejeição personalizados.
Escolha um nome não utilizado com o administrador DNS e confirme o mapeamento suportado no servidor real. Mantenha intacta a configuração normal de correio de entrada do domínio. Um nome de host devolvido é uma identidade de entrega de aplicativo e não deve ser confundido com a caixa de correio de resposta de um usuário ou com o endpoint de rastreamento do site.
Registre a correspondência pretendida para cada domínio De e registre o comportamento padrão. Os padrões merecem uma revisão comercial explícita em um servidor multimarcas: a entrega bem-sucedida ainda pode expor uma marca ou identidade de fornecedor inesperada. Não deduza o mapeamento ativo apenas dos nomes na configuração. O emitido Return-Path é a evidência para comparar mais tarde.
Publique e compare os registros públicos
Exporte os registros DNS relevantes antes de fazer a alteração aprovada. Confirme o serviço autoritativo e o tratamento de nomes relativos pelo editor DNS . Inspecione cada proprietário publicado de forma independente, incluindo sua cadeia CNAME ou resposta TXT . Um registro DKIM correto não prova que o nome de devolução está configurado e um registro de devolução correto não prova que a assinatura DKIM está ativa.
SPF é avaliado usando a identidade do envelope SMTP , não simplesmente o De visível. Se outro serviço ainda precisar da política SPF do domínio raiz, preserve-a. Em qualquer proprietário onde uma política SPF seja necessária, mantenha uma política e verifique o limite de prazo de consulta de DNS do protocolo. RFC 7208 , seções 2.4, 4.5 e 4.6.4.
Aguarde respostas autoritativas e recursivas consistentes onde os caches estão envolvidos. Se o provedor não puder verificar um recorde, salve o valor emitido e as observações DNS cronometradas para suporte, em vez de alterar repetidamente o nome. Uma limitação de host DNS deve ser tratada por meio de um método documentado e suportado.
Teste cada domínio From exato e correspondência de rejeição
Envie conteúdo inofensivo através de cada aplicativo e servidor de material para destinatários externos controlados. Preservar a hora, o ID da mensagem e a referência de evento do provedor ou do aplicativo. Teste os subdomínios separadamente, em vez de assumir que uma entrada para o domínio pai os cobre.
A página CNAME mais antiga menciona PRA e Sender em sua descrição de aplicabilidade, enquanto a visão geral atual e a página TXT descrevem uma correspondência De exata. Se o aplicativo usar um cabeçalho Sender separado ou outra identidade incomum, obtenha esclarecimentos e teste esse formato exato. Não traduza silenciosamente essas declarações divergentes numa regra universal.
No destinatário, registre De, Return-Path visível, identidade SPF confiável e resultado, cada DKIM d e s, e o DMARC resultado. A verificação DKIM usa o domínio e o seletor na assinatura real para localizar a chave pública. RFC 6376 , seções 3.5 e 6.1.
Compare cada identidade de passagem com o visível sob o aplicável alinhamento modo. Um subdomínio de rejeição personalizado pode atender ao alinhamento SPF relaxado sem atender à igualdade estrita. Uma passagem alinhada Assinatura DKIM pode satisfazer independentemente DMARC . Nem a verificação de domínio bem-sucedida nem uma passagem de autenticação de domínio do provedor são suficientes para inferir o resultado completo. RFC 9989 , Alinhamento de Identificador Explicado e Avaliação DMARC.
Diagnosticar a camada com falha
Para um erro de remetente não permitido, inspecione a verificação e os controles de domínio do servidor correto antes de alterar as chaves DNS . Para um domínio de assinatura inesperado, compare o De exato com a entrada DKIM configurada. Para um Return-Path inesperado, inspecione a correspondência de rejeição e o padrão. Mantenha essas verificações separadas para que o reparo de uma não esconda um problema de outra.
Se a verificação criptográfica falhar apesar DNS correto, investigue as alterações no conteúdo assinado ou nos cabeçalhos ao longo do caminho. Se a autenticação e o alinhamento forem aprovados, mas o posicionamento da caixa de entrada for ruim, investigue a filtragem do destinatário, a reputação e a finalidade da mensagem. A autenticação não promete entrega nem torna legítimo todo uso de uma conta autorizada.
Recuperação de registros antes do lançamento
Preencha a planilha de domínio e servidor do SocketLabs (crie um registro de revisão separado com os campos descritos aqui). Mantenha uma matriz rota por rota de permissão, método de assinatura, mapeamento de devolução e evidências recebidas. Identifique quem pode pausar o aplicativo ou restaurar uma configuração de servidor aprovada anteriormente se o teste falhar.
Não exclua chaves públicas antigas ou registros de devolução enquanto mensagens na fila ou outros servidores dependerem deles. Planeje a descontinuação com o proprietário do aplicativo e teste novamente após alterações no domínio De, servidor, método de chave, padrão de rejeição ou provedor DNS .
Caso de diagnóstico fictício envolvendo uma entrada de devolução padrão
Apenas caso fictício escrito: SOCK-01 assume que um servidor envia From news@alpha.example com envelope bounces.alpha.example e um resultado SPF aprovado. Uma segunda rota usa From news@beta.example mas volta para bounces.alpha.example , também com passe SPF . Sob alinhamento relaxado, o primeiro envelope estipulado se alinha; o segundo não. Ambos os resultados DKIM são desconhecidos, portanto, nem uma falha completa na segunda mensagem nem um reparo bem-sucedido são reivindicados. O proprietário do servidor deve aprovar e verificar o mapeamento do beta e, em seguida, inspecionar o Return-Path e DKIM emitidos. Nenhum teste de servidor, DNS ou mensagem foi realizado.
A aceitação permanece pendente
Aceite a rota quando o servidor pretendido permitir o domínio, o método de assinatura selecionado for verificado, cada mapeamento de rejeição se comportar como aprovado e a evidência do receptor estabelecer a passagem alinhada necessária. A aceitação do escopo original, as verificações de locatário e DNS em tempo real, a revisão técnica independente, a revisão visual e a aprovação humana das PME permanecem pendentes para este rascunho não publicado.
Separe uma mensagem passageira da prontidão para aplicação
RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínio p=reject e alertas sobre a interoperabilidade de correio indireto. Um único resultado alinhado SPF não justifica, por si só, uma implementação de política de rejeição. Revise todas as rotas legítimas e propriedade de políticas separadamente da configuração deste provedor.