Die E-Mail-Authentifizierung besteht aus drei Ebenen – SPF, DKIM und DMARC – und ein häufiger Fehler von Nutzern von Cloudflare Email Routing besteht darin, anzunehmen, dass die Aktivierung des Dienstes alle drei auf einmal löst. Cloudflare konfiguriert SPF automatisch für den Empfang, verarbeitet DKIM über ARC bei weitergeleiteten E-Mails und konfiguriert DMARC nicht für Sie. Wenn Sie einen separaten Versandanbieter nutzen, müssen SPF und DKIM für diesen Anbieter manuell hinzugefügt werden. Die Verwechslung dieser Rollen führt dazu, dass E-Mails abgelehnt werden – manchmal auch Ihre eigenen.
Was SPF macht und was Cloudflare hinzufügt
SPF (Sender Policy Framework) ist ein TXT-Eintrag in Ihrer DNS-Zone, der die Server auflistet, die berechtigt sind, E-Mails über Ihre Domain zu senden. Wenn ein empfangender Server eine E-Mail akzeptiert, die angeblich von seudominio.com stammt, fragt er den SPF von seudominio.com ab, um zu prüfen, ob die sendende IP in der Liste enthalten ist.
Wenn Sie E-Mail-Routing aktivieren, fügt Cloudflare automatisch include:_spf.mx.cloudflare.net zum SPF Ihrer Domain hinzu. Dadurch werden die Server von Cloudflare autorisiert, E-Mails für Ihre Domain zu empfangen – was sinnvoll ist, da sie die Server sind, die eingehende Nachrichten annehmen, bevor sie sie weiterleiten.
Der Punkt, der Aufmerksamkeit erfordert: Wenn Sie auch einen Outbound-Versandanbieter nutzen – Resend, SendGrid, Amazon SES, Mailgun – verfügt dieser Anbieter über eigene Server, die in Ihrem SPF erscheinen müssen. Der endgültige SPF-Eintrag muss sowohl Cloudflare als auch den Versandanbieter enthalten. Ein Beispiel mit Resend:
v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all
SPF hat ein Limit von 10 DNS-Suchvorgängen pro Auswertung. Jeder include: zählt als Lookup und kann weitere rekursive Lookups auslösen. Bei der Kombination vieler Anbieter ist es möglich, dass diese Grenze überschritten wird – was dazu führt, dass SPF bei allen Absendern und nicht nur bei einigen fehlschlägt. Tools wie MXToolbox und dmarcian verfügen über Validatoren, die Suchvorgänge zählen und Sie warnen, bevor es zu einem Problem wird.
DKIM beim Empfangen und Senden
DKIM (DomainKeys Identified Mail) funktioniert über asymmetrische Verschlüsselung: Der sendende Server signiert die E-Mail mit einem privaten Schlüssel und der empfangende Server überprüft die Signatur anhand des öffentlichen Schlüssels, der als TXT-Eintrag im DNS der sendenden Domain veröffentlicht wird.
Für über E-Mail-Routing empfangene und weitergeleitete E-Mails verwendet Cloudflare ARC (Authenticated Received Chain). ARC ist eine Reihe von Headern, die die E-Mail-Authentifizierungskette aufzeichnen, während sie über Vermittler läuft – in diesem Fall den Cloudflare-Server. Wenn Cloudflare eine E-Mail weiterleitet, fügt es ARC-Header hinzu, die dem Endempfangsserver mitteilen: „Ich habe diese E-Mail erhalten, die ursprüngliche DKIM-Signatur war zum Zeitpunkt ihres Eintreffens gültig und ich signiere sie, um diese Informationen zu bewahren.“ Cloudflare signiert bei der Weiterleitung erneut mit seinem eigenen DKIM-Schlüssel.
Für E-Mails, die von Ihrem Outbound-Anbieter gesendet werden, funktioniert DKIM anders. Resend, SES oder ein anderer sendender Anbieter werden Sie auffordern, einen oder mehrere TXT-Einträge mit ihrem öffentlichen DKIM-Schlüssel zu Ihrer DNS-Zone hinzuzufügen. Sie fügen diese Datensätze dem Cloudflare-Dashboard hinzu und der Anbieter verwendet den entsprechenden privaten Schlüssel, um E-Mails zu signieren, die über Ihre Domain versendet werden. Cloudflare generiert oder verwaltet diesen Schlüssel nicht – Sie hosten lediglich den TXT-Eintrag, den der Anbieter erstellt hat.
DMARC: was zu konfigurieren ist und in welcher Reihenfolge
DMARC (Domain-based Message Authentication, Reporting and Conformance) befindet sich in einem TXT-Eintrag in _dmarc.seudominio.com und definiert, was empfangende Server tun sollen, wenn eine E-Mail gleichzeitig SPF und DKIM nicht besteht. Außerdem wird definiert, wohin Authentifizierungsberichte gesendet werden sollen.
Cloudflare konfiguriert DMARC nicht für Sie. Sie erstellen den Datensatz manuell. Eine vernünftige Anfangsaufzeichnung:
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; pct=100
p=none bedeutet „überwachen, nicht ablehnen“. Berichte gehen an die in rua (tägliche Gesamtberichte) und ruf (forensische Fehlerberichte) definierten Adressen ein. Diese Berichte im XML-Format zeigen, welche IPs E-Mails über Ihre Domain senden und wie das SPF/DKIM-Ergebnis für jede IP lautet.
Die richtige Reihenfolge ist folgende: Aktivieren Sie zuerst p=none, warten Sie mindestens eine Woche mit den Berichten und überprüfen Sie, ob alle legitimen Absender – der sendende Anbieter, die Formularserver, die Marketingtools – in SPF oder DKIM als ausgerichtet angezeigt werden. Erst nach Bestätigung dieser Ausrichtung gelangen Sie zu p=quarantine (verdächtige E-Mails landen im Spam) und schließlich zu p=reject (verdächtige E-Mails werden beim Empfang abgewiesen).
Der häufigste Fehler besteht darin, p=reject zu aktivieren, bevor die SPF- und DKIM-Einträge des sendenden Anbieters hinzugefügt wurden. Das Ergebnis: Ihre eigenen E-Mails werden von Zielservern abgelehnt, weil sie über Resend oder SES gesendet werden, SPF diese Server jedoch noch nicht berücksichtigt oder der DKIM-Eintrag noch nicht hinzugefügt wurde. DMARC schlägt fehl und mit p=reject wird die E-Mail abgelehnt – aus Sicht des Absenders stillschweigend.
Was Sie überprüfen sollten, bevor Sie die DMARC-Richtlinie ändern
Bevor Sie von p=none zu einer restriktiveren Richtlinie wechseln, lohnt es sich, drei Dinge in den aggregierten Berichten zu überprüfen: dass Cloudflare für eingehende E-Mails, die Sie an Ihre eigenen Konten weiterleiten, als SPF-ausgerichtet angezeigt wird, dass der sendende Anbieter für ausgehende E-Mails als DKIM-ausgerichtet erscheint und dass es keine unerwarteten IPs gibt, die E-Mails über Ihre Domain senden – was auf die Konfiguration eines anderen Dienstes hinweisen würde, den Sie nicht zugeordnet oder missbraucht haben.
Tools wie dmarcian, Postmark (das über einen kostenlosen DMARC-Parser verfügt) und MXToolbox machen XML-Berichte einfach lesbar. Die investierte Zeit lohnt sich. Bei einer Domäne mit ordnungsgemäß konfiguriertem DMARC ist die Wahrscheinlichkeit geringer, dass gefälschte E-Mails von den Empfängern akzeptiert werden – und die Wahrscheinlichkeit, dass legitime E-Mails aufgrund von Konfigurationsfehlern abgelehnt werden, ist geringer.
Lesen Sie auch
- Die Einschränkungen von Cloudflare Email Routing, die im Tutorial nicht erwähnt werden
- Cloudflare Email Routing: E-Mails auf Ihrer Domain empfangen – und was nicht enthalten ist
- Cloudflare KV: Was bedeutet global verteilt, wenn Sie schreiben müssen
- Cloudflare Workers vs. Pages: Der Unterschied, der wichtig ist, bevor Sie sich entscheiden
- Email Routing vs. Improvmx vs. Forward Email: ehrlicher Vergleich
- E-Mail-Routing + Worker: E-Mails programmgesteuert auf Edge verarbeiten