E-Mail-Authentifizierung mit SPF, DKIM und DMARC

Worum es geht

SPF ist ein TXT-Eintrag am Domainnamen, der mit v=spf1 beginnt und die zulässigen sendenden Hosts aufzählt, etwa v=spf1 include:mail.example.net -all. RFC 7208 begrenzt die Zahl der Terme, die DNS-Abfragen auslösen (include, a, mx, ptr, exists, redirect), auf zehn pro Prüfung; darüber liefert die Prüfung «permerror». DKIM fügt jeder Nachricht einen DKIM-Signature-Header hinzu; der öffentliche Schlüssel steht unter selektor._domainkey.example.ch, sodass mehrere Dienste mit eigenen Selektoren nebeneinander signieren können. DMARC veröffentlicht unter _dmarc.example.ch eine Richtlinie (p=none, p=quarantine oder p=reject), die greift, wenn weder SPF noch DKIM mit der sichtbaren Absenderdomain übereinstimmen («Alignment»), und nennt mit rua= eine Adresse für zusammengefasste Berichte.

Warum es wichtig ist

Grosse Empfänger knüpfen die Annahme von Post nach verbreiteten Berichten zunehmend an diese Einträge, und Angreifer fälschen ungeschützte Absenderdomains für Phishing. Umgekehrt bricht eine unbedachte DNS-Änderung – ein überschriebener TXT-Eintrag, ein gelöschter Selektor – den Versand still: Die Nachrichten verlassen den Server und werden beim Empfänger abgewiesen oder aussortiert.

So wird es angewendet

• Alle legitimen Versanddienste (eigener Mailserver, Newsletter, Transaktionsmails, CRM) ermitteln und in genau einem SPF-Eintrag zusammenführen; mit ~all beginnen und nach Kontrolle der Berichte auf -all wechseln. Die zehn Abfragen zählen inklusive der include-Ketten der Dienste.
• Bei jedem Dienst DKIM aktivieren und den Selektor-Eintrag veröffentlichen; beim Schlüsselwechsel einen neuen Selektor anlegen statt den alten zu überschreiben, damit unterwegs befindliche Post prüfbar bleibt.
• DMARC mit p=none und Berichtsadresse starten, Berichte einige Wochen auswerten, dann quarantine, schliesslich reject; mit dem Tag sp eine eigene Richtlinie für Subdomains setzen, die nie senden.
• Vor jeder DNS-Umstellung (Anbieterwechsel, neue Website) TXT-, MX- und CAA-Einträge exportieren und nachher vergleichen.

Stolpersteine

Zwei SPF-Einträge am selben Namen sind ungültig, nicht additiv. Weiterleitungen brechen SPF, weil der weiterleitende Server nicht im Eintrag steht; DKIM übersteht sie – deshalb braucht es beides. Mailinglisten, die Betreff oder Fusszeile verändern, brechen damit DKIM-Signaturen. Subdomains erben keinen SPF-Eintrag. Berichte an eine Adresse in einer fremden Domain verlangen dort einen Freigabeeintrag (RFC 7489, «Verifying External Destinations»). DMARC-Berichte sind XML und bleiben ohne Auswertungswerkzeug ungelesen.

~all oder -all unter DMARC

Sobald DMARC mit p=quarantine oder p=reject gilt, bringt der Wechsel von ~all auf -all keinen Gewinn: DMARC unterscheidet nur «SPF pass» von «nicht pass», Softfail und Hardfail führen zum selben Ergebnis, und die Richtlinie p= entscheidet über die Behandlung. -all kostet dagegen weitergeleitete Post, denn Empfänger, die SPF-Hardfail bereits im SMTP-Dialog abweisen, tun das, bevor sie die DKIM-Signatur geprüft haben – dieselbe Signatur, die die Weiterleitung sonst rettet. Empfehlung: ~all dauerhaft für Domains, die senden, und die Schärfe über die DMARC-Richtlinie steuern; v=spf1 -all zusammen mit p=reject nur für Domains und Subdomains, die nie senden.