Para o Higher Logic Vanilla, trate a autenticação do remetente como uma comunidade coordenada, suporte e alteração DNS . Este não é um guia para um fórum de código aberto instalado de forma independente ou para um produto de e-mail diferente da Higher Logic. Primeiro identifique a comunidade e sua identidade de remetente público aprovada; um endereço de notificação não deve expor acidentalmente o endereço privado de um administrador.
Coordene a configuração suportada
Revise Painel > Configurações > Comunicações > Configurações de e-mail e o nome e endereço do remetente de saída. Peça ao Suporte Vanilla para confirmar essas configurações e fornecer os registros DNS por meio de sua equipe de operações. O proprietário DNS implementa os registros fornecidos e o Suporte confirma a ativação. O guia público identifica SendGrid como o serviço de envio. Também diz que o suporte deve confirmar o caminho de retorno domínio e se include:vanilla.email ou include:sendgrid.net se aplica. Não autorize ambos por suposição. Referência de autenticação de remetente Vanilla
Mantenha uma cópia dos nomes, tipos e valores dos proprietários fornecidos pelo suporte com a alteração aprovada. Não reutilize os seletores de outra comunidade. Quando um nome de proprietário proposto já tiver um CNAME, resolva o conflito de nome antes de tentar adicionar dados TXT lá. Escolher uma identidade de correio separada pode ser mais seguro do que alterar os registros usados pelo site da comunidade.
Teste as consequências específicas da comunidade
Exerça uma notificação de que os membros realmente assinaram, usando uma conta de teste controlada e um destinatário. Confirme o remetente visível, o comportamento de resposta e a autenticação separadamente. O carregamento bem-sucedido do site não testa o e-mail, e uma visualização do modelo não prova o caminho real de envio da notificação. Evite enviar um anúncio amplo apenas para obter uma amostra de cabeçalho. Se uma classe de notificação for diferente, investigue a sua rota em vez de tratar uma única amostra passageira como prova de cada mensagem da comunidade.
O aviso do guia público sobre um CNAME de domínio personalizado diz respeito ao mesmo nome de proprietário DNS : não é uma proibição para todos os domínios De personalizados. Preserve o registro do site e peça ao suporte para identificar os nomes de e-mail apropriados. Registre quem confirmou a ativação e quando, não apenas quando DNS foi salvo.
Verifique DNS e um resultado de recebimento real
Antes de alterar as configurações do remetente de notificação da comunidade, exporte os valores DNS existentes, registre a diferença aprovada e nomeie o proprietário da reversão. Confirme se o editor DNS espera um rótulo relativo ou um nome totalmente qualificado; duplicar o sufixo de domínio cria um recorde que nenhum verificador pretendido encontrará. Consulte o nome real do proprietário após salvar, incluindo qualquer destino CNAME , em vez de confiar no banner de sucesso do editor.
SPF deve permanecer uma política no domínio relevante e permanecer dentro dos limites de prazo de consulta de DNS em RFC 7208. Adicionar um include por si só não estabelece alinhamento. Sob RFC 9989, DMARC passa quando pelo menos um SPF ou DKIM o resultado se alinha com o domínio De visível no modo aplicável. Não exija que ambos os mecanismos se alinhem como uma condição imposta pelo padrão e não confunda uma passagem de domínio de provedor com uma passagem de domínio de cliente alinhada.
Envie uma notificação da comunidade inscrita por meio do fluxo de trabalho da comunidade ao vivo para uma caixa de correio que você controla. Salve os resultados de autenticação confiável do sistema receptor, De visível, identidade do envelope, valores DKIM d= e s=, carimbo de data/hora e status do provedor. Uma pesquisa DNS mostra apenas a chave disponível; RFC 6376 a verificação também avalia a assinatura da mensagem recebida. Use conteúdo não confidencial e evite expor mensagens completas dos clientes a verificadores públicos.
Use uma decisão limitada de aceitação e reversão
Apenas caso de diagnóstico escrito fictício: VA-01 assume community.example é um CNAME de site e um operador propõe colocar um SPF TXT no mesmo nome de proprietário. A notificação pretendida é community@example.org , mas as identidades/resultados do envelope e DKIM permanecem desconhecidos. O proprietário da comunidade deve obter os nomes exatos dos proprietários de e-mail do Suporte e resolver a colisão de nomes de sites sem alterar o roteamento de sites não relacionados. Uma visualização do modelo não pode fechar a ativação ou o alinhamento. Nenhuma conta, DNS , retransmissão ou mensagem foi testada para este exemplo.
Se o teste falhar, separe DNS ausente, errado seletor, configuração de provedor inativa, roteamento inesperado e modificação de mensagens antes de fazer outra alteração. Teste novamente o mesmo fluxo de trabalho após cada correção aprovada. Não enfraqueça a política DMARC de todo o domínio para ocultar o problema de um único remetente. Quando a reversão for necessária, restaure o roteamento anterior aprovado ou a configuração do remetente e retenha os registros-chave enquanto as mensagens assinadas na fila ainda precisarem deles. Mantenha as evidências de teste e as exceções não resolvidas com o inventário do domínio. Nenhum acesso de locatário, alteração DNS ou envio real foi realizado na preparação deste guia.
Mantenha um registro de aceitação responsável
Crie uma linha por conta, domínio e rota materialmente diferente. Registre o proprietário da empresa, o proprietário DNS , a referência de mudança, o De pretendido, o De observado, o domínio do envelope e o resultado SPF , cada DKIM d= e s= com seu resultado, modo de alinhamento aplicável, receptor confiável e carimbo de data/hora, estado de ativação do provedor, observação de posicionamento, pergunta não resolvida e próxima ação. Marque os valores ausentes como desconhecidos, em vez de tratá-los como aprovados ou reprovados. O proprietário aceita apenas o percurso pretendido e a identidade suportada pelas provas registadas; caso contrário, mantenha essa rota e siga o plano de recuperação aprovado.
Separe uma mensagem passageira da prontidão para aplicação
RFC 9989 A seção 7.4 exige DKIM válido para publicação de domínio p=reject e alertas 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.