Permissão separada para enviar da autenticação
ReachMail tem duas verificações de domínio distintas. Validação do domínio de envio confirma permissão para usar um domínio de endereço em campanhas. A autenticação de domínio conecta o correio enviado a evidências baseadas em DNS. O preenchimento de um link de verificação enviado por e-mail não prova que uma campanha subsequente terá um resultado alinhado SPF ou DKIM identidade.
Escolha o domínio de propriedade e o endereço De pretendido antes de alterar as configurações. O guia de validação do ReachMail exclui domínios de webmail gratuitos como Gmail , Yahoo e AOL para este uso. Cadastre o proprietário do negócio, caixa de correio de resposta e conta responsável por cada marca. Mantenha os diferentes domínios de clientes ou marcas separados, em vez de presumir que uma aprovação se estende aos demais.
O lista de verificação de primeiros passos diz que DKIM , SPF e rastreamento padrão usam domínios compartilhados gerenciados pelo ReachMail. Isto explica por que a autenticação básica pode já existir sem provar alinhamento para o De visível da organização. O objetivo de aceitação é uma mensagem controlada usando a identidade pretendida do cliente, e não simplesmente uma declaração de que a plataforma assina seu e-mail.
Valide o domínio da campanha
O caminho de validação documentado é Conta, Configurações de campanha, Domínios de envio. Um e-mail de verificação é enviado para um endereço no domínio selecionado e seu link de confirmação conclui essa etapa. Use uma caixa de correio controlada pela organização e registre o resultado da aprovação. Se a mensagem estiver faltando, investigue a entrega nessa caixa de correio em vez de adicionar novos domínios repetidamente.
ReachMail instruções de validação também descrevem um cadeado indicando se um DMARC política é detectada. Trate isso como um indicador de presença política. Não é o resultado de uma mensagem recebida, uma avaliação de cada remetente autorizado ou uma prova de que os domínios autenticados da campanha estão alinhados.
Verifique o endereço real de origem e de resposta na correspondência a ser testada. Um padrão salvo e a identidade selecionada em uma campanha existente podem ser diferentes, portanto verifique o objeto final antes de enviar. Obtenha aprovação antes de revogar um domínio usado por campanhas ativas. A limpeza não deve remover inesperadamente a identidade de envio necessária para uma mensagem comercial agendada.
Gere as instruções de autenticação para o domínio correto
O Guia de instalação DKIM direciona os administradores para a guia Conta, Configuração de campanha e Autenticação de domínio e, em seguida, para adicionar o domínio e o subdomínio aplicável. Sua página de configuração apresenta instruções SPF , DKIM e DMARC . Capture os valores exatos emitidos para a conta e o domínio selecionados.
Crie uma planilha de alterações DNS listando cada proprietário completo, tipo de registro, valor e finalidade. Confirme se o editor DNS espera um rótulo curto ou um nome de domínio completo. Preserve os registros existentes nesses proprietários e resolva os conflitos antes da substituição. O guia público explica o fluxo de trabalho; ele não fornece uma chave universal para copiar em cada zona do cliente.
As instruções DKIM identificam o registro e os dados da chave TXT a serem publicados, seguidos por Check Current DNS . ReachMail recomenda esperar pelo menos dez minutos antes de verificar novamente. Trate isso como uma orientação mínima do provedor, não como uma promessa de que todos os caches ou verificações de aplicativos serão atualizados em um prazo fixo. Compare a resposta oficial, o TTL relevante e o valor esperado antes de repetir uma alteração.
Mesclar SPF com cuidado e manter a propriedade DMARC
ReachMail Instruções SPF exibir um registro existente e a adição necessária e alertar contra a remoção de autorizações existentes. Interprete isso como a atualização de uma política SPF no proprietário pretendido, e não como a criação de outra política SPF separada. Preserve os serviços legítimos que ainda precisam ser enviados.
RFC 7208 define Registro SPF seleção e o limite de dez prazos para mecanismos de consulta de DNS e modificadores durante a avaliação. Revise inclusões e redirecionamentos aninhados, não apenas o número de termos de inclusão visíveis. Se a política combinada proposta exceder o limite ou tiver dependências pouco claras, resolva esse design antes da implementação.
SPF é avaliado em relação à identidade SMTP , normalmente o CORREIO DE domínio, não apenas o endereço De visível. A adição de um domínio raiz por si só não prova que o ReachMail usa um envelope de cliente alinhado. As páginas de configuração revisadas não estabelecem o comportamento do envelope personalizado da sua conta; mantenha essa reivindicação pendente até que as instruções atuais do provedor e um cabeçalho real a confirmem.
Inspecione o existente Registro DMARC antes de aplicar um valor sugerido. Preservar sua política aprovada, modos de alinhamento e destinos de relatórios. Um assistente de configuração de campanha não deve substituir silenciosamente uma decisão de segurança compartilhada por todos os remetentes no domínio. Qualquer alteração na aplicação também precisa da revisão do proprietário do domínio e de evidências de outras rotas legítimas.
Teste a campanha que realmente será enviada
Registre o status da autenticação de domínio e as respostas DNS públicas após a publicação. Em seguida, envie uma campanha inofensiva para uma pequena lista controlada. Verifique se a campanha usa o De pretendido em vez do padrão antigo. Inclua um destinatário interno como um caso separado se os anúncios dos funcionários fizerem parte do roteiro.
Salvar ID da mensagem, hora UTC, De, Return-Path, todos os domínios e seletores de assinatura DKIM e resultados de sistemas de recebimento confiáveis. RFC 6376 define os identificadores DKIM d= e s=. Inspecione cada assinatura: uma assinatura de domínio compartilhado de passagem pode coexistir com uma assinatura de domínio do cliente, e esta última precisa de seu próprio resultado.
Especificação atual do DMARC requer uma identidade SPF ou DKIM de passagem alinhada. Registre qual mecanismo observado fornece a passagem e qual modo de alinhamento se aplica. Um passe DKIM de domínio do cliente pode estabelecer DMARC mesmo quando o envelope permanece de propriedade do provedor, mas os requisitos de configuração do provedor ainda precisam ser atendidos.
Registre a autenticação e o posicionamento separadamente. A entrega ao lixo eletrônico pode ocorrer apesar de uma passagem alinhada, e uma mensagem aceita devido a uma exceção local pode ocultar uma rota não verificada. Se nenhuma cópia chegar, correlacione a atividade da campanha e as informações de devolução antes de alterar DNS . Repetir o envio completo do público não é um teste de diagnóstico apropriado.
Planilha de aceitação do ReachMail
Preencha uma linha por domínio de campanha e rota de envio relevante:
- Conta, marca, proprietário da empresa e destino De: ____.
- Caixa de correio de verificação do domínio de envio e tempo de conclusão: ____.
- Identidade da campanha e endereço de resposta verificados: ____.
- Instruções SPF , DKIM e DMARC emitidas pela conta: ____.
- Proprietários completos DNS , referências de valor e conflitos existentes: ____.
- Revisão combinada da política SPF e política DMARC mantida: ____.
- Respostas DNS público e verificação do resultado DNS atual: ____.
- Message-ID, hora UTC, Return-Path e todos os identificadores DKIM : ____.
- Resultados de autenticação confiável e mecanismo real alinhado: ____.
- Ação de recuperação, revisor de liberação e gatilho de nova verificação futura: ____.
Um domínio verificado ou cadeado fechado não pode preencher os campos de evidência da mensagem. Deixar o percurso pendente até que a campanha pretendida seja recebida e verificada.
Diagnóstico fictício de um indicador verde enganoso
Apenas exemplo fictício: Maple Studio verifica seu domínio de envio e vê um cadeado fechado. A equipe presume que a autenticação personalizada foi concluída. Uma campanha controlada mostra apenas um domínio de assinatura compartilhado e um envelope desalinhado, portanto, DMARC falha no De visível do estúdio.
O administrador abre a Autenticação de Domínio, recupera as instruções DKIM do cliente emitidas pela conta e conclui a alteração DNS aprovada. Uma nova campanha é verificada quanto ao seu domínio de assinatura real e resultado alinhado antes que o envio mais amplo seja retomado. A política DMARC existente permanece em vigor. Nenhuma conta, domínio ou mensagem Maple foi inspecionada; esta é uma distinção ilustrativa entre aprovação, presença de política e autenticação de mensagens.
Manter o inventário de domínio aprovado
Verifique novamente após alterações no domínio do remetente, movimentações DNS , migração de conta ou substituição de chave. Revise as campanhas programadas antes de retirar uma identidade verificada ou registro delegado. A inspeção de inquilinos em tempo real, valores específicos da conta, evidências DNS e mensagens recebidas, confirmação de envelope personalizado, revisão visual, aprovação humana de PME e publicação permanecem pendentes. Este guia aborda campanhas de marketing ReachMail; produtos de relé separados exigem suas próprias instruções e testes atuais.
Registre qual indicador verde foi verificado
Use campos de planilha separados para aprovação de domínio por e-mail, política DMARC detectada, status de autenticação DNS e alinhamento de campanha recebida. Registre o identificador da campanha ao lado do último item. O exemplo fictício não estipula nenhum mecanismo de passagem alinhado; isso não prova que um envelope desalinhado por si só sempre causa falha DMARC , porque DKIM alinhado ainda pode fornecer uma passagem.
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.