Autenticar e-mail enviado através do Yandex: configuração e verificação

Escopo e pré-requisitos

Este guia cobre um domínio personalizado conectado ao Yandex 360 for Business. Endereços Yandex de consumidores e aplicativos independentes que apenas usam uma caixa de entrada Yandex são caminhos diferentes. Comece com o administrador de domínio da organização e a pessoa que controla o DNS autoritativo. Um domínio delegado ao Yandex tem SPF e DKIM configurado automaticamente de acordo com a documentação atual do Yandex; DNS externo requer as etapas manuais abaixo. A configuração automática ainda precisa de um teste de mensagem recebida.

Configure a rota documentada

• Passo 1. Abra a página Domínios da organização e confirme se o domínio de envio exato está conectado e verificado. Faça um inventário de outros remetentes legítimos antes de alterar sua política SPF .
• Etapa 2. Para um domínio de envio exclusivamente Yandex, o valor SPF TXT documentado é v=spf1 redirect=_spf.yandex.net. Se outros serviços também enviarem, crie uma política combinada usando o documento include:_spf.yandex.net e os demais mecanismos autorizados. Não anexe um todos mecanismo para uma política destinada a confiar no redirecionamento: uma avaliação todos evita alcançar o redirecionamento.
• Etapa 3. Em Domínios, escolha Adicionar DKIM para o domínio. Copie sua chave pública do Configure Assinatura DKIM, em vez do exemplo abreviado na documentação.
• Etapa 4. Publique essa chave como um Registro TXT no correspondência. _domainkey em relação ao domínio de envio. Alguns consoles DNS exigem o nome completo. Verifique o nome totalmente qualificado salvo para evitar adicionar o domínio duas vezes. O TTL documentado quando necessário é de 21.600 segundos.
• Etapa 5. Volte para Domínios, escolha Verificar seu domínio e Verificar. Yandex avisa que as atualizações DNS podem levar até 72 horas. Diagnosticar primeiro a resposta oficial, em vez de tratar esse máximo como uma espera obrigatória.

Riscos específicos do produto

Uma política SPF somente de redirecionamento é um substituto cego e insatisfatório para um domínio que também envia faturas ou correspondências de marketing para outro lugar. Preserve esses remetentes na política única. Se DKIM permanecer não verificado, compare a chave pública completa, o proprietário TXT e o ativo servidores de nomes. Nunca cole a chave truncada de amostra. Uma tela verde de domínio não é evidência de que um aplicativo realmente foi enviado por meio da rota Yandex pretendida.

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: Cada domínio d=, s= seletor e resultado 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, chave truncada ou conflito CNAME não é corrigido aguardando por 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

Use o domínio conectado e verificado do administrador da organização, não uma identidade de caixa de correio do consumidor. O TTL documentado de 21.600 segundos é de seis horas quando o campo é obrigatório, e não há evidência de que qualquer consulta foi atualizada. Para um domínio ausente ou um seletor de e-mail ocupado, confirme a propriedade da conta e DNS antes de substituir os registros. Nenhuma garantia de aceitação do destinatário decorre da configuração automática.

Trabalhe em um caso de diagnóstico fictício

Apenas caso escrito fictício: YA-01 pressupõe que o domínio envia por meio do Yandex e de um serviço de faturamento separado. Uma operadora propõe substituir a política SPF mesclada pelo redirecionamento somente Yandex. Nenhuma identidade SPF avaliada ou resultados DKIM são fornecidos. O proprietário DNS deve reter a autorização aprovada do serviço de fatura em uma política revisada e testar ambas as rotas. Nenhuma falha na fatura ou reparo bem-sucedido é declarado. Nenhum locatário, DNS , comando de servidor ou mensagem foi exercido neste caso.

Separe uma mensagem passageira da prontidão para aplicação

A Seção 7.4 RFC 9989 exige DKIM válido para uma publicação de domínio p=reject e alerta 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.