Was machen SPF, DKIM und DMARC?
Die drei Verfahren ergänzen sich. Sie schützen die Domain in Ihrer Absenderadresse, nicht ähnlich geschriebene Domains.
- SPF (RFC 7208): Ein TXT-Eintrag nennt die Server, die für Ihre Domain senden dürfen. Geprüft wird vor allem die Adresse aus der Zustellung (MAIL FROM), nicht die sichtbare Absenderadresse.
- DKIM (RFC 6376): Der sendende Dienst signiert die Mail, der öffentliche Schlüssel liegt im DNS unter selektor._domainkey.ihredomain.de.
- DMARC (RFC 9989): Der Eintrag verbindet beides mit der sichtbaren Absenderadresse. Eine Mail besteht, wenn SPF oder DKIM besteht und die geprüfte Domain zur sichtbaren Domain passt. Das heißt Alignment. Standard ist relaxed, dieselbe Organisationsdomain genügt also.
Müssen Sie DMARC einrichten?
Eine allgemeine gesetzliche Pflicht habe ich nicht gefunden. Praktisch verlangen es große Empfänger: Google fordert von allen Absendern SPF oder DKIM und von Massenversendern mit mehr als 5.000 Mails am Tag SPF, DKIM und DMARC, wobei p=none genügt. Das BSI verlangt in seiner Technischen Richtlinie TR-03182 von E-Mail-Diensteanbietern SPF, DKIM und eine DMARC-Richtlinie. Sie richtet sich an Anbieter, zeigt aber, wo der Maßstab liegt.
Schritt 1: Alle Absender erfassen
Das ist die wichtigste Arbeit. Alles, was mit Ihrer Domain als Absender verschickt, muss später bestehen, sonst geht echte Post verloren. Für Dienste außerhalb Ihrer direkten Kontrolle empfiehlt Microsoft eine Unterdomäne wie marketing.ihredomain.de. Denken Sie an:
- den Postfachdienst, etwa Microsoft 365 oder Google
- Newsletter und Marketing
- CRM, Rechnungs- und Ticketsoftware
- Website-Formulare und Shop
- Drucker, Scanner und Fachanwendungen, die Mails senden
Schritt 2: SPF setzen
Legen Sie genau einen TXT-Eintrag auf der Domain an. Mehrere SPF-Einträge sind laut RFC 7208 nicht erlaubt und führen zu einem Fehler. Für eine Domain, die nur über Microsoft 365 sendet, lautet er laut Microsoft: v=spf1 include:spf.protection.outlook.com -all
Weitere Dienste ergänzen Sie mit eigenem include. Achten Sie auf die Grenze von zehn DNS-Abfragen, auch verschachtelte include zählen, und ein Überschreiten führt zum Fehler. Am Ende steht -all oder ~all. Microsoft empfiehlt für Microsoft-365-Domains -all, damit DMARC auch Mails ohne DKIM-Signatur erfasst. Nach meiner Prüfliste sind beide in Ordnung. Das Ende ?all ist laut Microsoft für Tests gedacht, und +all erlaubt jedem Server das Senden.
Schritt 3: DKIM aktivieren
Jeder Dienst, der in Ihrem Namen sendet, braucht einen eigenen Schlüssel und muss mit Ihrer Domain signieren, sonst zählt die Signatur für DMARC nicht. In Microsoft 365 müssen Sie das für eigene Domains selbst einrichten: Sie legen zwei CNAME-Einträge für selector1 und selector2 an und schalten die Signatur im Defender-Portal ein. Die genauen Werte zeigt das Portal.
Prüfen Sie das Ergebnis an einer echten Mail in den Kopfzeilen unter Authentication-Results. Ein Schlüssel im DNS allein beweist nicht, dass tatsächlich signiert wird.
Schritt 4: DMARC mit p=none veröffentlichen
Legen Sie einen TXT-Eintrag unter _dmarc.ihredomain.de an: v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.de
Mit p=none schlagen Sie den Empfängern keine Aktion vor, geschützt sind Sie damit also noch nicht. Der Zweck ist die Messung: RFC 9989 beschreibt diesen Start, damit bei SPF und DKIM nichts übersehen bleibt. Empfänger, die das unterstützen, schicken täglich oder öfter Berichte als XML, in der Regel komprimiert, mit Absender-IP, Menge und Prüfergebnis. Liegt die Berichtsadresse in einer anderen Organisationsdomain, etwa bei einem Dienstleister, muss diese das im DNS bestätigen (RFC 9990, Abschnitt 4). Sonst ignorieren die Empfänger die Adresse.
Schritt 5: Berichte auswerten und Lücken schließen
RFC 9989 rät zur maschinellen Auswertung, mit eigenem Werkzeug oder einem Dienst. Sie suchen zwei Dinge: echte Absender, die nicht bestehen, und fremde Quellen, die Ihre Domain missbrauchen. Echte Absender müssen laut RFC 9989 korrigiert sein, bevor Sie die Richtlinie verschärfen. Das kann viele Monate Berichte bedeuten, je nachdem, wie selten manche Systeme senden. Ich plane mindestens einen vollen Monat ein.
Schritt 6: Auf p=quarantine anheben
Sind die echten Absender sauber, ändern Sie den Eintrag: v=DMARC1; p=quarantine; rua=mailto:dmarc@ihredomain.de. Was dann mit Mails ohne Bestehen geschieht, entscheidet der Empfänger, etwa die Einstufung als Spam. Meine Prüfliste wertet p=quarantine mit Berichtsadresse und ohne Testmodus für einen normalen Betrieb als erreichtes Soll.
Manche Anleitungen, auch die von Microsoft, empfehlen Zwischenstufen mit pct. RFC 9989 kennt diesen Tag nicht mehr, unter anderem weil er laut Anhang A.6 meist nicht genau angewendet wurde. Für einen Testlauf gibt es nun t=y: Der Empfänger soll die Richtlinie dann nicht anwenden.
Schritt 7: Entscheiden, ob p=reject passt
Das ist keine Pflichtstufe. RFC 9989 sagt in Abschnitt 7.4, Domains mit Nutzern, die auf Mailinglisten schreiben, sollen kein p=reject veröffentlichen. Wer es trotzdem will, soll die Berichte nutzen und mindestens einen Monat p=none und ebenso lange p=quarantine fahren. Bei p=reject darf sich die Domain nicht allein auf SPF stützen und muss DKIM-Signaturen setzen. Empfänger dürfen Mails nicht allein wegen p=reject ablehnen. Microsoft nennt p=reject dagegen als Ziel für alle Domains. Den Unterschied sollten Sie kennen und bewusst entscheiden.
Anders liegt es bei Domains, die nie Mail senden. Für sie empfiehlt Microsoft SPF mit v=spf1 -all, DMARC mit v=DMARC1; p=reject und keine DKIM-Einträge. Dort gibt es auch keine Nutzer auf Mailinglisten.
Worauf sollten Sie achten?
Diese Punkte lassen sich vorab klären:
- Subdomains: Der DMARC-Eintrag gilt laut Microsoft auch für Subdomains ohne eigenen Eintrag. SPF und DKIM brauchen sie jeweils selbst. Mit sp und np setzen Sie eigene Richtlinien für vorhandene und nicht vorhandene Subdomains.
- Weiterleitungen: Nach einer Weiterleitung schlägt SPF oft fehl, eine DKIM-Signatur bleibt meist gültig. Auch deshalb sollten Sie sich nicht auf SPF allein verlassen.
- Selektoren: Sie lassen sich nicht aufzählen. Findet ein Prüfwerkzeug von außen keinen DKIM-Schlüssel, ist das ein Hinweis und kein Beweis.
- Berichte: Legen Sie fest, wer sie auswertet. Eine Berichtsadresse, die niemand liest, bringt nichts.
Wie prüfen Sie Ihren Stand?
Den Eintrag lesen Sie mit nslookup -type=txt _dmarc.ihredomain.de. Das Ergebnis einer konkreten Mail steht in deren Kopfzeilen unter Authentication-Results. Zur Einordnung: Meine eigene Domain floxa.de steht am 5. November 2026 noch auf p=none. Ich werte zuerst die Berichte aus und hebe danach auf p=quarantine an.