Comece com a jornada e transmita identidades
Uma conta Rejoiner pode enviar por meio de jornadas automatizadas e transmissões programadas. Identifique os fluxos de trabalho em uso antes de solicitar alterações DNS . Registre a marca, o proprietário da conta, o endereço De pretendido, a caixa de correio de resposta monitorada e um teste controlado para cada caminho. Use um cliente de teste e conteúdo inofensivo em vez de inscrever compradores reais ou gerar compras reais para fins de diagnóstico.
Reunião Documentação de configurações de e-mail coloca os detalhes do remetente padrão em Configurações e na guia E-mail. Ele distingue o nome de exibição, Endereço do remetente e Endereço de resposta. Compare esses padrões com a mensagem real a ser testada. Um nome de exibição familiar não estabelece qual domínio será autenticado.
A caixa de correio de resposta tem uma finalidade diferente dos domínios de assinatura e de envelope. Verifique se as respostas chegam à equipe pretendida, mas não trate uma resposta funcional como evidência de autenticação. Mantenha a decisão da marca e a tabela de identidade técnica juntas para que o proprietário do marketing possa ver o que os destinatários encontrarão.
Obtenha o conjunto de registros específico da conta atual
Reunião recurso de autenticação descreve assistência com a integridade da autenticação do cliente. Seu material público é um contexto útil, mas as fontes revisadas não fornecem uma visão completa específica do inquilino. seletor, chave, SPF autorização, procedimento de envelope personalizado ou sequência de ativação atual. Esses detalhes permanecem pendentes até serem fornecidos para a conta real.
Peça à equipe da conta o domínio de envio aprovado, proprietários e tipos exatos de registros DNS , valores públicos, valores esperados DKIM d=, envelope-domain behavior and any activation requirement. Confirm whether journeys and broadcasts use the same configuration. Request an explicit answer about custom envelope alinhamento em vez de presumir que a escolha de um De com marca altera automaticamente o Return-Path.
Não gere uma chave DKIM aleatória a partir de um tutorial genérico e publique-a para o Rejoiner. O serviço deve possuir a chave de assinatura correspondente e ser configurado para usar a identidade pretendida. Não copie o seletor de outro cliente nem infira uma inclusão SPF de um provedor upstream observado. A autoridade de configuração deve vir das instruções da conta suportada.
Escolha e documente o limite do domínio de envio
Reunião Guia de ferramentas do Google Postmaster diz que o Domínio do Remetente é normalmente um subdomínio reservado para Rejoiner ou correio de marketing. Trate isso como um padrão documentado, não como um nome de host obrigatório ou prova da configuração do locatário atual. Faça com que a empresa e os proprietários DNS aprovem o domínio realmente atribuído a este programa.
Anote como o De visível, o domínio de assinatura e o domínio do envelope se relacionam. No alinhamento relaxado, os domínios relacionados podem qualificar-se de forma diferente do que no alinhamento estrito. Não presuma que a criação de um subdomínio de marketing garante compatibilidade com uma política rígida existente. Resolva o design da identidade antes de configurar um novo endereço de campanha.
Mantenha os nomes de rastreamento de sites e os registros de verificação de monitoramento separados da autenticação de correio. As instruções do Postmaster do Rejoiner descrevem um documento emitido pelo Google Registro TXT para provar a propriedade do domínio desse serviço de monitoramento. A publicação desse token não ativa o Rejoiner DKIM nem fornece autorização SPF . Registre a finalidade de cada entrada DNS para que a limpeza futura não confunda o acesso analítico com a permissão de envio.
Publique apenas os registros de autenticação aprovados
Salve uma linha de base de registros DNS relevantes, seus nomes completos, tipos, valores e TTLs. Incluir SPF , DKIM e DMARC dependências para correspondência de funcionários e outras ferramentas de marketing. Confirme qual zona contém o subdomínio do remetente pretendido e se o editor anexa seu sufixo automaticamente.
Aplique cada registro emitido ao proprietário e tipo exatos. Compare a resposta pública resultante com as instruções do provedor, não apenas com a exibição do editor DNS . Se um seletor ou alias entrar em conflito com outro serviço, procure uma alternativa compatível em vez de substituir silenciosamente o registro do outro provedor. Mantenha a etapa de ativação e seu carimbo de data/hora com a alteração.
SPF sob RFC 7208 avalia a identidade SMTP em vez do visível De sozinho. Quando uma política SPF for necessária, mantenha uma única política nesse proprietário e revise o custo completo da consulta DNS, incluindo dependências aninhadas. Não expanda a autorização do domínio raiz apenas porque um artigo genérico de autenticação recomenda SPF .
Preservar a política DMARC existente da organização, os modos de alinhamento e os destinos dos relatórios, a menos que uma alteração aprovada separadamente seja justificada. Um novo programa de marketing deve se adequar ao projeto de autenticação do domínio. Não deve enfraquecer silenciosamente a proteção do correio dos funcionários ou de serviços transacionais não relacionados.
Exclua uma mensagem que nunca foi enviada
Antes de diagnosticar DKIM ausente, estabeleça que o teste produziu um email. O Guia de configurações de e-mail documenta a supressão de domínio e um limite de frequência para toda a conta em jornadas e transmissões. Esses controles podem impedir que um destinatário de teste específico receba uma nova mensagem. Revise as evidências relevantes da conta antes de alterar DNS ou acionar repetidamente o mesmo evento do cliente.
O mesmo guia diz que o BCC da conta se aplica a mensagens de viagem, não a transmissões, e alerta que o envolvimento do BCC pode distorcer os relatórios. Não use um BCC de transmissão ausente como prova de falha na entrega. Envie para um destinatário controlado através da rota real e preserve a evidência de entrega sem clicar desnecessariamente em links de rastreamento.
Se um fluxo de trabalho for suprimido, limitado ou nunca for acionado, resolva essa condição de teste por meio do proprietário apropriado. A autenticação é avaliada na correspondência que chega a um destinatário; uma decisão de não envio do lado do aplicativo não pode ser reparada adicionando um registro DNS . Mantenha esta distinção visível no registro de problemas.
Leia os cabeçalhos de ambos os fluxos de trabalho
Depois que a configuração estiver pronta, envie um e-mail de jornada controlada e uma transmissão controlada onde ambos estiverem no escopo. Capture Message-ID, hora UTC, From, Return-Path , cada DKIM d= e s=, e os resultados de autenticação confiável do sistema receptor final. Registre o identificador da viagem ou da transmissão para que as evidências possam ser reproduzidas.
Especificação do DKIM define o domínio de assinatura e o seletor. Inspecione cada assinatura e identifique qual delas, se houver, passa e se alinha com o De visível. Sob RFC 9989, DMARC requer um caminho SPF ou DKIM de passagem alinhado. Uma passagem de domínio de provedor não relacionada é insuficiente por si só.
Salve o resultado da autenticação separadamente do posicionamento e do engajamento. Uma taxa de abertura baixa não prova uma falha DKIM , e uma colocação na caixa de entrada não certifica todo o programa. Quando uma nova mensagem falhar, compare suas identidades observadas com a configuração emitida pela conta antes de escalar com um cabeçalho redigido e a hora UTC exata.
Planilha de aceitação de reingresso
Preencha entradas independentes para viagens e transmissões:
- Conta, marca, rota e proprietário da empresa: ____.
- Destinado, caixa de correio de resposta e domínio de envio aprovado: ____.
- Conjunto de registros do provedor e comportamento de assinatura/envelope compatível: ____.
- Proprietários exatos DNS , tipos, referências de valor e tempo de ativação: ____.
- Política DMARC existente e modos de alinhamento aplicáveis: ____.
- Verificações controladas de destinatário, gatilho, supressão e frequência: ____.
- ID da mensagem, hora UTC e identificador do fluxo de trabalho: ____.
- Return-Path , todos DKIM d= e s=, resultados confiáveis: ____.
- Mecanismo alinhado real e observação de posicionamento: ____.
- Ação de recuperação, revisor e questões de capacidade pendente: ____.
Mantenha a verificação de propriedade do Postmaster em uma linha de monitoramento separada. Ele pode suportar trabalhos de reputação posteriores, mas não pode preencher os campos de aceitação de autenticação.
Diagnóstico fictício de uma cópia de transmissão ausente
Apenas exemplo fictício: a Juniper Outfitters recebe cópias BCC de viagem, mas nenhuma transmissão BCC, e então propõe a substituição de seu registro DKIM . O administrador verifica o limite BCC documentado e testa a transmissão usando um destinatário real controlado. Essa cópia mostra DKIM alinhado e uma passagem DMARC .
A equipe deixa DNS inalterado e corrige seu método de coleta de evidências. Ele verifica separadamente os controles de frequência e supressão para destinatários de teste que não recebem nada. Nenhuma conta ou mensagem da Juniper foi inspecionada; o exemplo demonstra por que a evidência do fluxo de trabalho deve preceder um reparo de autenticação.
Deixe visíveis os recursos não resolvidos
Verifique novamente após alterações de remetente, novos fluxos de trabalho, migração DNS ou atualizações de chave de provedor. Valores DNS específicos da conta, suporte a envelope personalizado, inquilino ativo e verificação de cabeçalho, revisão visual, aprovação humana de PME e publicação permanecem pendentes. A documentação pública apoia as distinções de configurações acima, mas não fecha as portas de implementação.
Use as orientações do produto sem adotar atalhos de protocolo amplos
O recurso de autenticação geral é um plano de fundo, não uma chave emitida pela conta ou uma prova de que o correio autenticado é seguro. Use padrões de protocolo para avaliação de identidade e instruções emitidas pelo provedor para configuração. A transmissão fictícia de passagem é apenas um resultado estipulado ilustrativo, não um teste de inquilino Rejoiner realizado para esta revisão.
Separe a aceitação de mensagens da implementação de políticas
Um resultado SPF alinhado e aprovado pode satisfazer uma avaliação de mensagem, mas não justifica por si só mover um domínio inteiro para rejeição. RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínios p=reject e alerta sobre a interoperabilidade de correio indireto. Faça um inventário de todos os remetentes legítimos e rotas indiretas antes que o proprietário da política aprove a aplicação. Nenhuma alteração DNS , operação de locatário ou teste de mensagem recebida foi executada para este artigo.