Escolha a rota e as identidades Postmark
Este guia cobre mensagens de saída realmente enviadas ao Postmark , não a um site que usa apenas Postmark para processamento de entrada. Registre o aplicativo, o servidor Postmark e o fluxo de mensagens, o domínio De pretendido e o administrador DNS . Um recibo enviado por um aplicativo diferente deve ser testado separadamente, mesmo quando sua marca parecer idêntica. Antes de alterar DNS , salve os registros existentes e uma mensagem de linha de base do fluxo de trabalho exato.
O fluxo de trabalho de verificação de domínio do Postmark fornece um DKIM Registro TXT e personalizado Return-Path CNAME. Um domínio verificado permite o envio de endereços de todo esse domínio, portanto, a verificação do domínio deve pertencer à equipe autorizada a representá-lo. Use os valores mostrados para o seu domínio, e não valores de um locatário diferente. Verificação de domínio Postmark.
Habilite a assinatura antes de alterar a política
Abra Assinaturas do remetente, escolha o domínio e insira as configurações DNS . Copie o nome do host DKIM e o valor para um registro TXT no provedor DNS autoritativo. Verifique se o editor DNS anexa o nome da zona; um sufixo duplicado colocará a chave no local errado. Retorne ao Postmark e verifique o registro. Postmark documenta verificações automáticas em 48 horas e um controle de verificação manual. A assinatura começa após a verificação. Configuração DKIM.
Não trate o status verde como o teste de aceitação final. Estabelece que o provedor encontrou um recorde, não que seu aplicativo de produção tenha usado o endereço De pretendido ou que um gateway posterior tenha preservado a assinatura. Agende um envio controlado após verificação e preserve a mensagem original do destinatário, incluindo todas as assinaturas DKIM .
Adicione o Return-Path compatível separadamente
Use o nome do host Return-Path exibido nas mesmas configurações de domínio e seu destino CNAME , documentado como pm.mtasv.net . Reserve um nome de host não utilizado para esta finalidade. Não coloque um SPF Registro TXT ao lado de um CNAME com o mesmo nome de proprietário e não substitua seus registros apex pelo CNAME de rejeição. A documentação Postmark mostra diferentes grafias de nome de host padrão, portanto, o valor da conta ativa tem precedência sobre um exemplo copiado. Verificação de domínio.
Postmark não exige a sua inclusão no ápice do cliente Registro SPF. A verificação SPF segue o domínio real do envelope. Adicionar um apex include não pode converter um Return-Path de propriedade do provedor em um Return-Path de propriedade do cliente. O Return-Path personalizado documentado é um subdomínio; Postmark aconselha SPF relaxado alinhamento para este percurso. Um requisito estrito SPF não é corrigido pela adição de mais inclusões. Preserve a política aprovada do domínio e use um caminho DKIM alinhado e verificado quando apropriado. Orientação SPF Postmark.
Prove o resultado da aplicação
O que se segue é um projeto de aceitação sintético, não uma entrega capturada. Substitua cada exemplo pelo valor observado e mantenha o carimbo de data/hora e o ID da mensagem do teste.
- Evidência: Visível de; Valor ilustrativo: receipts@example.com ; Pergunta de aceitação: Esta é a identidade do aplicativo aprovado?
- Evidência: Domínio do envelope; Valor ilustrativo: pm-bounces.example.com ; Pergunta de aceitação: O Return-Path personalizado foi ativado nesta mensagem?
- Evidência: domínio de assinatura DKIM ; Valor ilustrativo: example.com ; Pergunta de aceitação: O receptor confiável validou esta assinatura?
- Evidência: DMARC; Valor ilustrativo: aprovado; Pergunta de aceitação: Qual método de passagem alinhado produziu este resultado?
- ra A partir do domínio example.com e de um subdomínio de rejeição abaixo dele, o alinhamento SPF relaxado pode funcionar, enquanto o alinhamento SPF estrito não. Uma passagem de domínio exato Assinatura DKIM ainda pode satisfazer DMARC . Avalie a assinatura observada, não uma promessa de que todas as mensagens sejam assinadas. Alinhamento DMARC.
Teste um recibo real e um evento de redefinição de senha por meio dos respectivos caminhos de aplicativos. Compare seus fluxos e configuração do remetente. Se um passar e o outro falhar, investigue a rota divergente antes de alterar DNS compartilhado. Não reenvie recibos financeiros genuínos aos clientes como teste.
Diagnosticar e recuperar
Se DKIM estiver ausente, confirme se o domínio De do aplicativo corresponde ao domínio verificado e se a assinatura está ativa. Se a assinatura existir, mas falhar, preserve o motivo do destinatário e inspecione o exato seletor pesquisa e qualquer retransmissão de modificação de conteúdo. Se SPF for aprovado, mas estiver desalinhado, inspecione a ativação Return-Path em vez de adicionar permissões apex. Se a verificação DNS falhar, compare as respostas oficiais, complete o nome do host e o tipo de registro com os valores da conta.
Pause somente o fluxo do aplicativo afetado se a aceitação falhar. Restaure o registro salvo ou a configuração do remetente por meio do proprietário da alteração e teste novamente um evento controlado. Não remova um seletor antigo enquanto o correio na fila ainda precisar dele. Retire a delegação de rejeição e os registros de assinatura não utilizados somente depois de confirmar que nenhum outro aplicativo Postmark os compartilha. Este manuscrito é baseado em documentação; nenhum locatário, alteração DNS ou entrega ao vivo foi testado.
Compare resultados estritos e relaxados explicitamente
Para o caso escrito PM-01, assuma From receipts@example.com , CORREIO DE bounce@pm-bounces.example.com e um passe SPF confiável para pm-bounces.example.com . Sob o alinhamento relaxado comum do mesmo domínio organizacional, esse caminho SPF se alinha; com aspf=s não corresponde exatamente example.com . Suponha separadamente uma assinatura de passagem d=example.com, s=demo1: esse caminho se alinha exatamente e pode satisfazer DMARC mesmo no caso de SPF estrito. Se DKIM se tornar desconhecido em vez de aprovado, não retenha uma aprovação com base na premissa anterior. Estes são contributos estipulados e não uma entrega capturada Postmark ou um conselho para enfraquecer uma política.
Preservar o limite de aplicação
A Seção 7.4 RFC 9989 exige DKIM válido, e não apenas SPF , para domínios que publicam p=reject, e alerta sobre a interoperabilidade de correio indireto e lista de discussão. Um único teste bem-sucedido de mensagem direta não é prova de que todas as rotas legítimas estejam prontas para políticas mais fortes. Mantenha a proteção aprovada existente enquanto diagnostica a lacuna real; qualquer mudança política necessita da sua própria decisão.