Autenticar e-mail enviado pelo Zendesk : configuração e verificação

Escopo e pré-requisitos

Use este guia para envio Zendesk Support a partir de um endereço de suporte externo com domínio personalizado. Adicione esse endereço ao Zendesk antes de configurar a autorização de domínio. Endereços em domínios de caixas de correio públicas não podem usar DNS controlado pelo cliente e uma rota do conector Gmail precisa de verificação separada. O encaminhamento de entrada para um endereço de suporte não é prova de que a autenticação de saída está configurada.

Configure a rota documentada

• Etapa 1. Faça um inventário de todos os domínios externos usados ​​pelos endereços de suporte. Salve o atual SPF política e seletor registros antes de alterá-los.
• Etapa 2. Adicionar include:mail.zendesk.com à política SPF TXT única do domínio, preservando outros remetentes autorizados. O exemplo do Zendesk apenas para seu serviço é v=spf1 include:mail.zendesk.com -all. Suas instruções atuais exigem a inclusão na primeira camada de pesquisa; validar a política resultante em vez de aninhá-la de forma invisível dentro de outro include.
• Etapa 3. Publique dois CNAMEs para cada domínio externo: zendesk1. _domainkey apontando para zendesk1._domainkey.zendesk.com, e zendesk2. _domainkey apontando para zendesk2._domainkey.zendesk.com. Os rótulos de host são relativos ao domínio externo, a menos que seu console DNS precise do nome completo.
• Passo 4. Confirme ambos CNAME as respostas estão disponíveis no DNS oficial e por meio dos resolvedores usados ​​para verificação. Mantenha ambos os registros; O método documentado do Zendesk acomoda a rotação de chaves sem substituição manual de chaves.
• Etapa 5. Somente depois que DNS estiver pronto, abra Admin Center, Channels, Talk and email, Email. Nas configurações de e-mail, habilite Domínio personalizado para DKIM e salve. Zendesk alerta que habilitar a opção antes da existência dos CNAMEs pode causar falhas na entrega.
• Etapa 6. Gere uma resposta de ticket comum de cada identidade de suporte relevante. Salve a mensagem bruta entregue e inspecione os resultados da autenticação do destinatário, não apenas o aviso da interface do agente.

Riscos específicos do produto

O erro de pedido de maior risco é ativar a assinatura de domínio personalizado antes de publicar ambos os CNAMEs. Se isso aconteceu, repare os registros e avalie a correspondência na fila com o proprietário do suporte. Evite um domínio inteiro DMARC relaxamento como solução alternativa para uma rota. A validação SPF também pode falhar quando outra inclusão na mesma política for inválida; adicionar Zendesk novamente não resolve isso. Não autorize sistemas de terceiros a enviar mensagens de um subdomínio de propriedade da Zendesk.

Prove a rota na extremidade receptora

Use uma caixa de correio externa aprovada e salve a mensagem bruta completa com seu carimbo de data/hora e identificador de mensagem. Nenhum teste de inquilino ativo é reivindicado neste guia. A seguir está uma planilha de aceitação para ser preenchida durante a implementação, não um recorde dos resultados observados.

• Campo de evidência: Visível de; O que registrar: Endereço e domínio reais; Pergunta de aceitação: esta é a identidade do remetente pretendido?
• Campo de evidência: Envelope; O que gravar: Return-Path e domínio SPF relatado pelo receptor; Pergunta de aceitação: Qual domínio SPF realmente autenticou?
• Campo de evidência: SPF ; O que registrar: Resultado do receptor confiável e identidade avaliada; Pergunta de aceitação: foi aprovado e essa identidade está alinhada?
• Campo de prova: DKIM ; O que registrar: Todo d= domínio, s= resultado do seletor e do receptor; Pergunta de aceitação: pelo menos uma assinatura aprovada está alinhada?
• Campo de evidência: DMARC ; O que registar: Resultado do receptor e política aplicável; Pergunta de aceitação: Existe um caminho de passagem alinhado?
• Campo de evidência: Rota; O que registrar: Produto, conta e tipo de mensagem; Pergunta de aceitação: O teste utilizou o caminho de produção?

DMARC precisa de pelo menos um caminho SPF ou DKIM alinhado e de passagem. Uma assinatura de passagem de um domínio de serviço não relacionado não é suficiente. Estrito alinhamento requer igualdade exata de domínio; o alinhamento relaxado usa o relacionamento de domínio organizacional aplicável. Verifique as configurações reais de alinhamento do domínio antes de declarar sucesso. Um subdomínio não é uma correspondência estrita automática. SPF usa a identidade SMTP , não o nome de exibição ou Responder para. Consulte o glossário de alinhamento ao registrar a decisão.

Usar Authentication-Results do sistema receptor em que você confia, não de um cabeçalho fornecido por um remetente arbitrário. Capture todas as assinaturas em vez de parar na primeira falha. Para correspondência encaminhada, compare um teste direto com uma cópia encaminhada: o encaminhamento pode alterar a avaliação SPF ou alterar o conteúdo assinado. Não diagnostique esses efeitos adicionando o endereço do remetente à autorização do seu provedor.

Diagnosticar falhas sem ampliar o acesso

Compare primeiro DNS autoritativo com os nomes de registro exatos configurados e, em seguida, verifique a visibilidade recursiva e a validação do serviço. Um nome errado, uma chave truncada ou CNAME conflitante não são corrigidos aguardando os caches. Mantenha apenas uma política SPF por proprietário e verifique o limite de dez prazos de pesquisa de DNS nas inclusões e redirecionamentos avaliados antes de mesclar outro remetente. Os seletores DKIM pertencem a configurações de assinatura individuais; não substitua o registro de outro aplicativo para forçar um resultado de validação.

Se a autenticação for aprovada, mas a entrega for ruim, inspecione a resposta do destinatário, a reputação, o conteúdo e as permissões de envio separadamente. O passe DMARC não promete aceitação ou colocação na caixa de entrada. Se nenhum dos caminhos estiver alinhado, interrompa a expansão e corrija a configuração real do remetente. Não enfraqueça a política DMARC de todo o domínio para esconder uma única falha do produto.

Transferência e recuperação

Salve a diferença DNS aprovada, os resultados da pesquisa pública, o status do serviço e a planilha de mensagens recebidas redigida com um proprietário nomeado. Mantenha credenciais e chaves privadas fora dos tickets. Em caso de falha, pause o trabalho de envio afetado ou use uma rota previamente testada sob o controle do proprietário do serviço. Restaure apenas os registros alterados que pertencem a esta integração; mantenha as chaves públicas necessárias para mensagens em trânsito. Teste novamente após reversão, rotação de chave, migração de domínio ou alteração na retransmissão de saída. Feche a mudança somente quando o proprietário do produto e o administrador de correio puderem explicar a cadeia de identidade observada.

Confirme o limite do provedor

A página SPF identifica include:smtp.zendesk.com e include:support.zendesk.com como alternativas mais antigas. Revise qualquer migração com o proprietário DNS em vez de manter autorizações duplicadas indefinidamente. O conector Gmail tem sua própria recomendação SPF ; não a trate silenciosamente como a mesma rota de ticket de domínio externo. A rotação trimestral de chaves declarada depende da retenção de ambos os CNAMEs gerenciados.

Trabalhe em um caso de diagnóstico fictício

Apenas caso escrito fictício: ZD-01 assume que uma resposta de ticket usa From help@studio.example com uma assinatura d=studio.example com falha no seletor zendesk1 e DNS autoritativo não possui esse CNAME . SPF e outras assinaturas são desconhecidas; a falha total DMARC não foi estabelecida. O proprietário do suporte deve interromper a expansão, restaurar o pré-requisito documentado DNS e testar novamente a rota do ticket, em vez de afrouxar toda a política de domínio. Um avanço funcional não é uma prova contrária. Nenhum locatário, DNS , comando de servidor ou mensagem foi exercido neste caso.

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.