Misfit-E-Mail-Serie: Meine E-Mail ist nicht authentisch genug

In meinem letzten Artikel habe ich die Grundlagen und Hintergründe der verschiedenen Authentifizierungsprotokolle behandelt, mit denen Absender zeigen können, dass ihre E-Mails authentisch für ihre Marken sind.  Kürzlich wurde mir die Frage gestellt: „Was passiert, wenn meine E-Mail nicht authentisch genug ist?“ Heute bespreche ich mögliche Probleme und Lösungen bei fehlerhafter E-Mail-Authentifizierung. Lehnen Sie sich also entspannt zurück.

E-Mail-Authentifizierungsprotokolle sind technisch.  Und wie bei allen technischen Dingen kann und wird es Konsequenzen haben, wenn sie nicht richtig implementiert werden.  Einige sind nur ein kleines Ärgernis, andere können geradezu katastrophal sein. In diesem Blog möchte ich einige der häufigeren Fälle beleuchten, in denen unsere Kundschaft ihre E-Mail-Authentifizierung nicht ganz richtig einrichtet, und zeigen, was man dagegen tun kann.

Da Mailgun oft als sekundäre Quelle für ausgehende E-Mails einer Domain fungiert, fällt uns auf, dass es unserer Kundschaft oft schwerfällt, die SPF-Einträge für all ihre Versandplattformen richtig zu implementieren.  Ein häufiges Problem besteht darin, dass ein zusätzlicher TXT-Eintrag für den Mailgun-SPF hinzugefügt wird, während der primäre SPF-Eintrag unverändert bleibt. Ein Beispiel wird dies veranschaulichen. Ich verwende ab sofort unsere fiktive Lieblingsdomain meowgun.com.  Wir beziehen uns auf:

dig txt meowgun.com

; <> DiG 9.10.6 <> txt meowgun.com

;; ANSWER SECTION:

meowgun.com.   869    IN TXT    "v=spf1 include:mailgun.org ~all"

meowgun.com.   869    IN TXT    "v=spf1 ipv4:127.0.0.1 ~all"

Hier sehen wir, dass beide SPF-Einträge zurückgegeben werden. Das Problem für die Empfängerserver besteht darin, dass, je nachdem, welcher Eintrag zuerst zurückkommt, entweder der IPv4-Eintrag oder der Eintrag include:mailgun.org erzwungen wird. Wenn Sie Ihr Glück nicht auf die Probe stellen wollen, gibt es einen besseren Weg.

Die Lösung ist ganz einfach: Fassen Sie die Einträge zu einem einzigen, sauberen SPF-TXT-Eintrag mit der richtigen Syntax zusammen. Die SPF-Syntax ist ziemlich flexibel und erlaubt es, eine ganze Reihe von E-Mail-Quellen in einem kleinen TXT-Eintrag unterzubringen – vorausgesetzt, Sie haben Ihre Hausaufgaben gemacht.  Wir empfehlen, die Einträge in dem obigen Szenario wie folgt zu integrieren:

"v=spf1 ipv4:127.0.0.1 include:mailgun.org ~all"

Nun haben wir einen sauberen SPF-Eintrag, der alle unsere E-Mail-Quellen abdeckt.

Die SPF-Spezifikationen begrenzen die Anzahl der DNS-Lookups, die für einen SPF-Eintrag durchgeführt werden können, auf zehn.  Im Folgenden finden Sie alle SPF-Mechanismen, die einen DNS-Lookup auslösen:

• Ein
• Exists
• Include
• MX
• PTR

Bei Absendern mit einer großen Anzahl von E-Mail-Streams für ihre Domain dauert es nicht lange, bis die SPF-Einträge unhandlich werden und das zulässige Limit überschreiten.

Für dieses Problem gibt es keine Universallösung, da es stark von den E-Mail-Quellen des jeweiligen Absenders abhängt.  Wir können Ihnen jedoch einige allgemeine Empfehlungen zur Orientierung geben:

• Ermitteln Sie, wie viele Lookups in Ihrem Include-Mechanismus verwendet werden. Includes können verschachtelt sein und zu mehr als einem Lookup führen.  Der SPF-Eintrag von Mailgun fällt in diese Kategorie und erfordert aufgrund der verschachtelten Includes insgesamt drei Lookups.
• Verwenden Sie keine PTR-Mechanismen.  
• Da IPv4- und IPv6-Mechanismen direkt auf IPs verweisen, erfordern sie keine DNS-Lookups und können nach Belieben verwendet werden.
• Die meisten Webserver und nur wenige eingehende MX-Server sind für den Versand von E-Mails richtig eingerichtet. Seien Sie also vorsichtig bei der Verwendung von A- oder MX-Mechanismen, wenn diese nicht zwingend erforderlich sind.
• Bei einigen Unternehmen ändern sich die E-Mail-Quellen regelmäßig. Überprüfen Sie daher den gesamten SPF-Eintrag gelegentlich und entfernen Sie nicht benötigte Einträge.  Das globale DNS-System wird es Ihnen danken.
• NEIN. PTR. MECHANISMEN.

Um kurz ernst zu bleiben: Der PTR-Mechanismus kann aufgrund seiner Implementierung ziemlich schnell außer Kontrolle geraten, weshalb Sie kaum seriöse Anbieter finden werden, die ihn empfehlen.

Beim Testen oder durch Feedback von der Empfängerseite fällt unserer Kundschaft manchmal auf, dass einige über die Mailgun-Plattform versendete Nachrichten mehr als eine DKIM-Signatur im Header aufweisen.  Oft wenden sie sich an unseren Support, um zu erfahren, warum das passiert und ob ihre Nachrichten möglicherweise falsch konfiguriert sind.

Kein Grund zur Sorge: Ihre Nachrichten sind nicht falsch konfiguriert, und mehrere DKIM-Signaturen haben keinen bedenklichen Hintergrund. Mailgun signiert Nachrichten doppelt mit DKIM, wenn sie an Anbieter gesendet werden, die eine ESP-DKIM-Signatur als Teil ihrer Feedback-Loop-Systeme verlangen.

Gmail und Verizon Media Group (Yahoo/AOL/Verizon) gehören zu den bekanntesten Namen, die diese Art von Feedback-Loop nutzen. Aus diesem Grund haben unsere Reputation- und Engineering-Teams beschlossen, Nachrichten an diese Systeme mit einer doppelten DKIM-Signatur zu versehen, um sicherzustellen, dass wir deren Feedback für unsere Kundschaft erhalten. Doppelt authentifizierte Nachrichten und das Feedback von ESPs sind eine Win-win-Situation.

Als fiktives Admin-Team für meowgun.com, einer etablierten Marke für feinste Katzen-Memes im Internet mit dem Ziel der globalen Meme-Weltherrschaft, möchten wir unsere Absenderdomains um einige neue Bereiche erweitern: Transaktions-E-Mails und Marketingkampagnen. Daher wählen wir transgressions.meowgun.com und meowketing.meowgun.com, um diese beiden neuen E-Mail-Streams abzuwickeln.  Diese Domains werden zusammen mit meowgun.com zu unserem Mailgun-Konto hinzugefügt und erben standardmäßig automatisch die DKIM-Autorität von meowgun.com. 

 Aber sollten sie das auch?

Auch hier gibt es keine Universallösung. Wichtige Überlegungen betreffen jedoch, inwieweit Überschneidungen bei der Domain-Reputation in Ordnung sind, ob ein Domain-Warm-up gewünscht ist, sowie die Lebensdauer des E-Mail-Streams.

Getrennt

• Wenn Sie keine Überschneidungen der Reputation zwischen den E-Mail-Streams wünschen, ist eine Trennung die richtige Lösung.  Jede Version der Domain wird sich dann kaum bis gar nicht auf die Reputation der anderen auswirken.
• Eine Trennung bedeutet, dass die neuen Domains bei den Anbietern noch keine Reputation haben. Planen Sie daher eine geeignete Warm-up-Strategie.
• E-Mail-Streams mit einer langen Lebensdauer sollten am besten getrennt gehalten werden.

Stamm-Domain vererben

• Wenn eine überschneidende Reputation kein großes Problem darstellt, können Sie die Autorität problemlos vererben.  Seien Sie bei Marketing-Streams jedoch vorsichtig: Das Engagement ist im Marketing in der Regel geringer als bei Transaktions-E-Mails oder direkten Nachrichten und könnte sich negativ auf die Domain-Reputation der primären Domain auswirken.
• Wenn Sie das Warm-up einer neuen Domain umgehen möchten, sollten Sie die Vererbung in Betracht ziehen. Auch hier gilt die oben genannte Verschlechterung der Reputation.
• Benötigen Sie einen kurzfristigen E-Mail-Stream (ein paar Wochen bis zu einem Monat) mit geringerem Volumen und einer Zielgruppe mit hohem Engagement, ist eine Vererbung ebenfalls überlegenswert.

Zuletzt sollten Sie bei der DKIM-Autorität bedenken, dass Ihre Entscheidung nicht in Stein gemeißelt ist. Die Einstellung kann jederzeit über unsere Domains-API oder über unseren Support geändert werden. Allerdings gelten auch nach einer Änderung weiterhin die Reputationskriterien.

Da DMARC-Implementierungen durch Empfängersysteme in der Branche immer mehr an Bedeutung gewinnen und die Akzeptanz steigt, kann eine intelligente DMARC-Richtlinie echte Vorteile für die Absenderreputation. bringen.  Wir haben viele sicherheitsbewusste Kunden, die sofort die strengste Richtlinie p=reject anwenden möchten.  Das scheint immer eine gute Idee zu sein, bis sie Berichte über gültige E-Mails erhalten, die aufgrund der Richtlinie blockiert wurden, und verärgerte Kunden sich fragen, wo ihre E-Mails geblieben sind.

Geduld zahlt sich hier aus. Zahlreiche Gespräche mit Kunden haben uns gezeigt, dass es besser ist, eine p=none-Richtlinie über einen längeren Zeitraum zu implementieren, bevor man eine strengere Richtlinie ausprobiert. Dies gibt der Administration Zeit, Berichte über alle E-Mails zu erhalten, die an der Richtlinie scheitern, und den DMARC-Eintrag oder den E-Mail-Stream entsprechend anzupassen. Planen Sie einen Zeitraum von einigen Wochen bis zu einem Monat ein, um alle E-Mail-Streams und ihre jeweiligen Rhythmen zu berücksichtigen. Sobald alle gültigen Streams die Richtlinie bestehen, können Sie sich für eine strengere p=quarantine- oder p=reject-Richtlinie entscheiden, um von der verbesserten Domain-Reputation zu profitieren.

Hoffentlich sind einige dieser Szenarien für unsere Kunden bei der Implementierung der verschiedenen E-Mail-Authentifizierungsprotokolle hilfreich. Zwar gibt es bei jedem Authentifizierungsprotokoll noch viel mehr zu entdecken, aber kein Grund zur Panik. Falls Sie noch Fragen oder Bedenken bezüglich Ihrer E-Mail-Authentifizierungsprotokolle haben, können Sie sich jederzeit an unseren Support wenden. Unser Team hilft Ihnen auf Ihrer E-Mail-Versand-Reise gerne weiter.

Autor: Levi Trejo Technical Account Manager at Sinch Mailgun