Identifizieren Sie die Bereitstellung und den endgültigen ausgehenden Absender
ManageEngine ServiceDesk Plus ist kein einziger universeller Sendedienst mit einem einzigen SPF enthalten. Identifizieren Sie zunächst ServiceDesk Plus Cloud oder das lokale Produkt, die Instanz, gegebenenfalls den bereitgestellten Build, den konfigurierten ausgehenden Dienst und den Geschäftsworkflow. Halten Sie ServiceDesk Plus MSP, MSP Cloud und SupportCenter Plus außerhalb des in diesem Handbuch festgelegten Einrichtungsbereichs. Ähnliche Menüs in diesen Produkten legen keine austauschbaren Authentifizierungseinstellungen fest.
Für Cloud-native E-Mails stellt ManageEngine ein Instanzpostfach bereit und unterstützt eine verifizierte benutzerdefinierte E-Mail-Adresse. Bei einer externen E-Mail-Route leitet der konfigurierte E-Mail-Dienst die Nachricht weiter. Das lokale Handbuch dokumentiert SMTP /SMTPS, Exchange Web Services und Microsoft Graph-Verbindungspfade, deren Steuerungen variieren. Anleitung für cloudnative E-Mails Und ServiceDesk Plus-Handbuch für ausgehende Server.
Zeichnen Sie die Route im Klartext: Adresse für den Anforderer, Anwendungsinstanz, ausgehender Server oder API-Dienst, etwaiges Downstream-Gateway und kontrolliertes Empfangspostfach. Notieren Sie, wer jede Komponente verwaltet. Eine eingehende Weiterleitungsregel gibt an, wo Tickets ankommen. Es wird nicht nachgewiesen, welcher Dienst Benachrichtigungen sendet. Eine benutzerdefinierte Portal-URL stellt ebenfalls nicht die E-Mail-Signaturdomäne her. Behalten Sie die aktuellen Einstellungen bei, bevor Sie eine Route ändern, und ermitteln Sie, welche Benachrichtigungsregeln oder Gruppenadressen davon abhängen.
Konfigurieren Sie Cloud-native-Mail nur, wenn dies die gewählte Route ist
In der Cloud wird der native Dienst unter Setup > Mail-Einstellungen > Mailserver-Einstellungen konfiguriert. Der Anbieter dokumentiert einen Aktivierungsschritt und eine instanzspezifische Supportadresse. Wenn native Mail bereits in Betrieb ist, sollte eine Authentifizierungsreparatur das Postfach nicht einfach so deaktivieren oder neu erstellen. Wenn eine Migration beabsichtigt ist, behandeln Sie eingehende Weiterleitungen, Ticketerstellung und ausgehende Antworten als eine koordinierte Änderung mit einem Rollback-Eigentümer. Native Dienstkonfiguration.
Für eine benutzerdefinierte Adresse verwenden Sie Setup > E-Mail-Einstellungen > E-Mail-Adressen und neue E-Mail. Die Reihenfolge des Anbieters ist die Domain-Verifizierung anhand des angezeigten SPF und DKIM Werte, gefolgt vom Link zur Adressverifizierung. Das DKIM Material ist domänenspezifisch. Nach der Überprüfung wählt die ausgehende Konfiguration die überprüfte Adresse im Steuerelement „Antwortadresse“ aus. Kopieren Sie die tatsächlichen Kontowerte und vervollständigen Sie den entsprechenden Verifizierungsstatus. nicht importieren Wähler oder Schlüssel von einer anderen Organisation. Überprüfung der benutzerdefinierten Adresse und ausgehende Konfiguration.
Obwohl die Schnittstelle die Bezeichnung Reply-To-Adresse verwendet, überprüfen Sie sowohl die tatsächlichen From- als auch Reply-To-Header. Produktetiketten sind kein Ersatz für Protokollnachweise. Der Cloud-Leitfaden beschreibt diese Steuerung in der Einrichtung der Absenderadresse, während der lokale Leitfaden das Feldverhalten je nach Verbindungsprotokoll unterschiedlich beschreibt. Zeichnen Sie das beobachtete Ergebnis für die ausgewählte Bereitstellung auf, anstatt davon auszugehen, dass eine Zuordnung für alle Editionen gilt.
Verwenden Sie dokumentierte Cloud-Labels und kontogeneriertes DNS
In den Cloud-Versionshinweisen vom 8. April 2026 werden die DKIM -Konfigurationsfelder in „Host/Name“ und TXT Wert“ umbenannt. Host/Name schließt den Selektor ein <Auswahl>. _domainkey bilden. Kopieren Sie die aktuell angezeigten Werte und berücksichtigen Sie dann, ob die DNS Konsole die Domäne automatisch anfügt. Nicht hinzufügen _domainkey zweimal, weil ein älterer Screenshot nur einen nackten Selektor zeigte. Versionshinweise zu ServiceDesk Plus Cloud, DKIM -Konfiguration.
Erfassen Sie für jede vorgeschlagene Änderung den vollständigen DNS Eigentümer, -Typ, den öffentlichen Wert, die betroffene Domäne und den vorherigen Eintrag. Wenn die angezeigte SPF -Anweisung einer vollständigen Richtlinie ähnelt, führen Sie die erforderliche Autorisierung mit den vorhandenen legitimen Absendern zusammen, anstatt eine doppelte Richtlinie zu erstellen oder die E-Mail-Autorisierung des Unternehmens zu ersetzen. Bewerten Sie die effektiven Kosten für die DNS-Suche. Bestätigen Sie, dass die veröffentlichte DNS Antwort zur beabsichtigten Zonen- und Datencenter-/Kontokonfiguration gehört, bevor Sie die Überprüfungsaktion des Anbieters verwenden. SPF Spezifikation.
Die überprüften Quellen stellen keine allgemeingültige Kundenkontrolle dar Return-Path Option für Cloud-native Mail. Lassen Sie diese Fähigkeit unbestätigt, es sei denn, der aktuelle Mieter oder der Support belegen dies. Erstellen Sie keine Bounce-Domain MX Eintrag Oder leihen Sie sich den SPF Wert eines Zoho Produkts aus, nur weil die Organisationen miteinander verbunden sind. Verwenden Sie die für diese ServiceDesk Plus-Bereitstellung angezeigten Aufzeichnungen und prüfen Sie den tatsächlich erhaltenen Umschlag.
Behandeln Sie die externe und die lokale Bereitstellung als separate Authentifizierungsarbeit
Identifizieren Sie für externe Cloud-Mails den tatsächlichen Dienst für ausgehende Postfächer und die unterstützte Verbindungsmethode im aktuellen Mandanten. Der ältere Cloud-Konfigurationsleitfaden beschreibt externe SMTP Einstellungen, beweist jedoch nicht, dass alle historischen Authentifizierungsmethoden weiterhin unterstützt werden. Validieren Sie die aktuelle Methode des Kontos, anstatt die veraltete Basisauthentifizierung zu aktivieren, um einen Screenshot zu reproduzieren. Externe Cloud-Mail-Einstellungen.
Für den lokalen ServiceDesk Plus konfiguriert ein SDAdmin das ausgewählte ausgehende Protokoll und die Server- oder API-Verbindung. Das beibehaltene Handbuch enthält eine Beispiel-Mail-Konnektivitätsprüfung und warnt davor, dass ein sekundärer Mailserver nach dem Failover weiterhin verwendet werden kann. Wenn ein sekundärer Server konfiguriert ist, beziehen Sie dessen Sendeidentitäten in den Akzeptanzplan ein, anstatt davon auszugehen, dass die primäre Route immer Nachrichten verarbeitet. Koordinieren Sie jede Rückkehr zum Primärserver als betriebliche Änderung. Ausgehende Konfiguration und Verhalten des Sekundärservers.
Die Verbindungsauthentifizierung wie OAuth autorisiert den Anwendungszugriff auf einen Postfachdienst. Es selbst veröffentlicht SPF nicht, ermöglicht keine DKIM Signierung und weist auch nicht nach DMARC Ausrichtung. Der Administrator des endgültigen Sendedienstes muss diese Kontrollen für die tatsächlichen Absender- und Umschlagidentitäten überprüfen. Fordern Sie nur die Berechtigungen an, die für die genehmigte Integration erforderlich sind. Halten Sie Passwörter, Token und Client-Geheimnisse von DNS Änderungstickets, Screenshots und Artikelbeweisen fern.
Eine erfolgreiche Beispiel-E-Mail liefert nützliche Konnektivitätsnachweise, eine Ticket-Antwort, eine automatisierte Benachrichtigung und eine Nachricht mit benutzerdefinierten Funktionen können jedoch unterschiedliche Standardeinstellungen oder Weiterleitungen haben. Testen Sie die tatsächlich genutzten Geschäftswege. Überprüfen Sie bei lokalen Änderungen, ob der E-Mail-Abruf vorübergehend gestoppt wurde, und stellen Sie ihn nach der genehmigten Änderung wieder her, damit die Authentifizierungsarbeit nicht stillschweigend neue Tickets verhindert.
Überprüfen Sie die Cloud-Workflow-Regeln, bevor Sie DNS beschuldigen
In den Cloud-Versionshinweisen vom 20. Mai 2026 werden Empfängereinschränkungen beschrieben, wenn die standardmäßige native Adresse der Absender für Testlizenzen und neu konfigurierte Standardlizenzen ist. Nicht angemeldete Empfänger können übersprungen werden, oder eine Nachricht wird möglicherweise nicht gesendet, wenn alle Empfänger nicht angemeldet sind. Überprüfen Sie die Systemprotokolle und die tatsächliche Kombination aus Lizenz und Absender, bevor Sie dieses Symptom als SPF Problem diagnostizieren. Schutzmaßnahmen für den Cloud-Mail-Versand.
Derselbe Versionsverlauf dokumentiert das DRE-Sendmail-Offloading: E-Mails mit benutzerdefinierten Funktionen werden als Systembenachrichtigungen behandelt und verwenden den Systemabsender und nicht den von der Funktion bereitgestellten From-Wert. Beziehen Sie benutzerdefinierte Funktionen in das Workflow-Inventar ein und überprüfen Sie das aktuell bereitgestellte Verhalten, wenn ein Test einen unerwarteten Absender anzeigt. Beheben Sie eine System-Absender-Diskrepanz nicht, indem Sie DNS für eine Adresse ändern, die die Anwendung nicht mehr ausgibt. Cloud DRE-Sendmail-Verhalten.
Diese Anwendungsprüfungen sind von der Eingangsfilterung getrennt. Eine vor der Ticketerstellung abgelehnte eingehende Nachricht ist kein Beweis für einen Fehler bei der ausgehenden Authentifizierung. Bewahren Sie die Richtung, den Zeitstempel und das relevante Protokollereignis im Vorfalldatensatz auf. Vermeiden Sie es, DMARC Prüfungen zu deaktivieren, eine breite Zulassungsliste einzurichten oder die Richtlinie der gesamten Domain als Diagnoseabkürzung zu lockern.
Vervollständigen Sie die ursprüngliche Identitätstabelle der empfangenen Nachricht
Die erforderliche ursprüngliche Identitätstabelle wurde hier nicht ausgeführt. Erstellen Sie eine Zeile für jede getestete Bereitstellung, Instanz, ausgehende Route, Von-Domäne und jeden Workflow. Geben Sie Build- oder Cloud-Kontext, ggf. Lizenz, Zeitstempel, Ticket- oder Test-ID, ausgehenden Dienst, Von, Antwort-An, Return-Path , vertrauenswürdige Empfänger SPF Domäne/-Ergebnis, jedes DKIM d=/s= und -Ergebnis, DMARC Ergebnis, Ausrichtungsbestimmung, Empfängerergebnis und eingeschränkten Beweisort an. Unterscheiden Sie die Ablehnung des Sendens einer Anwendung von der Ablehnung der Authentifizierung durch einen empfangenden Server.
Verwenden Sie synthetische Tickets und kontrollierte Empfänger. Überprüfen Sie die Antwort des Anfragenden, eine automatische Benachrichtigung, alle aktiven Gruppenadressen und alle wesentlichen benutzerdefinierten Funktionspfade. Wenn eine dokumentierte Failover-Route vorhanden ist, testen Sie diese nur im Rahmen einer genehmigten Betriebsübung. Stellen Sie sicher, dass eine Antwort zum vorgesehenen Ticket zurückkehrt und dass die eingehende Weiterleitung keine Schleife oder doppelte Anforderungen erzeugt. Behalten Sie die ursprünglichen Nachrichtenquellen bei und minimieren Sie gleichzeitig persönliche Angaben im Rezensionsexemplar.
DMARC vergleicht die sichtbare Von-Domäne mit einer vorübergehenden SPF oder DKIM Identität im anwendbaren Ausrichtungsmodus. Ein DKIM Pass für die Anbieterdomäne oder eine markenbezogene Helpdesk-URL allein beweist keine Übereinstimmung. Überprüfen Sie alle Signaturen und nutzen Sie die vertrauenswürdigen Ergebnisse des Empfängers. DKIM -Spezifikation Und DMARC -Spezifikation.
Stellen Sie den Dienst unter Beibehaltung des Domänenschutzes wieder her
Wenn keine Nachricht ausgegeben wird, überprüfen Sie zunächst die Benachrichtigungsregeln, Empfängerbeschränkungen, Absenderüberprüfung und Verbindungsfehler. Wenn die Lieferung den Empfänger erreicht, die Authentifizierung jedoch fehlschlägt, untersuchen Sie den beobachteten Umschlag oder Selektor beim tatsächlichen ausgehenden Dienst. Wenn ein Gateway signierte Inhalte ändert, vergleichen Sie eine kontrollierte direkte Route mit dem betroffenen Pfad. Wenn DNS erfolgreich ist, die Antworten jedoch verschwinden, überprüfen Sie das Weiterleitungs- und Ticketverarbeitungsverhalten separat.
Halten Sie nach Möglichkeit nur den betroffenen Workflow an. Stellen Sie bei Bedarf genehmigte vorherige Routing- oder DNS Werte wieder her und testen Sie dann sowohl die ausgehende Identität als auch die eingehende Ticketverarbeitung erneut. Ersetzen Sie die durchgesetzte DMARC -Richtlinie der Organisation nicht durch ein Überwachungsbeispiel als universellen Wiederherstellungsschritt. Hier wurden kein Mandant, keine Serverkonfiguration, kein Live DNS oder keine empfangene Nachricht überprüft. Die genaue Produkt-/Build-Bestätigung, die ursprüngliche routenspezifische Identitätstabelle, die mandantenspezifische FAQ-Anwendbarkeit und die KMU-Genehmigung für menschliche E-Mail-Sicherheit bleiben offen; Dieses Manuskript ist ein unveröffentlichter Kandidat.
Trennen Sie den Emissionsfehler vom Authentifizierungsfehler
Behalten Sie für eine vorgeschlagene Vorfallzeile den Workflow, die Absenderauswahl, den Lizenz-/Build-Kontext, den Anwendungsemissionsstatus, die tatsächliche ausgehende Route und den Empfängernachweis bei. Wenn die Anwendung einen Empfänger übersprungen hat, können DNS Änderungen nicht nachweisen, dass eine Nachricht gesendet wurde. Wenn der Empfänger eine gesendete Nachricht abgelehnt hat, behalten Sie die genaue Ferndiagnose bei. Wenn die Authentifizierung erfolgreich ist, eine Antwort jedoch ihr Ticket verfehlt, untersuchen Sie Routing und Threading separat. Lassen Sie nicht verfügbare Beweise unbekannt, anstatt den Vorfall standardmäßig der SPF zuzuordnen.