In diesem Leitfaden stellen Sie sicher, dass Ihr E-Mail-System für eine nahtlose Integration mit Zendesk optimiert ist. Wenn Sie die in diesem Beitrag beschriebenen Best Practices befolgen, können Sie das Vertrauensniveau Ihres E-Mail-Servers verbessern und das Risiko von Problemen bei der Arbeit mit Zendesk minimieren.

Dieser Beitrag enthält die folgenden Einrichtungsempfehlungen und Best Practices:

Empfehlung 1: PTR-Eintrag für SMTP-Server einrichten, die E-Mails an Zendesk senden

Stellen Sie sicher, dass alle IP-Adressen, die Sie zum Senden von E-Mails an Support verwenden, einen Pointer (PTR)-Eintrag aufweisen. PTR-Einträge bieten zusätzliche Sicherheit, dass die angegebene IP-Adresse eine Verbindung zum Domäneninhaber hat. Wenn jemand von domain.com eine E-Mail an Support sendet, sollte sich die IP-Adresse 1.2.3.4 beispielsweise in mail.domain.com auflösen.

Im Idealfall sollte ein PTR-Eintrag derselben Domäne angehören, die E-Mails an Support sendet. Sie sollte keine IP-Adressnummern oder Schlüsselwörter enthalten, die angeben, dass eine IP-Adresse zu einem privaten ISP gehört.

Beispiel für den richtigen Eintrag für domain.com:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com

Beispiel für einen fehlenden Datensatz:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)

Beispiel für den Datensatz, der nicht zum Senden einer E-Mail verwendet werden sollte:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com

Empfehlung 2: HELO- und EHLO-Grußhostname einrichten

HELO-Name wird von SMTP-Servern verwendet, um sich gegenseitig zu begrüßen. Der HELO-Eintrag, der gemäß RFC 5321 (§2.3.5) aufgelöst werden kann, sollte zur Domäne des E-Mail-Absenders gehören und mit einem MX-Eintrag übereinstimmen. Support erwartet, dass SMTP-Server, die E-Mails an Support senden, einen auflösbaren HELO-Hostnamen haben.

Beispiel für den richtigen Eintrag für domain.com:

  • HELO mail.domain.com

Beispiel für HELO-Grüße, die als wenig vertrauenswürdig gelten:

  • HELO mail.otherdomain.com
  • HELO localhost
  • HELO 1.2.3.4
  • HELO invalid.tld
  • HELO not.existing.domain.com
    Weitere Informationen finden Sie unter Liste der SMTP-Server-Rückgabecodes aus Wikipedia.

Empfehlung 3: SPF-Einträge

Domänen, die E-Mails an Support senden, sollten über einen gültigen SPF-Eintrag verfügen, der IP-Adressen berechtigt, E-Mails im Namen der Domäne zu senden.

Nachfolgend zwei Beispiele für den richtigen SPF-Eintrag für die folgende Situation:

  • domain.com
  • SMTP servers with address 1.2.3.4
  • MX record mail.domain.com pointing on 1.2.3.4.

Beide Beispiele würden 1.2.3.4 ermöglichen, E-Mails im Namen von domain.com zu senden.

  • domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”
  • domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”

Empfehlung 4: SPF, DKIM, DMARC und ARC

Um die Anzahl von Spoofing- und Spam-E-Mails zu reduzieren, können Sie als zusätzliche Sicherheitsebene für eingehende E-Mails die Absenderauthentifizierung mit SPF-, DKIM-, DMARC- und ARC-Ausrichtung aktivieren. Weitere Informationen finden Sie unter Authentifizieren eingehender E-Mails (SPF, DKIM, DMARC und ARC).

Empfehlung 5: Hinzufügen von ARC-Headern

Für Konten, die Datenverkehr an Zendesk weiterleiten, empfehlen wir, ARC-Header hinzuzufügen, damit wir Ihre Authentifizierungsbewertung des Datenverkehrs, der bei Ihren Weiterleitungsservern einging, einbeziehen können.

Best Practices zum Senden von E-Mails mit Skripts und Webformularen

Das Senden von E-Mails an Support über Webformulare oder automatisierte Skripts wird nicht empfohlen und derzeit nicht unterstützt. Kunden, die weiterhin solche E-Mails senden möchten, müssen die unten aufgeführten Regeln befolgen.

  • Alle sendenden Webformulare müssen entweder authentifiziert werden oder CAPTCHA oder beides verwenden. Zendesk kann Spam-Angriffe, die Sie zulassen und fördern, nicht verhindern.
  • Wenn Sie E-Mails über Webformulare, Webanwendungen oder Automatisierungsskripts an Support senden, sollten diese gemäß RFC 5322 korrekt formatiert sein.
  • Nachrichten sollten die Kopfzeilen Betreff:, Von:, An: und Antwort an: richtig formatiert enthalten.
  • Die sendende IP-Adresse sollte einen PTR-Eintrag aufweisen (umgekehrte DNS-Auflösung).
  • Support empfiehlt, gültige SPF-Einträge hinzuzufügen, diese E-Mails mit dem in der DNS-Zone der sendenden Domäne veröffentlichten DKIM-Schlüssel zu signieren und eine DMARC-Richtlinie veröffentlichen zu lassen, in der die Art und Weise festgelegt ist, wie E-Mails behandelt werden sollen.
  • Der HELO-Gruß sollte einen gültigen auflösbaren DNS-Namen aufweisen
  • Weiterleiten von E-Mails aus einem Webformular an eine externe Supportadresse, um Datenredundanz zu vermeiden und die Wahrscheinlichkeit von Sperrungen oder Datenverkehreinbrüchen zu verringern
  • Wenn Sie an eine native Zendesk Support-Adresse (Support@IhreSubdomäne.zendesk.com) senden, sollte Ihr Formular in der Lage sein, vorübergehende Netzwerkfehler und 4xx-Antworten zu verarbeiten, um die Stabilität zu gewährleisten.
  • Hardcodieren Sie ein MX-Relay nicht in einen unserer MX-Einträge. Jedes Relay sollte einen MX-Lookup durchführen
  • Verwenden Sie die Funktion Als Spam markieren nicht für Einsendungen aus Ihrem Webformular. Dies wirkt sich negativ auf den Ruf des Absenders Ihres Formulars aus
  • Zendesk-Kundensupport bietet keinen Support für die Funktionen Ihres Webformulars

Best Practices zum Senden vertrauenswürdiger E-Mails

Zendesk vertraut nicht auf:

  • E-Mails, die den E-Mail-Absender fälschen, ohne dass ein autorisierter SPF-Eintrag in der DNS-Zone des Domäneninhabers veröffentlicht wird

  • E-Mails mit gefälschter Absenderadresse, ungültiger oder nicht ausgerichteter DKIM-Signatur oder fehlgeschlagener SPF-Prüfung

    Hinweis: Zendesk versucht, weitergeleitete E-Mails zu erkennen, wenn Sie E-Mails von Ihrer Domäne an eine Zendesk Support Subdomäne weiterleiten, z. B. Support@IhreDomäne.com >> Support@IhreSubdomäne.zendesk.com. Falls Zendesk die E-Mail-Weiterleitung erkennt, verfolgt Zendesk alternative Ansätze zur Authentifizierung des sendenden SMTP-Servers. Versuchen Sie jedoch, den Weiterleitungsserver so zu konfigurieren, dass die DKIM-Signatur erhalten bleibt und der ursprüngliche E-Mail-Text und sensible Header nicht manipuliert werden, da dies zu Fehlern führen kann. Verwenden Sie nach Möglichkeit auch ARC-Header.
  • E-Mails, die ungültige, nicht vorhandene oder nicht auflösbare Domänennamen im Kopfbereich des Absenders und Empfängers verwenden, werden wahrscheinlich gesperrt oder abgewiesen.

Support hat nur geringes Vertrauen in E-Mails, die über einen SMTP-Server mit einem fehlenden PTR-Eintrag oder einem ungültigen HELO-Gruß gesendet wurden.

Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.

Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.

Powered by Zendesk