Welche Best Practices gibt es, um sicherzustellen, dass die E-Mail-Systeme im Support funktionieren?

Frage

Wie kann ich sicherstellen, dass mein E-Mail-System mit Zendesk funktioniert?

Antwort

Zendesk ist bestrebt, Ihren Posteingang frei von Spam zu halten. Sie können jedoch bestimmte Maßnahmen ergreifen, um die Kanäle zu schützen, über die Sie mit Kunden interagieren. In diesem Beitrag erfahren Sie, wie Sie die Vertrauensstufe Ihres E-Mail-Servers erhöhen.

Dieser Beitrag enthält die folgenden Abschnitte:

• PTR-Eintrag für SMTP-Server, die E-Mails an Zendesk . senden
• HELO und EHLO-Gruß-Hostname
• SPF-Einträge
• DMARC und DKIM
• E-Mails mit Skripts und Webformularen senden
• E-Mails, denen Zendesk nicht vertraut

PTR-Eintrag für SMTP-Server, die E-Mails an Zendesk . senden

Stellen Sie sicher, dass alle IP-Adressen, die Sie zum Senden von E-Mails an den Support verwenden, über einen Pointer-Eintrag (PTR) verfügen. PTR-Einträge geben zusätzliche Sicherheit, dass die angegebene IP-Adresse eine Verbindung zum Domaininhaber hat. Die IP-Adresse 1.2.3.4 sollte beispielsweise in mail.domain.com aufgelöst werden, wenn jemand von domain.com eine E-Mail an den Support sendet.

Im Idealfall sollte ein PTR-Eintrag zu derselben Domäne gehören, von der auch E-Mails an den Support gesendet werden. Sie sollte keine IP-Adressnummern oder Schlüsselwörter enthalten, die darauf hindeuten, dass eine IP-Adresse 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 soll:

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

HELO und EHLO-Gruß-Hostname

Der HELO-Name wird von SMTP-Servern zur Begrüßung verwendet. Der HELO-Eintrag, der gemäß RFC 5321 (§2.3.5) auflösbar ist, 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 korrekten Eintrag für domain.com:

• HELO mail.domain.com

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

• 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 Wikipedia-Artikel: Liste der Rückgabecodes des SMTP-Servers.

SPF-Einträge

Domänen, die E-Mails an den 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 finden Sie zwei Beispiele für den richtigen SPF-Eintrag in der folgenden 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 könnte 1.2.3.4 E-Mails im Namen von domain.com 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”

DMARC und DKIM

Wenn Sie weniger gefälschte E-Mails und Spam erhalten, sollten Sie eingehende E-Mails zusätzlich schützen, indem Sie die Absenderauthentifizierung mit SPF-, DKIM- und DMARC-Ausrichtung aktivieren. Weitere Informationen finden Sie im Beitrag: Authentifizierung eingehender E-Mails (SPF, DKIM, DMARC) .

E-Mails mit Skripts und Webformularen senden

Das Senden von E-Mails an den Support mithilfe von Webformularen oder automatisierten Skripts wird nicht empfohlen und wird derzeit nicht unterstützt. Kunden, die solche E-Mails dennoch senden möchten, müssen die unten aufgeführten Regeln befolgen.

• Alle sendenden Webformulare sollten entweder eine Authentifizierung erfordern oder CAPTCHA verwenden oder beides. Wir können Spam-Angriffe, die Sie zulassen und fördern, nicht verhindern.
• Wenn Sie E-Mails mithilfe von Webformularen, Webanwendungen oder Automatisierungsskripts an den Support senden, müssen die E-Mails gemäß RFC 5322 richtig formatiert sein.
• Nachrichten sollten die korrekt formatierten Kopfzeilen Betreff:, Von:, An: und Antwort an: enthalten.
• Die sendende IP-Adresse sollte über einen PTR-Eintrag (Reverse-DNS-Auflösung) verfügen.
• Der Support empfiehlt Ihnen, gültige SPF-Einträge hinzuzufügen, diese E-Mails mit dem DKIM-Schlüssel zu signieren, der in der DNS-Zone der Absenderdomäne veröffentlicht ist, und eine DMARC-Richtlinie veröffentlichen zu lassen, die die Behandlung von E-Mails festlegt.
• Die HELO-Begrüßung sollte einen gültigen auflösbaren DNS-Namen haben.
• Weiterleiten von E-Mails aus einem Webformular an eine externe Supportadresse aus Gründen der Datenredundanz und um die Wahrscheinlichkeit einer Sperrung zu verringern.
• Wenn Sie an eine native Zendesk-Supportadresse (support@ subdomain.zendesk.com) senden, sollte Ihr Formular in der Lage sein, vorübergehende Netzwerkfehler zu verarbeiten, und oder4xx Antworten auf Resilienz.
• MX-Relays dürfen nicht fest in unsere MX-Einträge codiert werden. Jedes Relay sollte eine MX-Suche durchführen.
• Verwenden Sie nicht die Als Spam markieren für Einsendungen aus Ihrem Webformular. Dies wirkt sich negativ auf den Ruf Ihres Formulars beim Senden aus.
• Der Zendesk-Kundensupport bietet keinen Support für die Funktionen Ihres Webformulars.

E-Mails, denen Zendesk nicht vertraut

Zendesk vertraut nicht:

• E-Mails, bei denen der Absender der E-Mail vorgetäuscht wird, ohne dass ein SPF-Eintrag in der DNS-Zone des Domäneninhabers veröffentlicht wurde.
• E-Mails mit gefälschter Absenderadresse, ungültiger DKIM-Signatur oder fehlgeschlagener SPF-Prüfung.*
• E-Mails mit ungültigen, nicht vorhandenen oder nicht auflösbaren Domänennamen in den Absender- und Empfängerheadern der E-Mail.

Der Support schenkt E-Mails, die über einen SMTP-Server mit fehlendem PTR-Eintrag oder ungültiger HELO-Begrüßung gesendet wurden, nur wenig Vertrauen.

*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 eine E-Mail-Weiterleitung erkennt, versucht Zendesk, den SMTP-Server des Absenders zu authentifizieren. Konfigurieren Sie den SMTP-Weiterleitungsserver jedoch so, dass die DKIM-Signatur erhalten bleibt und der ursprüngliche E-Mail-Text und die vertraulichen Header nicht manipuliert werden.

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.