Authentifizieren Sie über Zendesk gesendete E-Mails: Konfiguration und Überprüfung

Umfang und Voraussetzungen

Verwenden Sie diese Anleitung für Zendesk Support-Sendungen von einer externen benutzerdefinierten Domänen-Supportadresse. Fügen Sie diese Adresse zu Zendesk hinzu, bevor Sie die Domänenautorisierung konfigurieren. Adressen in öffentlichen Postfachdomänen können kein kundengesteuertes DNS verwenden und eine Gmail Connector-Route erfordert eine separate Überprüfung. Die eingehende Weiterleitung an eine Support-Adresse ist kein Beweis dafür, dass die ausgehende Authentifizierung konfiguriert ist.

Konfigurieren Sie die dokumentierte Route

• Schritt 1: Inventarisieren Sie alle externen Domänen, die von den Supportadressen verwendet werden. Speichern Sie den aktuellen SPF Politik und Wähler Datensätze, bevor Sie sie ändern.
• Schritt 2. Hinzufügen include:mail.zendesk.com an die einzelne SPF TXT Richtlinie der Domain unter Beibehaltung anderer autorisierter Absender. Das Beispiel von Zendesk ist allein für seinen Service v=spf1 include:mail.zendesk.com -all. Seine aktuellen Anweisungen erfordern das Einschließen in die erste Suchschicht; Validieren Sie die resultierende Richtlinie, anstatt sie unsichtbar in einem anderen Include zu verschachteln.
• Schritt 3. Veröffentlichen Sie zwei CNAMEs für jede externe Domäne: zendesk1. _domainkey zeigt darauf zendesk1._domainkey.zendesk.com, Und zendesk2. _domainkey zeigt darauf zendesk2._domainkey.zendesk.com. Hostbezeichnungen beziehen sich auf die externe Domäne, es sei denn, Ihre DNS Konsole benötigt den vollständigen Namen.
• Schritt 4. Bestätigen Sie beides CNAME Antworten sind beim autoritativen DNS und über die zur Überprüfung verwendeten Resolver verfügbar. Bewahren Sie beide Aufzeichnungen auf; Die dokumentierte Methode von Zendesk ermöglicht die Schlüsselrotation ohne manuellen Schlüsselaustausch.
• Schritt 5. Erst wenn DNS bereit ist, öffnen Sie Admin Center, Kanäle, Talk und E-Mail, E-Mail. Aktivieren Sie unter E-Mail-Einstellungen die Option Benutzerdefinierte Domäne für DKIM und speichern. Zendesk warnt davor, dass die Aktivierung der Option, bevor die CNAMEs vorhanden sind, zu Lieferfehlern führen kann.
• Schritt 6: Generieren Sie eine normale Ticketantwort von jeder relevanten Support-Identität. Speichern Sie die zugestellte Rohnachricht und überprüfen Sie die Authentifizierungsergebnisse des Empfängers, nicht nur die Warnung der Agentenschnittstelle.

Produktspezifische Risiken

Der Bestellfehler mit dem höchsten Risiko besteht darin, die Signierung benutzerdefinierter Domänen vor der Veröffentlichung beider CNAMEs zu aktivieren. Wenn das passiert ist, reparieren Sie die Datensätze und überprüfen Sie die E-Mails in der Warteschlange mit dem Support-Inhaber. Vermeiden Sie eine domänenweite DMARC Entspannung als Workaround für eine Route. SPF Validierung kann auch fehlschlagen, wenn ein anderes Include in derselben Richtlinie ungültig ist; Das erneute Hinzufügen Zendesk behebt das Problem nicht. Autorisieren Sie Drittsysteme nicht zum Senden von einer Zendesk-eigenen Subdomain.

Beweisen Sie die Route auf der Empfängerseite

Verwenden Sie ein zugelassenes externes Postfach und speichern Sie die vollständige Rohnachricht mit Zeitstempel und Nachrichtenkennung. In diesem Leitfaden wird kein Live-Tenant-Test beansprucht. Das Folgende ist ein Abnahmearbeitsblatt, das während der Implementierung auszufüllen ist ein Rekord der beobachteten Ergebnisse.

• Beweisfeld: Sichtbar von; Was aufzuzeichnen ist: Tatsächliche Adresse und Domain; Akzeptanzfrage: Ist dies die beabsichtigte Absenderidentität?
• Beweisfeld: Umschlag; Was soll aufgezeichnet werden: Return-Path und vom Empfänger gemeldete SPF Domäne; Akzeptanzfrage: Welche Domäne hat SPF tatsächlich authentifiziert?
• Nachweisfeld: SPF ; Was aufzuzeichnen ist: Ergebnis des vertrauenswürdigen Empfängers und bewertete Identität; Akzeptanzfrage: Hat es bestanden und stimmt diese Identität überein?
• Nachweisfeld: DKIM ; Was aufzuzeichnen ist: Jedes d= Domänen-, s= Selektor- und Empfängerergebnis; Akzeptanzfrage: Stimmt mindestens eine bestandene Unterschrift überein?
• Beweisfeld: DMARC ; Was aufzuzeichnen ist: Ergebnis des Empfängers und geltende Richtlinie; Akzeptanzfrage: Existiert ein ausgerichteter Überholweg?
• Beweisfeld: Route; Was aufzuzeichnen ist: Produkt, Konto und Nachrichtentyp; Akzeptanzfrage: Wurde beim Test der Produktionspfad verwendet?

DMARC benötigt mindestens einen ausgerichteten, passierenden SPF oder DKIM Pfad. Eine Weitergabesignatur von einer unabhängigen Dienstdomäne reicht nicht aus. Strikt Ausrichtung erfordert genaue Domänengleichheit; Bei der entspannten Ausrichtung wird die entsprechende Organisationsdomänenbeziehung verwendet. Überprüfen Sie die tatsächlichen Ausrichtungseinstellungen der Domain, bevor Sie den Erfolg melden. Eine Subdomain ist keine automatische strikte Übereinstimmung. SPF verwendet die SMTP Identität, nicht den Anzeigenamen oder die Antwortadresse. Konsultieren Sie die Ausrichtungsglossar bei der Protokollierung der Entscheidung.

Verwenden Authentication-Results von dem empfangenden System, dem Sie vertrauen, und nicht ein Header, der von einem beliebigen Absender bereitgestellt wird. Erfassen Sie alle Signaturen, anstatt beim ersten Fehler anzuhalten. Vergleichen Sie für weitergeleitete E-Mails einen direkten Test mit einer weitergeleiteten Kopie: Durch die Weiterleitung kann sich SPF Bewertung ändern oder der signierte Inhalt geändert werden. Diagnostizieren Sie diese Auswirkungen nicht, indem Sie die Adresse des Spediteurs zu Ihrer Provider-Autorisierung hinzufügen.

Diagnostizieren Sie Fehler, ohne den Zugriff zu erweitern

Vergleichen Sie zunächst das autorisierende DNS mit den exakt konfigurierten Datensatznamen und prüfen Sie dann die rekursive Sichtbarkeit und Dienstvalidierung. Ein falscher Name, ein abgeschnittener Schlüssel oder ein widersprüchlicher CNAME können nicht durch Warten auf Caches behoben werden. Behalten Sie nur eine SPF Richtlinie bei einem Eigentümer bei und überprüfen Sie die Beschränkung auf zehn DNS-Lookup-Terms für ausgewertete Includes und Weiterleitungen, bevor Sie einen anderen Absender zusammenführen. DKIM Selektoren gehören zu einzelnen Signaturkonfigurationen; Überschreiben Sie nicht den Datensatz einer anderen Anwendung, um ein Validierungsergebnis zu erzwingen.

Wenn die Authentifizierung erfolgreich ist, die Zustellung jedoch schlecht ist, überprüfen Sie die Empfängerantwort, die Reputation, den Inhalt und die Sendeberechtigungen separat. DMARC Pass verspricht keine Annahme oder Platzierung im Posteingang. Wenn keiner der Pfade übereinstimmt, stoppen Sie die Erweiterung und korrigieren Sie die tatsächliche Absenderkonfiguration. Schwächen Sie nicht die DMARC Richtlinie der gesamten Domain, um einen einzelnen Produktfehler zu verbergen.

Übergabe und Genesung

Speichern Sie den genehmigten DNS Diff, die Ergebnisse der öffentlichen Suche, den Dienststatus und das geschwärzte Arbeitsblatt für empfangene Nachrichten bei einem benannten Eigentümer. Halten Sie Zugangsdaten und private Schlüssel von Tickets fern. Bei einem Fehler pausieren Sie den betroffenen Sendeauftrag oder verwenden Sie eine zuvor getestete Route unter der Kontrolle des Diensteigentümers. Stellen Sie nur die geänderten Datensätze wieder her, die zu dieser Integration gehören. Bewahren Sie öffentliche Schlüssel auf, die für Flugnachrichten benötigt werden. Erneuter Test nach Rollback, Schlüsselrotation, Domänenmigration oder einer Änderung im ausgehenden Relay. Schließen Sie die Änderung nur ab, wenn der Produktbesitzer und der E-Mail-Administrator die beobachtete Identitätskette erklären können.

Bestätigen Sie die Anbietergrenze

Die SPF -Seite identifiziert include:smtp.zendesk.com und include:support.zendesk.com als ältere Alternativen. Überprüfen Sie jede Migration mit dem DNS Eigentümer, anstatt doppelte Autorisierungen auf unbestimmte Zeit aufzubewahren. Der Gmail Connector verfügt über eine eigene SPF Empfehlung; Behandeln Sie es nicht stillschweigend als dieselbe externe Domänen-Ticketroute. Die angegebene vierteljährliche Schlüsselrotation hängt von der Beibehaltung beider verwalteter CNAMEs ab.

Arbeiten Sie einen fiktiven Diagnosefall durch

Nur fiktiver schriftlicher Fall: ZD-01 geht davon aus, dass eine Ticketantwort From help@studio.example mit einer fehlerhaften d=studio.example -Signatur am Selektor zendesk1 verwendet und dem autorisierenden DNS dieser CNAME fehlt. SPF und andere Signaturen sind unbekannt; Es wurde kein vollständiger DMARC Fehler festgestellt. Der Supportinhaber muss die Erweiterung stoppen, die dokumentierte DNS Voraussetzung wiederherstellen und die Ticketroute erneut testen, anstatt die gesamte Domänenrichtlinie zu lockern. Ein funktionierender eingehender Vorstoß ist kein Gegenbeweis. In diesem Fall wurde kein Mandant, DNS , Serverbefehl oder Nachricht ausgeführt.

Trennen Sie eine vorübergehende Nachricht von der Durchsetzungsbereitschaft

RFC 9989 Abschnitt 7.4 erfordert gültiges DKIM für eine Domain-Veröffentlichung p=reject und warnt vor der Interoperabilität indirekter E-Mails. Ein einzelnes abgestimmtes SPF Ergebnis allein rechtfertigt nicht die Einführung einer Ablehnungsrichtlinie. Überprüfen Sie alle legitimen Routen und Richtlinieneigentümer getrennt von dieser Anbietereinrichtung.