Was sind die Best Practices, um sicherzustellen, dass E -Mail -Systeme in Support funktionieren?

Frage

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

Antwort

Zendesk ist bemüht, Ihren Posteingang frei von Spam zu halten, aber Sie können bestimmte Maßnahmen ergreifen, um die Kanäle zu schützen, über die Sie mit Kunden interagieren. Dieser Beitrag bietet einen Überblick über die Erhöhung der Vertrauensstufe Ihres E -Mail -Servers.

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
• Senden von E -Mails über Skripts und Webformulare
• 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 Zendesk Support verwenden, einen Zeigerdatensatz (PTR) aufweisen. PTR -Einträge geben zusätzliche Sicherheit, dass die angegebene IP -Adresse eine Verbindung zum Domäneninhaber 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 Support sendet.

Idealerweise sollte ein PTR -Eintrag zu der Domäne gehören, die E -Mails an Support sendet. Er darf keine IP -Adressennummern oder Schlüsselwörter enthalten, die darauf hinweisen, dass eine IP -Adresse 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 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

HELO name wird von SMTP -Servern verwendet, um sich gegenseitig zu begrüßen. Der gemäßRFC 5321 (§2.3.5)auflösbare HELO -Eintrag 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 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 Beitrag aus der Wikipedia: Liste der SMTP -Server -Rückkehrcodes.

SPF -Einträge

Domänen, die E -Mails an Support senden, sollten über einen gültigen SPF -Eintrag verfügen, der IP -Adressen autorisiert, 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 ermöglichen es 1.2.3.4, 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”

DMARC und DKIM

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

Senden von E -Mails über Skripts und Webformulare

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

• Alle sendenden Webformulare müssen entweder eine Authentifizierung erfordern oder CAPTCHA verwenden oder beides. Wir können keine Spam -Angriffe verhindern, die Sie zulassen und fördern.
• Wenn Sie E -Mails über Webformulare, Webanwendungen oder Automatisierungsskripts an Support senden, müssen sie gemäß RFC 5322richtig formatiert werden.
• Nachrichten sollten korrekt formatierte Kopfzeilen für Betreff:, Von:, An: und Antwort an: enthalten.
• Die sendende IP -Adresse sollte einen PTR -Eintrag aufweisen (umgekehrte DNS -Auflösung).
• In Support sollten Sie gültige SPF -Einträge hinzufügen, diese E -Mails mit dem in der DNS -Zone der sendenden Domäne veröffentlichten DKIM -Schlüssel signieren und eine DMARC -Richtlinie veröffentlichen, in der festgelegt ist, wie E -Mails behandelt werden sollen.
• Der HELO Gruß sollte einen gültigen auflösbaren DNS -Namen enthalten.
• Leiten Sie E -Mails von einem Webformular an eine externe Supportadresse weiter, um Datenredundanzen zu vermeiden und die Sperrung zu verhindern.
• Wenn Sie an eine native Zendesk -Supportadresse (support@subdomäne.zendesk.com) senden, sollte Ihr Formular vorübergehende Netzwerkfehler und oder verarbeiten können 4xx Antworten für mehr Ausfallsicherheit.
• Codieren Sie ein MX -Relay nicht fest mit einem unserer MX -Einträge. Jedes Relay sollte eine MX -Suche durchführen.
• Verwenden Sie die Funktion Als Spammarkieren nicht für Einreichungen über Ihr Webformular. Dies wirkt sich negativ auf die Reputation des Formulars beim Senden aus.
• Der Zendesk -Kundensupport bietet keinen Support für die Funktionalität Ihres Webformulars.

E -Mails, denen Zendesk nicht vertraut

Zendesk vertraut nicht:

• E -Mails, die Spoofing -Nachrichten an den Absender senden, 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.*
• E-Mails mit ungültigen, nicht vorhandenen oder nicht auflösbaren Domänennamen im Absender- und Empfänger-Header der E-Mail.

Support ist gegenüber E -Mails, die über einen SMTP -Server mit einem fehlenden PTR -Eintrag oder einem ungültigen HELO -Gruß gesendet werden, ein geringes Maß an 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@meinedomäne.com >> support@subdomäne.zendesk.com. Für den Fall, dass Zendesk die E -Mail -Weiterleitung erkennt, unternimmt Zendesk alternative Methoden, um den sendenden SMTP -Server zu authentifizieren. Sie können den Weiterleitungs -SMTP -Server jedoch so konfigurieren, dass die DKIM -Signatur beibehalten wird und der ursprüngliche E -Mail -Text und die sensiblen Kopfzeilen nicht geändert 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.