E-Mail-Sicherheit: SPF, DKIM und DMARC in fünf Schritten

SPF allein sagt nichts über die sichtbare Absenderadresse (RFC 7208, Abschnitt 11.2). Erst DMARC verknüpft sie: Eine Nachricht besteht DMARC, wenn mindestens eine per SPF oder DKIM bestätigte Domain zur Absenderdomain passt (RFC 9989, Abschnitt 5.3.5).

Erfassen Sie jeden Dienst, der E-Mails mit Ihrer Domain als Absender verschickt. Jeder legitime Absender braucht später ein bestandenes SPF oder DKIM mit passender Domain; Lücken müssen geschlossen sein, bevor Sie eine strenge Richtlinie veröffentlichen (RFC 9989, Abschnitt 5.1.6).

• Eigener Mailserver oder Microsoft 365 bzw. Exchange Online
• Newsletter- und Marketingdienste
• CRM, Ticketsystem, Webshop und Buchhaltung (Rechnungsversand)
• Geräte und Anwendungen mit SMTP-Versand, etwa Scanner, Monitoring und Webformulare
• Dienstleister, die in Ihrem Namen senden
• Domains und Subdomains, die gar keine E-Mails versenden

; Microsoft 365 und ein eigener Server (192.0.2.25 ist eine Beispieladresse)
example.com.      IN TXT "v=spf1 ip4:192.0.2.25 include:spf.protection.outlook.com -all"

; Name, unter dem keine E-Mails versendet werden
www.example.com.  IN TXT "v=spf1 -all"

• Pro Domain genau ein SPF-Eintrag: Mehrere Einträge mit v=spf1 ergeben einen permanenten Fehler (permerror, RFC 7208, Abschnitt 4.5).
• Höchstens 10 DNS-Abfragen durch include, a, mx, ptr, exists und redirect während der ganzen Prüfung, sonst permerror (Abschnitt 4.6.4). Die Einträge eingebundener Dienstleister zählen mit.
• ptr nicht verwenden (Abschnitt 5.5).
• -all (fail) erklärt nicht genannte Server ausdrücklich für unberechtigt, ~all (softfail) ist nur eine schwache Aussage; allein wegen softfail sollen Empfänger nicht ablehnen (Abschnitte 2.6.4, 2.6.5 und 8.5).
• Namen ohne E-Mail-Versand veröffentlichen v=spf1 -all (Abschnitt 10.1.2).
• Ein TXT-String fasst höchstens 255 Zeichen. Längere Einträge werden auf mehrere Strings verteilt, die der Empfänger ohne Leerzeichen zusammensetzt (Abschnitt 3.3).

Jeder Absender signiert mit einem eigenen Schlüssel. Den öffentlichen Schlüssel veröffentlichen Sie als TXT-Eintrag unter <selector>._domainkey.<domain>; Selektor (s=) und Domain (d=) stehen in der Signatur jeder Nachricht (RFC 6376, Abschnitte 3.5 und 3.6.2.1).

mail2026._domainkey.example.com.  IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

• Signieren nur mit rsa-sha256; rsa-sha1 darf weder zum Signieren noch zum Prüfen verwendet werden (RFC 8301, Abschnitt 3.1).
• Schlüssel mit mindestens 1024 Bit, empfohlen sind 2048 Bit (RFC 8301, Abschnitt 3.2).
• Microsoft 365: DKIM wird über zwei CNAME-Einträge selector1._domainkey und selector2._domainkey eingerichtet; die genauen Ziele zeigt Get-DkimSigningConfig. Beim Anlegen per PowerShell sind 1024 Bit voreingestellt; Rotate-DkimSigningConfig -KeySize 2048 stellt auf 2048 Bit um.
• DKIM-Signaturen überstehen Weiterleitungen meist, SPF nicht. Wer p=reject veröffentlicht, darf sich deshalb nicht allein auf SPF verlassen und muss gültig mit DKIM signieren (RFC 9989, Abschnitt 7.4).

_dmarc.example.com.  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.com"

• p=none äußert keine Präferenz für den Umgang mit Fehlschlägen (Monitoring Mode). Mit rua erhalten Sie aggregierte Berichte über alle Server, die mit Ihrer Domain senden (RFC 9989, Abschnitte 5.1.4 und 5.1.5).
• Die Berichte sind für die maschinelle Auswertung gedacht; nutzen Sie ein Auswertungswerkzeug oder einen Dienst (Abschnitt 5.1.5).
• Liegt das Berichtspostfach in einer fremden Domain, muss diese zustimmen, zum Beispiel mit einem TXT-Eintrag example.com._report._dmarc.example.net mit dem Inhalt v=DMARC1 (RFC 9990).
• Fehlerberichte (ruf) enthalten Inhalte einzelner Nachrichten; die meisten Empfänger versenden sie aus Datenschutzgründen nicht (RFC 9989, Abschnitt 10.2). Aggregierte Berichte bleiben das empfohlene Mittel (RFC 9991).
• Jeder legitime Absender ohne passendes SPF oder DKIM wird nachgebessert, bevor eine strenge Richtlinie gilt (RFC 9989, Abschnitt 5.1.6).

• t=y kennzeichnet eine Richtlinie im Test: Empfänger wenden eine Stufe weniger an, bei p=reject also nur quarantine (RFC 9989, Tag t). Den früheren Tag pct gibt es seit RFC 9989 nicht mehr; ältere Anleitungen, auch von Microsoft, nennen ihn noch.
• Subdomains: sp gilt für bestehende Subdomains, np für nicht existierende; fehlen beide, gilt p (RFC 9989, Tags sp und np).
• Mailinglisten: Domains, deren Nutzer an Mailinglisten im Internet schreiben, sollen laut RFC 9989 kein p=reject veröffentlichen; wer es trotzdem tut, soll die Nutzer darauf hinweisen, dass die Teilnahme an Mailinglisten beeinträchtigt sein kann (Abschnitt 7.4).

parked.example.com.         IN TXT "v=spf1 -all"
_dmarc.parked.example.com.  IN TXT "v=DMARC1; p=reject;"
parked.example.com.         IN MX  0 .

Der Null-MX-Eintrag MX 0 . sagt, dass die Domain keine E-Mails annimmt; daneben darf es keinen anderen MX-Eintrag geben, und Domains, die als Absender genutzt werden, sollen ihn nicht veröffentlichen (RFC 7505). Für ungenutzte Domains empfiehlt Microsoft DMARC-Einträge, nach denen nie E-Mails von ihnen kommen dürfen, und keine DKIM-Einträge.

• Alle Absender sind erfasst, auch externe Dienste und Geräte.
• Genau ein SPF-Eintrag, höchstens 10 DNS-Abfragen, Abschluss mit -all oder ~all.
• DKIM für jeden Absender mit rsa-sha256 und 2048-Bit-Schlüssel.
• DMARC mit p=none und rua; die Berichte werden ausgewertet.
• Alle legitimen Absender bestehen DMARC mit passender Domain.
• p=quarantine, dann p=reject; Mailinglisten sind berücksichtigt.
• Domains ohne E-Mail-Verkehr sind mit SPF, DMARC und Null-MX abgesichert.