Estabeleça se o Openprovider atende a zona ativa
Este guia trata da publicação de registros de autenticação no Openprovider DNS . Não é um guia de configuração para caixas de correio separadas ou produtos de encaminhamento do Openprovider. Seu domínio pode ser registrado no Openprovider enquanto Microsoft 365 , um serviço de campanha ou outro provedor envia seu email. O remetente fornece suas instruções de autenticação; o operador DNS autorizado publica os registros aprovados. Mantenha essas funções separadas ao atribuir o trabalho.
Openprovider suporta seu próprio servidores de nomes e servidores de nomes externos. Seu guia de servidor de nomes explica que as zonas hospedadas externamente devem ser configuradas no provedor DNS externo, enquanto as zonas hospedadas pelo Openprovider são gerenciadas por meio do gerenciamento DNS e da visão geral das zonas DNS . Comece com a delegação pública real e a zona exata em alteração. Um domínio registado e uma zona visível na conta não são suficientes para estabelecer autoridade. Orientação sobre servidor de nomes Openprovider
Não altere os servidores de nomes apenas para fazer uma SPF editor disponível. Essa é uma migração separada que pode afetar o site, o correio recebido, os tokens de validação e DNSSEC. Se um provedor externo tiver autoridade, entregue as alterações de registro aprovadas ao administrador desse provedor. Se o Openprovider for autoritativo, confirme que você está editando a zona ativa em vez de um modelo destinado para uso futuro.
Monte as alterações de registro do serviço de envio
Solicite a autorização SPF atual emitida pelo remetente, DKIM proprietários e valores, quaisquer instruções de envelope personalizado e o domínio preciso ao qual cada uma se aplica. Evite um registro universal chamado configuração SPF do Openprovider: um host DNS não se torna um remetente de e-mail autorizado simplesmente hospedando a zona. A mesma distinção se aplica ao DKIM . O artigo DKIM do Openprovider diz que o servidor de envio de e-mail determina o conteúdo do registro e o provedor ou engenheiro de sistema o fornece. Publicação Openprovider DKIM
Exporte ou preserve de outra forma todos os conjuntos de registros afetados, incluindo nomes de proprietários, tipos, TTLs e valores. Mantenha intactos os tokens TXT não relacionados. Registre cada ação proposta como adicionar, substituir ou retirar, com seu proprietário de serviço e motivo. UM seletor que parece antigo ainda pode validar mensagens em fila ou oferecer suporte a outro aplicativo. A instrução de um novo serviço não autoriza a exclusão da chave do serviço antigo.
Separe o proprietário pretendido totalmente qualificado da entrada do editor. Para DKIM , os rótulos seletor e _domainkey são essenciais; eles não são intercambiáveis com o ápice do domínio. Para DMARC, identifique o proprietário _dmarc aplicável. Para SPF , identifique o domínio real do envelope SMTP . O guia de registros DNS recuperado não estabelece uma convenção universal atual de entrada no ápice. Confirme o tratamento atual da interface do proprietário raiz e dos sufixos anexados antes de salvar; não presuma que um campo em branco ou @ seja aceito em todos os modos de entrada. Convenções de registro DNS do Openprovider
Publique SPF como uma política com formatação TXT verificada
O guia SPF do Openprovider usa Registros TXT e instrui especificamente seus usuários a colocar o conteúdo entre aspas retas. Siga a convenção de entrada documentada do editor atual e inspecione a resposta TXT publicada para verificar se a formatação foi interpretada corretamente. As aspas curvas copiadas de um processador de texto não são equivalentes. Não adicione repetidamente camadas de cotação quando um resolvedor já exibir strings entre aspas. Publicação Openprovider SPF
A semântica do protocolo é o critério de aceitação. Deve haver uma política SPF candidata no proprietário avaliado. Um registro TXT pode conter diversas cadeias de caracteres unidas para processamento SPF , portanto, uma divisão de exibição não significa necessariamente diversas políticas. Por outro lado, dois registros separados começando com o marcador de versão SPF não são uma forma válida de acomodar dois remetentes. Preserve os espaços necessários e a sequência completa do mecanismo no valor reconstruído. SPF RFC 7208
O artigo SPF geral do provedor contém linguagem simplificada sobre o comprimento TXT , enquanto seu guia de registros DNS descreve explicitamente a divisão de um valor TXT grande em strings menores dentro de um registro. O limite de cadeia de caracteres não deve ser tratado como um limite total de registros. Confirme o tratamento do editor atual e verifique a resposta reconstruída. Orientação de registro TXT do Openprovider Se um valor longo for rejeitado, obtenha orientação do fornecedor; não encurte uma chave pública nem divida uma política SPF em registros independentes.
Avalie os limites de pesquisa recursiva do SPF antes de salvar uma política mesclada. Uma apólice visualmente curta ainda pode exceder o limite por meio de apólices incluídas. Não substitua mecanismos mantidos pelo provedor por um instantâneo dos endereços IP atuais, a menos que esse modelo de manutenção seja deliberadamente aprovado e apoiado. Mudanças estáticas de nivelamento que devem acompanhar mudanças futuras na infraestrutura.
Mantenha intactos os tipos de registro DKIM e a propriedade do seletor
Alguns serviços de envio fornecem uma chave pública TXT ; outros fornecem um CNAME apelido. Publique o tipo fornecido no proprietário do seletor fornecido. Não coloque um alvo CNAME em um campo TXT nem publique a chave no ápice. O receptor deriva a pesquisa do domínio e seletor de assinatura da mensagem, e é por isso que um registro de aparência plausível para um proprietário diferente não ajuda. DKIM RFC 6376
O Openprovider documenta erros quando um CNAME compartilha seu proprietário com outros dados de registro comuns. Se o editor relatar uma duplicata ou conflito CNAME , inspecione o conjunto completo de registros do proprietário exato. Não exclua o registro TXT conflitante antes de identificar o remetente que o possui. Peça ao novo remetente um seletor não conflitante compatível ou planeje uma rotação controlada. O conflito é uma questão de propriedade de confiança, não apenas um problema de validação de entrada. Orientação sobre conflitos CNAME do Openprovider
Uma chave pública ou registro de delegação não faz com que o serviço de envio comece a assinar. Conclua qualquer ativação do remetente separadamente e verifique a assinatura em uma mensagem real. Nunca publique chaves privadas, credenciais de API ou senhas SMTP na zona ou planilha.
Distinguir DMARC manual de delegação hospedada
A integração EasyDMARC do Openprovider descreve dois caminhos de gerenciamento: uma política hospedada alcançada por meio de um alias CNAME e uma política TXT mantida manualmente. Avisa que o alvo de delegação mostrado em um exemplo não é o valor a ser usado; o painel de controle fornece o alvo real. Ele também descreve a criação automática CNAME em uma compra qualificada ou fluxo de ativação usando servidores de nomes Openprovider. Portanto, inspecione o proprietário _dmarc existente antes de adicionar qualquer coisa manualmente. Gerenciamento Openprovider EasyDMARC
Escolha um modelo de gestão aprovado. Com uma delegação hospedada, a política operacional pode mudar no serviço hospedado sem uma edição correspondente na zona Openprovider. Atribua um proprietário para esse serviço e mantenha as configurações de política aprovadas. Com o TXT manual, as alterações devem ser refletidas no valor publicado. Evite deixar uma política TXT e um CNAME no mesmo proprietário e não substitua os destinos de relatórios existentes apenas para seguir um assistente de integração.
DMARC avalia o domínio From visível em relação à passagem de identidades SPF ou DKIM alinhadas. A publicação é uma parte desse processo; isso não prova que os remetentes do domínio estejam alinhados. Mantenha o comportamento do destinatário distinto da política solicitada e mantenha um inventário de remetentes em todo o domínio antes de reforçar a aplicação. DMARC RFC 9989
Planilha de publicação reutilizável do Openprovider
Crie uma linha para cada proprietário alterado e mantenha um registro de alteração compartilhado para o domínio.
- Domínio, servidores de nomes autorizados e identificador de zona ativa: ______.
- Administrador DNS , administrador remetente e aprovador de alterações: ______.
- Serviço de envio e sua evidência de configuração atual: ______.
- Proprietário totalmente qualificado pretendido e entrada separada do host do editor: ______.
- Tipo de registro, valor aprovado completo e TTL: ______.
- Conjunto de registros anteriores e dependências que devem sobreviver: ______.
- Proprietário do envelope avaliado SPF e verificação de política recursiva: ______.
- Propriedade do seletor DKIM , revisão de conflitos e ativação do remetente: ______.
- Manual DMARC TXT ou CNAME hospedado escolha e proprietário da política: ______.
- Resposta oficial após mudança e comparação recursiva: ______.
- Referência da mensagem recebida, De, envelope, assinaturas e resultados confiáveis: ______.
- Etapas de reversão, reteste do proprietário, verificação visual e aceitação humana: pendente.
Diagnóstico fictício de uma colisão de seletores
Este exemplo é fictício. Um revendedor adiciona um novo serviço de marketing a um domínio cujo DNS é hospedado pelo Openprovider. O novo serviço solicita um CNAME em um seletor que já possui uma chave TXT para um remetente de fatura. Openprovider rejeita a mudança como um conflito. O revendedor propõe a remoção do TXT porque o novo guia de configuração diz que o seletor é necessário.
A investigação segura identifica o remetente da fatura e confirma que ele ainda assina mensagens de saída com esse seletor. A recuperação proposta é solicitar um seletor compatível diferente do serviço de marketing ou coordenar uma transição de chave verificada com ambos os proprietários. Não é para excluir cegamente a chave da fatura. Após uma alteração aprovada, faturas e mensagens de marketing separadas seriam testadas. Nenhuma zona real, remetente ou teste bem-sucedido é representado por este cenário.
Fechar com DNS e evidência de mensagem
Consulte os proprietários exatos nos servidores de nomes autorizados após salvar e preservar as respostas. Compare uma resposta recursiva separadamente, reconhecendo o cache. Em seguida, faça com que cada remetente afetado produza uma mensagem controlada para uma caixa de correio independente e registre os resultados do receptor confiável. Um validador somente DNS não pode confirmar qual seletor o remetente realmente usa ou se sua identidade de passagem está alinhada.
Se a recuperação for necessária, restaure apenas o conjunto de registros anterior afetado e repita os testes de fluxo de trabalho relevantes. Preserve evidências de configurações de política hospedada, bem como de valores DNS , porque os primeiros podem mudar de forma independente. O acesso à conta corrente, capturas de tela da interface, capturas oficiais de antes e depois, evidências de mensagens recebidas e aprovação humana de PME permanecem pendentes para este guia. Nenhuma edição DNS ou testes ao vivo foram realizados.
Mantenha os registros públicos separados das operações criptográficas
A publicação de uma chave pública não criptografa o corpo do e-mail, não cria uma assinatura nem estabelece que toda a mensagem é segura. Use o padrão DKIM para semântica de assinatura em vez da explicação simplificada de criptografia do artigo do provedor. Verifique o conteúdo assinado real e o resultado do receptor depois que o operador remetente concluir a ativaçã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.