Confirme o contexto do produto e da conta
O guia de configurações de e-mail do SolarWinds Service Desk cobre a configuração de e-mail de entrada e saída para o produto Service Desk em nuvem. Não é um guia para o produto Web Help Desk separado ou para um servidor SMTP SolarWinds genérico. Confirme a conta, o datacenter e se a organização usa o contexto de navegação ITSM ou ESM antes de planejar alterações.
A documentação fornece configurações de Configuração > Conta > Email para ITSM e um contexto de organização ou provedor de serviços para ESM. Registre qual escopo administrativo possui o domínio do remetente pretendido. Um nome de empresa compartilhado não estabelece que um domínio pertença a todos os provedores de serviços ou organizações configuradas na plataforma.
Este manuscrito descreve o fluxo de trabalho documentado e a verificação proposta. Ele não reivindica acesso a uma conta real, um direito de inquilino atual, uma alteração real DNS ou uma notificação bem-sucedida. Os requisitos originais de implementação e liberação de produção permanecem abertos. Configurações de e-mail da central de serviços
Gere e publique os registros de domínio personalizado
Em Autenticação de e-mail, o guia orienta o administrador a adicionar um domínio personalizado. A nova entrada aparece inicialmente como Não verificada. Expandir suas configurações DNS revela três CNAME registros. Publique esses registros gerados pela conta, retorne às Configurações de e-mail e selecione Verificar para o domínio. O estado de sucesso documentado é Verificado.
Mantenha os nomes e alvos exatos da conta selecionada. Não substitua registros de outro ambiente ou um anúncio de migração mais antigo. Revise a zona autoritativa e os dados existentes em cada nome de proprietário antes de aprovar a alteração. O editor DNS pode anexar a zona automaticamente, portanto compare os nomes finais pretendidos com as convenções da interface em vez de colar cegamente um sufixo.
O provedor discute um possível atraso na publicação e verificação. Trate isso como uma orientação de tempo, não como uma evidência de que um recorde incorreto acabará sendo aprovado. Registre o horário e o resultado real da verificação e, em seguida, investigue o nome ou alvo específico sem correspondência, se ele permanecer sem solução. Configuração de e-mail Etapa 1
Mantenha os controles do datacenter separados da autenticação do domínio
O guia inclui permissões de domínio e IP específicas do datacenter como uma etapa de configuração separada. Ele lista valores diferentes para contas dos EUA, UE e UA. Não aplique uma lista de datacenters antigos ou não relacionados como recomendação universal e não trate a lista de permissões como um substituto para a autenticação da identidade do remetente.
Qualquer exceção de filtragem proposta precisa de uma revisão de segurança do seu escopo e do tráfego pretendido. Este manuscrito não altera uma política de firewall, gateway de correio ou caixa de correio e não recomenda desabilitar verificações de autenticação para forçar a entrega. A evidência útil é a localização real da conta e o propósito aprovado de qualquer exceção, e não uma afirmação de que todo destinatário deve confiar incondicionalmente no tráfego de um fornecedor.
Da mesma forma, os controles sobre quem pode criar incidentes ou comentários por e-mail dizem respeito ao acesso ao fluxo de trabalho recebido. Eles não estabelecem o SPF ou DKIM resultado de notificações de saída. Mantenha as decisões de acesso de entrada e a autenticação de saída em linhas de aceitação separadas. Configuração de e-mail Etapa 2; Endereços bloqueados e permitidos
Revise a política SPF documentada no contexto
Para enviar do domínio da organização, o guia instrui os administradores a adicionar o Registro TXT mostrado em Configurações DNS e ilustrado include:_spf.samanage.com. Use as instruções reais da conta e revise toda a política afetada, em vez de substituir a autorização existente por um exemplo isolado.
SPF avalia suas identidades SMTP especificadas, não o nome de exibição amigável de um agente. Vários selecionados Registros SPF causar um erro, portanto, um domínio compartilhado precisa de uma política coerente que preserve fontes legítimas. Revise o limite de avaliação em termos dependentes de DNS e quaisquer dependências aninhadas antes de aprovar uma alteração.
O guia também discute DMARC, mas uma política publicada não é prova de que todas as mensagens do Service Desk estão alinhadas. Uma amostra de mensagem recebida autorizada é necessária para comparar o domínio do autor visível com uma identidade de autenticação de passagem. Não enfraqueça uma política existente em toda a organização apenas para simplificar a implementação do service desk. Aborde outros padrões de e-mail; RFC 7208 , seção 2.4; RFC 7208 , seção 3.2; RFC 7208 , seção 4.6.4; RFC 9989 , seção 4.4
Distinguir nomes, endereços e respostas personalizados
O provedor documenta diversas configurações separadas. Os nomes de e-mail personalizados afetam o nome usado para ações originadas pelo usuário, enquanto os endereços de e-mail personalizados afetam o endereço De para tais ações após a autenticação. O guia diz que notificações automáticas não originadas de ações do usuário não são afetadas por essas configurações. Também diz que essas configurações não alteram o Responder para.
Esta distinção deve moldar o plano de aceitação. Uma amostra produzida por um comentário de agente não prova automaticamente a identidade do remetente de uma notificação programada ou automática. Um nome familiar não é uma identidade de domínio e um destino de resposta funcional não estabelece DKIM alinhamento. Registre cada campo e categoria de mensagem separadamente.
O recurso Endereço de email de resposta tem sua própria finalidade, incluindo consistência quando regras de encaminhamento são usadas. Revise o caminho de resposta pretendido do cliente ou funcionário sem confundir a verificação do fluxo de trabalho com a validação criptográfica. Se o remetente ou o caminho de resposta for diferente das expectativas, inspecione a configuração e a categoria selecionadas antes de alterar DNS correto. Nomes de e-mail personalizados; Endereços de e-mail personalizados; Endereço de e-mail de resposta
Planilha de aceitação para operações de gerenciamento de serviços
Use esta planilha proposta original para tornar explícitos os limites de conta, notificação e segurança.
- Escopo do produto: conta do Service Desk, datacenter, contexto ITSM ou ESM e administrador autorizado.
- Solicitação de domínio: domínio do remetente pretendido, nomes/destinos CNAME gerados exatos e proprietário DNS atual.
- Revisão da política: completar a política SPF afetada e as expectativas de alinhamento DMARC da organização.
- Exceções de segurança: permissões específicas do datacenter aprovadas separadamente, se necessário, com sua finalidade e proprietário.
- Classes de mensagens: pelo menos os caminhos materialmente diferentes de ação do usuário e notificação automática identificados para aceitação posterior.
- Identidade visível: endereço remetente, nome amigável e resposta para registrados como campos diferentes.
- Verificação: status e carimbo de data/hora do provedor, além de evidências minimizadas de mensagens autorizadas com resultados de receptor confiável.
- Liberação: questões não resolvidas de aplicabilidade atual, proprietário de reversão e aprovação de produção.
A planilha é uma orientação de planejamento em branco. Nenhuma conta, lista de entrada, zona DNS ou configuração de segurança foi alterada e nenhum incidente ou notificação foi criado para testá-la.
Diagnóstico fictício: uma notificação automática não personalizou
Uma equipe de TI fictícia verifica seu domínio e habilita endereços personalizados. O comentário de um agente usa a identidade De esperada, mas uma notificação automática não tem a mesma aparência. A equipe inicialmente assume que a configuração DKIM falhou porque o remetente visual é diferente.
A investigação proposta identifica primeiro se a mensagem originou-se de uma ação do usuário ou de um processo automático. O revisor então compara os campos de endereço reais e os resultados de autenticação confiável em vez de tratar a aparência como prova. Reply-To é revisado de forma independente porque seu comportamento é controlado separadamente.
A transferência resultante distingue o escopo de personalização documentado da aceitação de autenticação e identifica quaisquer rotas não verificadas. Ele não exclui os registros CNAME funcionais nem amplia as listas de permissões recebidas para reparar um mal-entendido cosmético. Este cenário é fictício e não contém nenhum teste executado ou alegação sobre uma implantação real do Service Desk.