Identificare la distribuzione e il mittente in uscita finale
ManageEngine ServiceDesk Plus non è un unico servizio di invio universale con uno solo SPF includere. Inizia identificando ServiceDesk Plus Cloud o il prodotto locale, l'istanza, la build distribuita ove applicabile, il servizio in uscita configurato e il flusso di lavoro aziendale. Mantenere ServiceDesk Plus MSP, MSP Cloud e SupportCenter Plus fuori dall'ambito di configurazione dichiarato di questa guida. Menu simili in questi prodotti non stabiliscono impostazioni di autenticazione intercambiabili.
Per la posta nativa nel cloud, Acronis fornisce una casella di posta dell'istanza e supporta un indirizzo e-mail personalizzato verificato. Per un percorso di posta esterno, il servizio di posta configurato trasporta il messaggio. La guida locale documenta i percorsi di connessione SMTP /SMTPS, Servizi Web Exchange e Microsoft Graph, i cui controlli variano. Guida alla posta nativa nel cloud E Guida al server in uscita ServiceDesk Plus.
Disegna il percorso in un linguaggio semplice: indirizzo rivolto al richiedente, istanza dell'applicazione, server in uscita o servizio API, qualsiasi gateway downstream e casella di posta di ricezione controllata. Registra chi amministra ciascun componente. Una regola di inoltro in entrata indica dove arrivano i biglietti; non dimostra quale servizio invia notifiche. Allo stesso modo, un URL personalizzato del portale non stabilisce il dominio di firma dell'e-mail. Conserva le impostazioni correnti prima di modificare uno dei percorsi e identifica quali regole di notifica o indirizzi di gruppo dipendono da esse.
Configura la posta nativa del cloud solo quando questo è il percorso scelto
Nel Cloud, il servizio nativo è configurato in Configurazione > Impostazioni di posta > Impostazioni del server di posta. Il fornitore documenta una fase di attivazione e un indirizzo di supporto specifico dell'istanza. Se la posta nativa è già operativa, una riparazione dell'autenticazione non dovrebbe disattivare o ricreare casualmente la casella di posta. Se è prevista una migrazione, trattare l'inoltro in entrata, la creazione di ticket e le risposte in uscita come una modifica coordinata con un proprietario del rollback. Configurazione del servizio nativo.
Per un indirizzo personalizzato, utilizzare Configurazione > Impostazioni posta > Indirizzi posta e Nuova email. La sequenza del provider è la verifica del dominio utilizzando l' SPF visualizzato e DKIM valori, seguito dal collegamento di verifica dell'indirizzo. Il materiale DKIM è specifico del dominio. Dopo la verifica, la configurazione in uscita seleziona l'indirizzo verificato nel controllo Indirizzo di risposta. Copiare i valori effettivi del conto e completare il relativo stato di verifica; non importare a selettore o chiave da un'altra organizzazione. Verifica dell'indirizzo personalizzato e configurazione in uscita.
Sebbene l'interfaccia utilizzi l'etichetta Indirizzo di risposta, controlla entrambe le intestazioni Da e Rispondi. Le etichette dei prodotti non sostituiscono le prove del protocollo. La guida Cloud descrive questo controllo nella configurazione dell'indirizzo del mittente, mentre la guida locale descrive il comportamento del campo in modo diverso tra i protocolli di connessione. Registra il risultato osservato per la distribuzione selezionata anziché dare per scontato che una mappatura si applichi a tutte le edizioni.
Utilizza etichette cloud documentate e DNS generati dall'account
Le note sulla versione Cloud dell'8 aprile 2026 rinominano i campi di configurazione DKIM in Host/Nome e Valore TXT . Host/Nome include il selettore in <selettore>. _domainkey modulo. Copia i valori visualizzati correnti, quindi verifica se la console DNS aggiunge automaticamente il dominio. Non aggiungere _domainkey due volte perché uno screenshot più vecchio mostrava solo un semplice selettore. Note sulla versione di ServiceDesk Plus Cloud, configurazione DKIM.
Per ogni modifica proposta, acquisisci il proprietario DNS completo, il tipo, il valore pubblico, il dominio interessato e il record precedente. Se l'istruzione SPF visualizzata assomiglia a una policy completa, unisci l'autorizzazione richiesta con i mittenti legittimi esistenti invece di creare una policy duplicata o sostituire l'autorizzazione e-mail aziendale. Valutare il costo effettivo della ricerca DNS. Conferma che la risposta DNS pubblicata appartiene alla zona prevista e alla configurazione del data center/account prima di utilizzare l'azione di verifica del provider. Specifica SPF.
Le fonti esaminate non stabiliscono un controllo universale del cliente Return-Path opzione per la posta nativa nel cloud. Lasciare tale capacità non confermata a meno che l'attuale inquilino o le prove di supporto non lo dimostrino. Non creare un dominio di rimbalzo Record MX oppure prendere in prestito il valore SPF di un prodotto Zoho semplicemente perché le organizzazioni sono correlate. Utilizza i record mostrati per questa distribuzione di ServiceDesk Plus e controlla la busta effettivamente ricevuta.
Tratta la consegna esterna e quella locale come un lavoro di autenticazione separato
Per la posta esterna cloud, identificare il servizio di cassetta postale in uscita effettivo e il metodo di connessione supportato nel tenant corrente. La vecchia guida alla configurazione del cloud descrive le impostazioni SMTP esterne, ma non dimostra che tutti i metodi di autenticazione storici rimangano supportati. Convalida il metodo attuale dell'account anziché abilitare l'autenticazione di base obsoleta per riprodurre uno screenshot. Impostazioni di posta esterna cloud.
Per ServiceDesk Plus locale, un SDAdmin configura il protocollo in uscita selezionato e la connessione server o API. La guida conservata include un controllo di connettività di posta di esempio e avvisa che un server di posta secondario può rimanere in uso dopo il failover. Se è configurato un server secondario, includere le relative identità di invio nel piano di accettazione anziché dare per scontato che il percorso primario gestisca sempre i messaggi. Coordinare qualsiasi ritorno al server primario come modifica operativa. Configurazione in uscita e comportamento del server secondario.
L'autenticazione della connessione, come OAuth, autorizza l'accesso dell'applicazione a un servizio di cassetta postale. Non pubblica SPF , non abilita la firma DKIM né dimostra DMARC allineamento. L'amministratore del servizio di invio finale deve verificare tali controlli per il mittente effettivo e le identità della busta. Richiedi solo le autorizzazioni necessarie per l'integrazione approvata. Mantieni password, token e segreti client lontani da ticket di modifica DNS , screenshot e prove di articoli.
Un'e-mail di esempio riuscita stabilisce un'utile prova di connettività, ma una risposta al ticket, una notifica automatizzata e un messaggio con funzione personalizzata possono avere impostazioni predefinite o routing diversi. Testare i percorsi aziendali effettivamente utilizzati. Per le modifiche locali, controlla se il recupero della posta è stato temporaneamente interrotto e ripristinalo dopo la modifica approvata in modo che il lavoro di autenticazione non impedisca silenziosamente nuovi ticket.
Controlla le regole del flusso di lavoro cloud prima di incolpare DNS
Le note sulla versione Cloud del 20 maggio 2026 descrivono le restrizioni sui destinatari quando l'indirizzo nativo predefinito è il mittente per le licenze di prova e Standard appena configurate. I destinatari che non hanno effettuato l'accesso possono essere ignorati oppure un messaggio potrebbe non essere inviato quando tutti i destinatari non hanno effettuato l'accesso. Esaminare i registri di sistema e l'effettiva combinazione licenza/mittente prima di diagnosticare il sintomo come un problema SPF . Misure di salvaguardia per l'invio di posta cloud.
La stessa cronologia di rilascio documenta l'offload di sendmail DRE: l'e-mail con funzione personalizzata viene trattata come una notifica di sistema e utilizza il mittente del sistema anziché il valore Da fornito dalla funzione. Includi funzioni personalizzate nell'inventario del flusso di lavoro e controlla il comportamento attualmente distribuito se un test mostra un mittente imprevisto. Non riparare una mancata corrispondenza del mittente del sistema modificando DNS per un indirizzo che l'applicazione non emette più. Comportamento di invio posta Cloud DRE.
Questi controlli delle applicazioni sono separati dal filtro in entrata. Un messaggio in entrata rifiutato prima della creazione del ticket non dimostra un difetto di autenticazione in uscita. Conserva la direzione, la data e l'ora e l'evento di registro pertinente nel record dell'incidente. Evita di disabilitare i controlli DMARC , inserire liste consentite estese o allentare la politica dell'intero dominio come scorciatoia diagnostica.
Completa la tabella delle identità dei messaggi ricevuti originali
La tabella identità originale richiesta non è stata eseguita qui. Crea una riga per ogni distribuzione, istanza, percorso in uscita, Dal dominio e flusso di lavoro testati. Includere contesto di build o cloud, licenza se pertinente, timestamp, identificatore ticket o test, servizio in uscita, Da, Rispondi a, Return-Path , dominio/risultato SPF del destinatario attendibile, ogni DKIM d=/s= e risultato, risultato DMARC , determinazione dell'allineamento, risultato del destinatario e posizione delle prove limitate. Distinguere il rifiuto dell'applicazione di inviare dal rifiuto di autenticazione del server ricevente.
Utilizza ticket sintetici e destinatari controllati. Controlla la risposta del richiedente, una notifica automatica, qualsiasi indirizzo di gruppo attivo e qualsiasi percorso di funzioni personalizzate del materiale. Laddove esiste un percorso di failover documentato, testarlo solo attraverso un esercizio operativo approvato. Verificare che una risposta ritorni al ticket previsto e che l'inoltro in entrata non crei un loop o richieste duplicate. Conserva le origini dei messaggi originali riducendo al minimo i dettagli personali nella copia di revisione.
DMARC confronta il dominio Da visibile con un'identità SPF o DKIM di passaggio nella modalità di allineamento applicabile. Un pass DKIM del dominio del provider o un URL dell'help desk con marchio da soli non dimostrano l'allineamento. Ispeziona tutte le firme e utilizza i risultati attendibili del destinatario. Specifica DKIM E Specifica DMARC.
Ripristina il servizio preservando la protezione del dominio
Quando non viene emesso alcun messaggio, esaminare prima le regole di notifica, le restrizioni sui destinatari, la verifica del mittente e gli errori di connessione. Quando la consegna raggiunge il destinatario ma l'autenticazione fallisce, indaga sulla busta o sul selezionatore osservato presso l'effettivo servizio di uscita. Se un gateway altera il contenuto firmato, confronta un percorso diretto controllato con il percorso interessato. Se DNS viene superato ma le risposte scompaiono, ispezionare separatamente il comportamento di inoltro e di elaborazione dei ticket.
Metti in pausa solo il flusso di lavoro interessato, ove possibile. Ripristina il routing precedente approvato o i valori DNS quando necessario, quindi verifica nuovamente sia l'identità in uscita che la gestione dei ticket in entrata. Non sostituire la policy DMARC applicata dall'organizzazione con un esempio di monitoraggio come fase di ripristino universale. Nessun tenant, configurazione del server, DNS attivo o messaggio ricevuto è stato controllato qui. Restano aperte la conferma esatta del prodotto/build, la tabella di identità specifica del percorso originale, l'applicabilità delle FAQ specifiche del tenant e l'approvazione da parte delle PMI per la sicurezza della posta umana; questo manoscritto è un candidato inedito.
Separare l'errore di emissione dall'errore di autenticazione
Per una riga di incidente proposta, conservare il flusso di lavoro, la selezione del mittente, il contesto di licenza/build, lo stato di emissione dell'applicazione, il percorso in uscita effettivo e le prove del destinatario. Se l'applicazione ignora un destinatario, le modifiche DNS non possono dimostrare che sia stato emesso un messaggio. Se il ricevitore ha rifiutato un messaggio trasmesso, conservare l'esatta diagnostica remota. Se l'autenticazione viene superata ma la risposta non riceve il ticket, esaminare separatamente il routing e il threading. Lasciare sconosciute le prove non disponibili anziché assegnare l'incidente SPF per impostazione predefinita.