Comece com o produto e conta Smaily
A autenticação Smaily requer uma decisão sobre o domínio de envio e a conta autorizada a usá-lo. Comece listando campanhas, automações e mensagens de marketing acionadas por API que usam o domínio. Registre o proprietário da empresa e o administrador DNS . Um domínio usado por várias marcas ou agências precisa de um plano de mudança compartilhado antes das alterações na verificação de propriedade.
Smaily também oferece uma plataforma transacional separada com uma interface diferente e envio de IPs, incluindo opções SMTP e API. Não presuma que uma verificação de conta de marketing autentica faturas transacionais ou alertas de aplicativos. A página do produto revisada estabelece essa separação, mas não uma receita DNS transacional específica da conta. Mantenha essa rota aberta para suas próprias instruções de configuração e evidências de mensagens recebidas. Descrição do produto transacional Smaily, Por que usar e-mails transacionais e Para desenvolvedores.
Este guia desenvolve o fluxo de trabalho documentado do domínio da conta, preservando esse limite. Não afirma que algum inquilino, domínio ou mensagem já tenha passado. Se o requisito original incluir o serviço transacional, a implementação não poderá ser aceita até que esse serviço também seja testado.
Revise a mudança de propriedade antes da autenticação
O guia de propriedade coloca a verificação de domínio em Preferências > Domínios. Ele suporta verificação de link de e-mail e token DNS. Os links de verificação de e-mail duram sete dias. A verificação DNS é preferida e seu token deve permanecer publicado porque Smaily o verifica novamente. A mudança para a verificação DNS revoga as aprovações anteriores de propriedade de links de e-mail em outras contas; cada conta autorizada precisa de seu próprio token. Guia de propriedade de domínio Smaily, verificação DNS.
Antes de aprovar essa alteração, identifique todas as contas que usam legitimamente o domínio, incluindo uma conta de agência que, de outra forma, poderia ser facilmente perdida. Obtenha o token atual da conta pretendida. Registre apenas as informações necessárias para o ticket de implementação, com acesso devidamente restrito. Não copie o token de propriedade de outra conta nem remova um token desconhecido simplesmente porque parece redundante.
Mantenha um proprietário para notificações técnicas e um contato de backup. Uma caixa de correio usada durante a configuração inicial pode ficar desacompanhada após uma mudança de equipe. Revise quem pode solicitar uma nova identidade de remetente, bem como quem pode publicar DNS . A aprovação de propriedade e a autenticação de mensagens são linhas de evidências separadas: passar uma nunca deve fechar silenciosamente a outra.
Publique os registros de autenticação documentados com cuidado
O guia de autenticação do Smaily especifica include:_spf.smaily.com e dois CNAMEs: blue.smly. _domainkey para blue._dkim.smaily.com e green.smly. _domainkey para green._dkim.smaily.com . Estes são registros públicos documentados, não observações do DNS desta conta. Ambos DKIM entradas são obrigatórias. Em seguida, direciona o administrador para a aba Domínios e Autenticar; o status não resolvido pode expor quais registros estão faltando. Obtenha os valores atuais desse guia e conta oficial antes de alterar DNS . Guia de autenticação Smaily, SPF , DKIM e verificações de registros.
Salve a zona existente e prepare uma diferença registro por registro. Confirme se o editor DNS espera um proprietário relativo ou um nome totalmente qualificado. Depois de salvar, inspecione o nome completo do proprietário resultante para que um domínio anexado automaticamente não crie um sufixo duplicado. Um recorde visível em uma tela de gerenciamento é insuficiente se essa tela não estiver atendendo à zona autoritativa.
Para SPF, preserve os outros remetentes autorizados na mesma apólice do proprietário relevante. Não cole uma nova política completa sobre uma política de correio corporativo existente. O limite de avaliação inclui termos de consulta de DNS aninhados, portanto, conte a cadeia de dependência completa em vez de contar apenas as inclusões visíveis. RFC 7208 , seções 4.5 e 4.6.4.
Não copie mecanismos opcionais de um exemplo, a menos que o proprietário do domínio realmente pretenda autorizar os hosts que identifica. Revise o proprietário exato SPF em relação ao domínio do envelope visto posteriormente em uma mensagem real. A verificação de configuração solicitada por um provedor e a identidade SPF do destinatário respondem a diferentes questões operacionais.
Confirme ambos os registros DKIM sem adivinhar a rotação
Resolva ambos os proprietários DKIM emitidos e siga seus CNAMEs até as respostas de chave pública. Salve as respostas e o tempo de observação. Se um falhar, investigue esse registro em vez de presumir que o outro conclui a configuração. Preservar seletores existentes usados por sistemas não relacionados.
O guia público não estabelece quais seletor uma mensagem específica usará ou um cronograma de rotação de chaves prometido. Teste a assinatura realmente presente. UM Assinatura DKIM identifica seu domínio de assinatura por meio de d e seletor por meio de s; juntos eles localizam a chave. RFC 6376 , seções 3.5 e 6.1.
Se a verificação da conta não for bem-sucedida, compare os valores DNS pretendidos com as respostas oficiais antes de editar novamente. Registre o status atual do provedor e qualquer explicação sobre registros ausentes. Evite alterações repetidas enquanto os caches ainda mantêm a versão anterior. Escale uma discrepância reproduzível com os proprietários dos registros e observações cronometradas, sem enviar credenciais de conta.
Teste o fluxo de trabalho que enviará mensagens de produção
Use uma campanha inofensiva e uma automação representativa para controlar caixas de correio externas. Se as mensagens acionadas pela API usarem outra configuração de remetente, teste essa configuração separadamente. Dê a cada teste um assunto identificável e mantenha seu ID de mensagem e horário UTC. Uma visualização ou mensagem direta de uma caixa de correio da equipe não substitui a rota de envio de produção.
Preservar os cabeçalhos originais da caixa de correio receptora. Grave o domínio From exibido, Return-Path, domínio autenticado por SPF, todos os valores DKIM d e s e resultados de receptor confiável. Determine qual identidade de passagem se alinha com o De visível na política do domínio. DMARC precisa de um caminho SPF ou DKIM alinhado; uma assinatura de provedor não relacionada não estabelece esse resultado. RFC 9989 , Alinhamento de Identificador Explicado e Avaliação DMARC.
O suporte ao domínio de envelope personalizado permanece não confirmado pelas páginas de configuração revisadas do Smaily. Não invente um salto CNAME ou SPF alinhado com promessa. Se DKIM alinhado fornecer o passe, identifique-o explicitamente. Se a organização exigir separadamente um domínio de envelope específico, obtenha uma configuração Smaily compatível e teste-a antes de fechar esse requisito.
Diagnosticar propriedade e entrega separadamente
Uma falha de propriedade aponta primeiro para a conta aprovada, o método de verificação e o token retido. Uma falha na autenticação do DNS exige uma comparação dos registros emitidos com as respostas públicas. Uma mensagem recebida com a identidade De errada chama uma revisão da configuração do fluxo de trabalho. Esses são problemas diferentes e nem todos devem ser tratados adicionando outro SPF .
Se DKIM for aprovado, mas o e-mail for considerado spam, examine a reputação, as expectativas do destinatário e o conteúdo separadamente. A autenticação não garante o posicionamento na caixa de entrada. Se DMARC falhar, compare os domínios reais e alinhamento modos antes de considerar uma mudança de política. Enfraquecer a política existente da organização para fazer com que um teste seja entregue não é uma implementação completa.
Registre a transferência e o plano de recuperação
Use a planilha de propriedade e rota do Smaily (crie um registro de revisão separado com os campos descritos aqui). Mantenha linhas distintas para propriedade da conta, os dois registros DKIM , a política SPF , evidências de campanha, evidências de automação e qualquer rota transacional. Nomeie a pessoa que aprovará cada requisito não resolvido.
Se um teste falhar, pause o fluxo de trabalho afetado usando um plano operacional aprovado. Restaure uma configuração de remetente previamente testada somente após verificar se sua propriedade e seus registros ainda funcionam. Não remova tokens de propriedade ou registros de autenticação enquanto outras contas autorizadas ou mensagens na fila dependerem deles. Teste novamente após uma migração DNS , transferência de conta ou alteração no produto remetente.
Caso de diagnóstico fictício envolvendo uma conta de agência
Apenas caso escrito fictício: SM-02 pressupõe que uma conta de marca muda books.example de email-link para propriedade DNS , enquanto uma agência autorizada ainda precisa enviar offers@books.example . O token DNS da própria agência ainda não foi publicado; seus resultados de autenticação de mensagens são desconhecidos. O proprietário da marca deve confirmar a autorização contínua da agência, obter o token separado dessa conta e verificar a propriedade antes de um teste de campanha controlado. Uma aprovação no teste de conta de marca, se obtida posteriormente, não estabeleceria a permissão da agência. Nenhum token, conta, DNS ou campanha foi acessado.
A aceitação permanece pendente
Aceite a rota documentada somente após a propriedade, as verificações de autenticação e as evidências do receptor concordarem. A aceitação do escopo original permanece pendente para qualquer requisito transacional ou de envelope personalizado não verificado. O acesso ao inquilino em tempo real, os testes DNS e de mensagens, a revisão técnica independente, a revisão visual e a aprovação humana das PME permanecem pendentes para este rascunho não publicado.
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.