Escolha o produto antes de editar DNS
A documentação de domínio pessoal do TinkMail descreve domínios personalizados como um recurso Pro. Seu guia de negócios usa valores e espaços reservados fornecidos pela conta. Não aplique o pool de envio pessoal a um espaço de trabalho comercial por suposição. Confirme o produto, o domínio do remetente pretendido, o proprietário DNS e se a movimentação de e-mails recebidos faz parte do projeto autorizado. Este guia não testou uma conta TinkMail.
Procedimento de domínio personalizado pessoal
Adicione o domínio em Configurações > Domínios e use a tabela DNS resultante. O guia pessoal especifica promx1.tinkmail.me e promx2.tinkmail.me com prioridades 10 e 20; SPF inclui prospf.tinkmail.me e requer ~all . Copie o gerado pelo domínio DKIM host e chave pública e execute Check DNS . A ativação depende de MX , SPF , DKIM e DMARC correspondência. O exemplo DMARC publicado usa estrito alinhamento e p=none. Reconcilie esses requisitos com a política existente em vez de adicionar registros duplicados. A fonte exata do domínio pessoal está abaixo.
Procedimento de domínio comercial
O SPF incluído e a chave DKIM da página comercial são espaços reservados, não valores de produção. Obtenha a inclusão real, seletor e a chave pública do gerente da conta e obtenha ajuda para mesclar SPF existente. Trate os dados ausentes da conta como um bloqueador de configuração. Não substitua um nome de host adivinhado, o pool pessoal ou uma chave fabricada.
Projeto original de aceitação de migração
Separe a transferência de entrada da autenticação de saída no ticket de alteração. Uma lista de verificação de ativação de domínio pessoal que inclui MX pode afetar o local onde os novos e-mails são entregues. Antes de alterar MX , faça um inventário das caixas de correio, aliases e acessos de recuperação existentes; preservar os destinos anteriores. Obtenha uma decisão específica de migração de entrada em vez de tratar MX como um registro de autenticação inofensivo.
O projeto de aceitação possui dois ramos de produto e nenhum dado observado. Na ramificação pessoal, colete os valores esperados e ativos do painel e uma mensagem de domínio personalizado recém-enviada. Na filial de negócios, primeiro registre os valores reais e o escopo do produto do gerente de contas e, em seguida, execute as mesmas verificações do receptor. Use um alias de teste com conteúdo inofensivo. Com alinhamento estrito, um domínio pai e seu subdomínio não contam como idênticos. Confirmar o valor d= assinado e o domínio do envelope, em vez de enfraquecer a política apenas para tornar verde um indicador de estado.
Prove a identidade no destinatário
Use uma caixa de correio externa controlada e envie através do fluxo de trabalho de produção, com conteúdo inofensivo e sem dados do cliente. Salve a mensagem bruta, o carimbo de data e hora e o sistema receptor Authentication-Results. Ignore as asserções de autenticação inseridas por um remetente não confiável. Registre o domínio From visível, Return-Path ou identidade de envelope autenticada e cada par DKIM d= e s=. Um nome de exibição ou endereço de resposta não é a identidade DMARC .
A passagem SPF autoriza o servidor de conexão para a identidade do envelope avaliada. O passe DKIM valida uma assinatura para seu domínio de assinatura. DMARC precisa de um método de passagem cujo domínio se alinhe com o De visível: o alinhamento estrito requer o mesmo domínio; o alinhamento relaxado permite o relacionamento de domínio organizacional aplicável. Uma assinatura de propriedade do provedor pode passar sem autenticar seu De visível. Uma passagem alinhada Assinatura DKIM pode satisfazer DMARC mesmo quando outra assinatura falha. Essas regras de protocolo vêm da RFC 7208 , RFC 6376 e RFC 9989, listado abaixo.
Verifique DNS autoritativo antes de diagnosticar caches. Peça a um servidor autorizado o nome e o tipo exatos e compare um resolvedor recursivo após seu tempo de vida em cache. Para DKIM , siga qualquer CNAME à sua resposta TXT de chave pública. Nunca publique uma chave privada. Mantenha uma política SPF para cada nome avaliado e verifique o limite de dez prazos causadores de pesquisa de DNS em inclusões aninhadas. Não substitua uma política SPF compartilhada por um exemplo de provedor.
Recuperação e aceitação
Pause o fluxo de trabalho afetado se os testes mostrarem uma nova regressão. Compare o registro alterado com a versão salva e desfaça apenas essa alteração após verificar outros remetentes. Verifique novamente DNS e reenvie após a recuperação; reverter um valor não libera todos os resolvedores imediatamente. Mantenha registros de verificação DKIM antigos disponíveis enquanto mensagens assinadas anteriormente ainda estiverem em trânsito, a menos que um incidente de segurança exija revogação.
Aceite a alteração somente quando DNS , o estado do aplicativo e uma mensagem real recebida estiverem de acordo. Registre o proprietário do fluxo, o carimbo de data/hora da evidência e o acionador da próxima revisão. A colocação na caixa de entrada por si só não é prova de autenticação, e a autenticação bem-sucedida não garante a colocação na caixa de entrada. Não restrinja a política DMARC de um domínio compartilhado com base no teste de um provedor. Faça um inventário das outras fontes legítimas primeiro.
Interromper uma implementação comercial com valores de conta ausentes
O caso escrito TM-01 pressupõe que um espaço de trabalho comercial se destina support@example.org . A única referência disponível contém os espaços reservados YOUR_PROVIDED_KEY e _spf.example.com ; o provedor de caixa de correio atual ainda recebe mensagens de entrada. Nenhum seletor de negócios real, inclusão ou aprovação de migração foi fornecida. O proprietário do espaço de trabalho deve obter os registros emitidos e o proprietário da caixa de correio deve decidir separadamente qualquer migração de entrada. Não substitua o pool pessoal prospf/promx, publique um espaço reservado ou faça downgrade da política DMARC existente. Todos os resultados DNS e do receptor permanecem desconhecidos. Nenhuma conta, caixa de correio ou operação DNS ocorreu.
Preservar o limite de aplicação
RFC 9989 Seção 7.4 exige DKIM válido, e não apenas SPF , para publicação de domínios p=rejecte alerta sobre a interoperabilidade de correio indireto e listas 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.