Anhand dieser Anleitung können Sie sicherstellen, dass Ihr E-Mail-System für eine nahtlose Integration mit Zendesk optimiert ist. Durch Befolgen der in diesem Beitrag beschriebenen Best Practices 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
  • Empfehlung 2: HELO- und EHLO-Gruß-Hostname einrichten
  • Empfehlung 3: SPF-Einträge
  • Empfehlung 4: DMARC und DKIM
  • Best Practices für den Versand von E-Mails über Skripts und Webformulare
  • Best Practices für den Versand vertrauenswürdiger E-Mails

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 zur Begrüßung verwendet. 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 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 in diesem Beitrag von Wikipedia: Liste der SMTP-Server-Rückgabecodes.

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, im Namen der Domäne E-Mails 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.

In beiden Beispielen kann 1.2.3.4 im Namen von domain.com E-Mails 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 im folgenden Beitrag: Authentifizierung eingehender E-Mails.

Empfehlung 5: Hinzufügen von ARC-Headern

Für Konten, die den Datenverkehr an Zendesk weiterleiten, empfehlen wir, ARC-Header hinzuzufügen, damit wir Ihre Authentifizierung des Datenverkehrs, der bei Ihren Weiterleitungsservern eintraf, berücksichtigen 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 und/oder CAPTCHA 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 sie gemäß RFC 5322 korrekt formatiert sein.
  • Nachrichten sollten die Header 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 zu veröffentlichen, in der 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 zum Zwecke der Datenredundanz und um die Wahrscheinlichkeit von Sperrungen oder Datenabbrüchen zu verringern.
  • Wenn Sie an eine native Zendesk Support-Adresse (Support@subdomä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 sendenden Formulars aus.
  • Zendesk Customer Support bietet keinen Support für die Funktionen Ihres Webformulars.

Best Practices zum Senden vertrauenswürdiger E-Mails

Zendesk vertraut nicht auf Folgendes:

  • 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@Subdomäne.zendesk.com. Falls Zendesk E-Mail-Weiterleitung erkennt, wählt 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 die sensiblen 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 ein 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