MTA-STS permite que um domínio receptor publique expectativas para entrega TLS autenticada. Ele aborda a conexão SMTP com o serviço receptor. Ele não autentica o endereço De do autor da mensagem nem criptografa a mensagem do dispositivo de uma pessoa para outro.
Uma implantação funcional conecta três coisas: as rotas MX de entrada reais do domínio, a política HTTPS e o registro DNS que sinaliza essa política. Os relatórios TLS fornecem um caminho de feedback separado.
Estabeleça o limite real de recebimento
Referências: RFC 8461 §3.4, RFC 8461 §4.
Liste os hosts MX que aceitam correio para o domínio, incluindo serviços de backup e um gateway de segurança upstream. Verifique o comportamento TLS e do certificado no limite de recebimento público real, não apenas em um servidor de caixa de correio interno.
Registre quem é o proprietário da rota MX , hospedagem de políticas, renovação de certificados e destino de relatórios. Um serviço de caixa de correio hospedado não necessariamente hospeda a política MTA-STS do cliente nem opera todos os gateways à sua frente.
Avalie os subdomínios separadamente. MTA-STS não usa herança de política pai no estilo DMARC. Um subdomínio receptor precisa da configuração aplicável a esse domínio.
Crie uma política para os hosts reais
Referências: RFC 8461 §3.2, RFC 8461 §3.3.
Sirva a política no local HTTPS necessário para o domínio de recebimento. Por example.com , o local é https://mta-sts.example.com/.well-known/mta-sts.txt. O serviço HTTPS precisa de um certificado válido para seu nome de host de política.
A política identifica sua versão, modo, padrões MX permitidos e vida útil máxima do cache. Comece com uma implantação de teste apropriada ao escopo e inspecione os resultados antes da aplicação. Escolha o período de observação a partir do tráfego e das dependências reais, em vez de tratar uma duração de amostra como prova universal.
Uma política ilustrativa para um domínio MX único fictício é:
versão: modo STSv1: teste mx: mx1.example.net max_age: 86400Este exemplo pressupõe que mx1.example.net é o host receptor real do domínio e tem suporte SMTP TLS apropriado. Não é uma política pronta para outro fornecedor. Combine os hosts permitidos com precisão e inclua todas as rotas de recebimento legítimas.
Publicar descobertas e relatórios separadamente
Referências: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
Em _mta-sts.example.com , um valor TXT ilustrativo é v=STSv1; id=2026110701. O identificador sinaliza uma revisão da política. Publique e verifique a política antes de anunciar sua nova revisão no DNS .
TLS-RPT usa seu próprio registro em _smtp._tls.example.com . Uma solicitação ilustrativa é v=TLSRPTv1; rua=mailto:tls-reports@example.com, assumindo que o endereço existe e seu caminho de coleta funciona.
Não assuma um DMARC O destino rua recebe automaticamente relatórios TLS ou apenas o teste MTA-STS cria uma solicitação de relatório funcional. Verifique cada registro com o nome correto e cada destino por meio de seu próprio processo de coleta.
Teste a cadeia implantada
Referências: RFC 8461 §4, RFC 8461 §6.
Busque a política externamente e confirme se o endpoint HTTPS necessário atende ao corpo de texto simples pretendido com HTTP 200. Não siga redirecionamentos HTTP: um redirecionamento não é uma busca de política válida sob RFC 8461 §3.3. Verifique DNS de descoberta e compare todas as rotas MX anunciadas com os padrões permitidos.
Teste SMTP TLS e validação de certificado em cada rota de recebimento. Um certificado da web funcional em mta-sts.example.com não estabelece que o servidor MX apresenta um certificado SMTP válido.
Revise os relatórios TLS disponíveis e as evidências de entrega controlada. Os serviços de envio diferem na participação, portanto o silêncio não estabelece o sucesso universal. Mantenha o repórter, o intervalo e MX afetado em cada observação.
Em um caso sintético, uma política permite apenas o gateway principal, enquanto DNS também anuncia um MX de backup. O backup aceita mensagens em testes comuns, mas falha na correspondência de política. Reparar a política ou o design de roteamento antes da aplicação; não descarte o backup porque seu volume diário é pequeno.
Planeje a aplicação e a recuperação de caches
Referências: RFC 8461 §5, RFC 8461 §8.3.
O modo de aplicação pode impedir que remetentes de suporte façam entregas por meio de uma conexão não compatível. Remetentes que não apoiam estão fora dessa garantia. Registre a dependência e a resposta operacional aceitável antes de alterar o modo.
Os caches do remetente podem reter políticas anteriores válidas para seu max_age. Excluir DNS de descoberta ou desativar o endpoint HTTPS não é uma reversão global imediata. Para retirada, publique uma política válida mode: none com vida útil curta e, em seguida, atualize o ID de descoberta. Mantenha ambos os pontos finais disponíveis até que todas as políticas anteriores expirem, incluindo revisões mais antigas com vidas úteis mais longas. Conte cada tempo de vida a partir da última vez que a revisão foi veiculada, e não apenas a partir da próxima edição.
Para uma migração de gateway, torne a política compatível com a transição planejada, verifique a nova rota e permita versões em cache. Mantenha o endpoint da política disponível enquanto os remetentes relevantes ainda podem contar com ele.
A transferência deve juntar a configuração MX , o histórico da política, a propriedade do certificado e o tratamento de relatórios. MTA-STS permanece útil quando essas partes móveis são mantidas juntas.