SPF, DKIM und DMARC, erklärt für alle, die Websites betreiben

E-Mail wurde in einer Welt entworfen, in der jeder jedem vertraute. Die Absenderadresse (From) einer Nachricht ist eine Textzeile, die der Absender selbst eintippt; nichts im ursprünglichen Protokoll prüft sie. Drei DNS-Einträge, in den letzten zwanzig Jahren hinzugekommen, lassen den Inhaber einer Domain festlegen, wer in seinem Namen senden darf und was Empfänger mit allem anderen tun sollen. Zusammen machen sie den Unterschied zwischen „jeder kann Ihren Kunden in Ihrem Namen schreiben“ und „niemand kann es“.

Die meisten Domains, die in einem Perimetry-Audit durchfallen, scheitern zuerst hier, und die Behebung kostet nichts außer zehn Minuten in der DNS-Verwaltung.

Warum das in Deutschland auch eine Frage des Stands der Technik ist

Das BSI hat die Anforderungen in zwei Technischen Richtlinien festgehalten: die TR-03182 „E-Mail-Authentifizierung“ für SPF, DKIM und DMARC und die TR-03108 „Sicherer E-Mail-Transport“ für die Verschlüsselung zwischen Mailservern (unter anderem mit DANE und MTA-STS). Sie richten sich an E-Mail-Anbieter, beschreiben aber genau das, was jede Domain veröffentlichen sollte. Im IT-Grundschutz-Kompendium gehört das Thema zum Baustein APP.5.3 „Allgemeiner E-Mail-Client und -Server“.

Für Einrichtungen unter NIS2 verlangt § 30 BSIG Risikomanagementmaßnahmen, die den Stand der Technik einhalten. Eine Domain ohne DMARC-Richtlinie lässt sich schwer als Stand der Technik verteidigen, wenn ein Betrüger in ihrem Namen Rechnungen verschickt. Der Perimetry-Bericht ordnet die Befunde dazu den Anforderungen von NIS2 zu, als Hinweis, nicht als Konformitätsbewertung.

Die drei Einträge in je einem Absatz

SPF (Sender Policy Framework) ist ein TXT-Eintrag auf Ihrer Domain, der die Server auflistet, die für sie senden dürfen: Ihr E-Mail-Anbieter, Ihr Newsletter-Tool, der Transaktionsmail-Dienst Ihrer Website. Ein empfangender Server schaut sich die Adresse an, die sich mit ihm verbunden hat, vergleicht sie mit der Liste und erhält ein Ergebnis: pass, fail, softfail oder neutral.

DKIM (DomainKeys Identified Mail) ist eine Signatur. Ihr sendender Server signiert jede ausgehende Nachricht mit einem privaten Schlüssel; der passende öffentliche Schlüssel steht im DNS unter einem Selektor, zum Beispiel selector1._domainkey.ihre-domain.de. Der Empfänger holt den Schlüssel und prüft, dass die Nachricht nicht verändert wurde und wirklich von einem Server stammt, der Ihren Schlüssel besitzt.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist die Richtlinie, die beide verbindet. Sie sagt: „Wenn eine Nachricht vorgibt, von meiner Domain zu stammen, und weder SPF noch DKIM passend zur Absenderadresse besteht, dann tu Folgendes damit: nichts, in Quarantäne verschieben oder abweisen.“ Sie gibt Empfängern außerdem eine Adresse, an die sie tägliche Berichte senden, sodass Sie sehen, wer in Ihrem Namen sendet.

Ohne DMARC sind SPF und DKIM nur Empfehlungen. Ein Empfänger, der bei einer Nachricht ohne DMARC-Richtlinie einen SPF-Fehler sieht, stellt sie meist trotzdem zu, vielleicht mit etwas höherem Spam-Wert. Mit einer DMARC-Richtlinie p=reject wird dieselbe Nachricht verworfen.

Was schiefgeht, in der Reihenfolge, in der wir es sehen

Gar kein DMARC-Eintrag. Das ist der häufigste Befund auf Domains kleiner Unternehmen. Die Domain kann perfektes SPF und DKIM haben, und trotzdem kann jeder sie fälschen, weil keine Richtlinie Empfängern sagt, wie sie auf die Ergebnisse reagieren sollen.

DMARC mit p=none. Das ist der richtige Ort, um zu beginnen, denn Sie erhalten Berichte, ohne die Zustellung zu beeinflussen. Es ist der falsche Ort, um zu bleiben. Eine Richtlinie p=none schützt nichts; sie beobachtet nur. Viele Domains wurden vor Jahren von einer wohlmeinenden Administratorin auf none gesetzt und nie weiterbewegt.

SPF endet mit ?all oder ~all, wo -all hingehört. Der letzte Mechanismus eines SPF-Eintrags sagt, was mit Absendern geschehen soll, die nicht auf der Liste stehen. -all heißt fail. ~all heißt softfail, was die meisten Empfänger als „zustellen, aber vermerken“ behandeln. ?all heißt neutral: „Ich habe keine Meinung“, was so gut ist wie gar kein SPF. Mit DMARC ist ~all vertretbar, weil DMARC die letzte Entscheidung trifft; ohne DMARC zählt nur -all.

SPF mit mehr als 10 DNS-Abfragen. Jedes include:, a, mx, redirect= und exists: kostet eine DNS-Abfrage, und der Empfänger gibt nach zehn auf. Der Eintrag liefert dann einen dauerhaften Fehler, den DMARC als Scheitern wertet. Das passiert unbemerkt, wenn ein Unternehmen den vierten oder fünften Versanddienst hinzufügt; das include jedes Anbieters kann selbst mehrere Includes enthalten. Perimetry zählt die Abfragen rekursiv und meldet die Summe.

Ein totes include. Ihr SPF nennt noch einen Anbieter, den Sie vor drei Jahren gekündigt haben. Verschwindet dessen Eintrag, liefert Ihrer einen Fehler. Wird der Anbieter übernommen oder vergibt er seine Adressen neu, haben Sie einen Fremden autorisiert.

Fehlendes DKIM. Viele E-Mail-Anbieter schalten DKIM erst auf Anfrage ein, über zwei oder drei CNAME-Einträge, die sie Ihnen nennen. Ohne DKIM bricht eine Weiterleitung SPF (der Server des Weiterleitenden steht nicht auf Ihrer Liste), und die Nachricht scheitert an DMARC.

Die zu veröffentlichenden Einträge

Ersetzen Sie die Beispielnamen. Jede Zeile ist ein eigener DNS-Eintrag.

SPF

Ein TXT-Eintrag auf der Domain selbst, der nur die Dienste nennt, die tatsächlich für Sie senden:

ihre-domain.de.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Faustregeln: ein SPF-Eintrag pro Domain, nie zwei. Entfernen Sie jeden Dienst, den Sie nicht mehr nutzen. Bleiben Sie unter zehn Abfragen; der Perimetry-Bericht zeigt die Zahl. Kommen Sie nicht unter zehn, fragen Sie die Anbieter nach ihren IP-Bereichen und nutzen Sie ip4:-Mechanismen, die keine Abfrage kosten.

Der kostenlose SPF-Generator schreibt diesen Eintrag aus den Diensten, die Sie anhaken, und zählt seine Abfragen; der SPF-Check zeigt, was ein veröffentlichter Eintrag kostet, Include für Include, und erklärt Fehler wie permerror: too many DNS lookups.

DKIM

Ihr E-Mail-Anbieter nennt Ihnen die Einträge. Meist sehen sie so aus:

selector1._domainkey.ihre-domain.de.  CNAME  selector1-ihre-domain-de._domainkey.provider.net.
selector2._domainkey.ihre-domain.de.  CNAME  selector2-ihre-domain-de._domainkey.provider.net.

Schalten Sie dann in der Verwaltung des Anbieters die Signatur ein. Tun Sie dasselbe für jeden Dienst, der in Ihrem Namen sendet: Newsletter, Rechnungsversand, Helpdesk. Jeder hat seinen eigenen Selektor. Schlüssel sollten 2048 Bit lang sein; Perimetry schätzt die Schlüssellänge aus dem veröffentlichten Eintrag und meldet 1024-Bit-Schlüssel.

Den Selektor eines Anbieters finden Sie unter s= im Header DKIM-Signature einer gesendeten Nachricht; den Schlüssel prüfen Sie dann mit dem kostenlosen DKIM-Check.

DMARC

Beginnen Sie im Beobachtungsmodus:

_dmarc.ihre-domain.de.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de; fo=1"

Lesen Sie zwei bis vier Wochen lang die aggregierten Berichte. Jeder legitime Absender sollte als bestanden erscheinen. Beheben Sie die, die scheitern (meist ein vergessener Dienst, der DKIM braucht). Wechseln Sie dann zu quarantine und danach zu reject:

_dmarc.ihre-domain.de.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@ihre-domain.de; sp=reject; adkim=s; aspf=r"

_dmarc.ihre-domain.de.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ihre-domain.de; sp=reject; adkim=s; aspf=s"

sp=reject wendet die Richtlinie auf Subdomains an, die Angreifer bevorzugen, weil niemand auf sie achtet. Die Alignment-Tags adkim und aspf legen fest, wie genau die signierende oder die SPF-Domain zur Absenderdomain passen muss; streng ist besser, sobald alles funktioniert. Der kostenlose DMARC-Generator erstellt diese Einträge Einstellung für Einstellung, und der DMARC-Check liest einen veröffentlichten Eintrag Tag für Tag, einschließlich der Freigabe externer Berichtsadressen.

Domains, die nie E-Mails senden

Eine geparkte Domain, eine Markenvariante, eine Produktdomain nur für eine Website: Sie senden nichts, also können sie alles abweisen. Veröffentlichen Sie alle drei Einträge in ihrer strengsten Form und fügen Sie ein Null-MX hinzu, das der Welt sagt, dass die Domain auch keine E-Mails annimmt:

markenvariante.de.         MX   0 .
markenvariante.de.         TXT  "v=spf1 -all"
_dmarc.markenvariante.de.  TXT  "v=DMARC1; p=reject; sp=reject"
*._domainkey.markenvariante.de.  TXT  "v=DKIM1; p="

Perimetry prüft genau diese Konfiguration auf Domains ohne MX-Einträge und meldet, wenn eine nicht sendende Domain offen bleibt.

Zwei optionale Einträge, die sich lohnen

MTA-STS sagt sendenden Servern, dass Ihre Mailserver TLS unterstützen und dass sie die Zustellung über eine unverschlüsselte Verbindung verweigern sollen. Es besteht aus einem DNS-Eintrag und einer kleinen Richtliniendatei, die per HTTPS unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt ausgeliefert wird. Die TR-03108 des BSI behandelt diesen Transportschutz (zusammen mit DANE, das DNSSEC voraussetzt).

TLS-RPT gibt Absendern eine Adresse, an die sie TLS-Fehler melden:

_smtp._tls.ihre-domain.de.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

Keiner von beiden betrifft Fälschungen, aber beide kosten wenig, und beide erscheinen im Perimetry-Bericht als Befunde mit niedrigem Schweregrad, wenn sie fehlen.

Wie Perimetry diese Einträge liest

Das Audit löst den SPF-Eintrag auf, folgt jedem include und redirect rekursiv, zählt die Abfragen und meldet Syntaxfehler, tote Includes und Schleifen. Es fragt mehr als fünfzig gängige DKIM-Selektoren ab (die von Google, Microsoft, Mailchimp, SendGrid, Postmark, Brevo, Amazon SES und anderen) und schätzt die Schlüssellänge jedes gefundenen. Es zerlegt den DMARC-Eintrag Tag für Tag, prüft, dass Berichtsadressen auf anderen Domains den nötigen Autorisierungseintrag haben, und vergleicht die Richtlinie mit dem tatsächlichen E-Mail-Aufbau der Domain. Der Bericht endet mit den genauen Einträgen für Ihre Situation, nicht mit einer allgemeinen Vorlage.