Mit diesem Leitfaden können Sie sicherstellen, dass Ihr E-Mail-System für die 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 erhöhen und das Risiko von Problemen bei der Arbeit mit Zendesk minimieren.

Dieser Beitrag enthält die folgenden Empfehlungen und Best Practices zur Einrichtung:

  • Empfehlung 1: Richten Sie einen PTR-Eintrag für SMTP-Server ein, die E-Mails an Zendesk senden
  • Empfehlung 2: Richten Sie den Hostnamen für HELO- und EHLO-Grüße ein
  • Empfehlung 3: SPF-Einträge
  • Empfehlung 4: DMARC und DKIM
  • Best Practices für das Senden von E-Mails mit Skripts und Webformularen
  • Best Practices für das Senden vertrauenswürdiger E-Mails

Empfehlung 1: Richten Sie einen PTR-Eintrag für SMTP-Server ein, die E-Mails an Zendesk senden

Stellen Sie sicher, dass alle IP-Adressen, die Sie zum Senden von E-Mails an Zendesk Support verwenden, einen Pointer (PTR)-Eintrag haben. PTR-Einträge geben Ihnen zusätzliche Sicherheit, dass die angegebene IP-Adresse eine Verbindung zum Domäneninhaber aufweist. So sollte die IP-Adresse 1.2.3.4 beispielsweise in mail.domäne.com aufgelöst werden, wenn jemand von domäne.com aus eine E-Mail an den Support sendet.

Im Idealfall sollte ein PTR-Eintrag zur selben Domäne gehören, über die E-Mails an Support gesendet werden. Sie darf keine IP-Adressnummern oder Schlüsselwörter enthalten, die darauf hinweisen, dass die IP-Adresse zu einem privaten ISP gehört.

Beispiel für den korrekten 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: Richten Sie den Hostnamen für HELO- und EHLO-Grüße ein

Der HELO-Name wird von SMTP-Servern verwendet, um sich gegenseitig zu begrüßen. Der HELO-Eintrag, der gemäß RFC 5321 (Nr. 2.3.5)auflösbar sein muss, 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 Zendesk Support senden, über einen auflösbaren HELO-Hostnamen verfügen.

Beispiel für den korrekten 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 in diesem Beitrag auf Wikipedia: Liste der Rückgabecodes des SMTP-Servers.

Empfehlung 3: SPF-Einträge

Domänen, die E-Mails an Support senden, müssen einen gültigen SPF-Eintrag aufweisen, der IP-Adressen zum Senden von E-Mails im Namen der Domäne autorisiert.

Hier finden Sie 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: DMARC und DKIM

Um die Anzahl von Spoofing- und Spam-E-Mails zu reduzieren, fügen Sie Ihren eingehenden E-Mails eine zusätzliche Sicherheitsebene hinzu, indem Sie die Absenderauthentifizierung mit SPF-, DKIM- und DMARC-Ausrichtung aktivieren. Weitere Informationen finden Sie im folgenden Beitrag: Authentifizieren eingehender E-Mails (SPF, DKIM, DMARC).

Best Practices für das Senden von E-Mails mit Skripts und Webformularen

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

  • Alle gesendeten Webformulare sollten entweder eine Authentifizierung erfordern 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 den Support senden, müssen diese E-Mails gemäß RFC 5322korrekt formatiert sein.
  • Nachrichten müssen die ordnungsgemäß formatierten Header Subject:, From:, To:und Reply-To: enthalten. 
  • Die sendende IP-Adresse sollte einen PTR-Eintrag (umgekehrte DNS-Auflösung) haben. 
  • Support empfiehlt, gültige SPF-Einträge hinzuzufügen, diese E-Mails mit dem DKIM-Schlüssel zu signieren, der in der DNS-Zone der sendenden Domäne veröffentlicht ist, und eine DMARC-Richtlinie zu veröffentlichen, in der festgelegt ist, wie E-Mails behandelt werden sollen. 
  • Der HELO-Gruß muss einen gültigen auflösbaren DNS-Namen enthalten.
  • Leiten Sie E-Mails von einem Webformular aus Gründen der Datenredundanz und zur Senkung der Wahrscheinlichkeit einer Sperrung an eine externe Supportadresse weiter.
  • Wenn Sie an eine native Zendesk-Supportadresse (support@subdomäne.zendesk.com) senden, sollte Ihr Formular vorübergehende Netzwerkfehler verarbeiten können 4xx für mehr Resilienz.
  • Codieren Sie ein MX-Relay nicht fest für einen unserer MX-Einträge. Jedes Relay sollte einen MX-Lookup durchführen.
  • Verwenden Sie nicht die Funktion „ Als Spam markieren“ für Einträge aus Ihrem Webformular. Dies wirkt sich negativ auf den Ruf Ihres Formulars aus.
  • Der Zendesk-Kundensupport bietet keinen Support für die Funktionen Ihres Webformulars.

Best Practices für das Senden vertrauenswürdiger E-Mails

Zendesk vertrauenswürdig ist nicht:

  • E-Mails, die den Absender spoofieren, ohne dass ein autorisierender SPF-Eintrag in der DNS-Zone des Domäneninhabers veröffentlicht wurde
  • E-Mails mit Spoofing-Absenderadresse, ungültiger 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, zum Beispiel support@ihredomäne.com >> support@subdomäne.zendesk.com. Wenn Zendesk eine E-Mail-Weiterleitung erkennt, unternimmt Zendesk alternative Ansätze, um den sendenden SMTP-Server zu authentifizieren. Konfigurieren Sie den SMTP-Weiterleitungsserver jedoch so, dass die DKIM-Signatur erhalten bleibt und der ursprüngliche E-Mail-Text und sensible Header nicht manipuliert werden.
  • E-Mails mit ungültigen, nicht vorhandenen oder nicht auflösbaren Domänennamen in den Absender- und Empfängerheadern der E-Mail

Zendesk Support hat E-Mails, die über einen SMTP-Server mit einem fehlenden PTR-Eintrag oder einem ungültigen HELO-Gruß gesendet wurden, als wenig vertrauenswürdig.

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