In vielen Tenants, die ich betreue, kommt das Thema SPF, DKIM und DMARC für Exchange Online spätestens dann auf den Tisch, wenn Google und Yahoo neue Regeln für den Mailversand ankündigen. Zum Jahresanfang war es wieder so weit. Ab Februar 2024 verlangen beide Provider von Massenversendern, dass ihre E-Mails sauber per SPF und DKIM authentifiziert und zusätzlich durch DMARC-Policies abgesichert sind. Admins sollten ihre DNS-Einträge und Konfigurationen deshalb zügig überprüfen. Das sichert die Zustellbarkeit und hilft gleichzeitig gegen Phishing und Spoofing. Wer bisher nur einen SPF-Record mit include:spf.protection.outlook.com gesetzt und sich um den Rest nicht gekümmert hat, kommt um eine vollständige Umsetzung jetzt nicht mehr herum.

SPF und DKIM bilden in Exchange Online die Grundlage der Mailauthentifizierung

SPF, DKIM und DMARC gemeinsam einzusetzen, gehört heute zum Standard für jedes Mailsystem, das ernst genommen werden will. SPF ist in Exchange Online schnell erledigt. Für reine Microsoft-Cloud-Postfächer genügt meist ein TXT-Record im DNS mit v=spf1 include:spf.protection.outlook.com -all. Schwieriger wird es in größeren Tenants oder sobald Drittanbieter wie Newsletter-Tools oder Ticketsysteme ebenfalls Mails im Namen der eigenen Domain verschicken. Dort begegnen mir immer wieder dieselben Fehler: zu viele Includes (Stichwort 10-DNS-Lookup-Limit), nach Migrationsprojekten vergessene Anpassungen oder einfach veraltete Records. Wer an dieser Stelle hängt, findet in diesem Artikel von Microsoft eine gute Grundlage.

Auch DKIM lässt sich in Exchange Online inzwischen erfreulich einfach einrichten. Im Defender-Portal erzeugt man für jede Domain zwei CNAME-Records (selector1 und selector2) und trägt sie im DNS ein. Nach einer kurzen Wartezeit kann man die DKIM-Signierung dann im Portal aktivieren. Trotzdem finde ich in vielen Umgebungen noch Lücken. Mal wurden die CNAMEs nie im DNS angelegt, mal weiß das Team nicht, dass nach einem Domainumzug neue Einträge fällig sind. Oft wird zudem übersehen, dass DMARC ohne aktive DKIM-Signierung nicht richtig funktioniert, weil dann neben SPF die zweite Säule der Authentifizierung fehlt.

DMARC startet mit „none“ und wird schrittweise verschärft

Mit DMARC legt man fest, wie der Empfänger Mails behandeln soll, die bei SPF oder DKIM durchfallen. In der Regel beginnt man mit der Policy „none“, sammelt erst einmal Reports und erkennt so, wo es hakt. Dazu kommt ein weiterer TXT-Record ins DNS, zum Beispiel dieser:

_dmarc.meinedomain.de.    IN   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

Viele Empfänger schicken über die RUA-Reports aggregierte Auswertungen, aus denen hervorgeht, wie sie die eigenen Mails bewerten. Auf „quarantine“ oder „reject“ sollte man erst dann Schritt für Schritt umstellen, wenn alle legitimen Absender sauber authentifiziert sind. Wie das abläuft, erklärt Microsoft verständlich in seiner Anleitung zur DMARC-Konfiguration. Wer sofort „reject“ einstellt, muss damit rechnen, dass legitime Mails verloren gehen, weil irgendwo noch ein Tickettool mit falscher Absenderadresse läuft.

Drittanbieter sorgen für die meisten Stolperfallen

Knifflig wird es häufig durch Lösungen von Drittanbietern. Newsletter-Tools, Buchungssysteme oder Helpdesks verschicken ihre Mails oft mit der eigenen Domain als Absender, nutzen dafür aber fremde Server. Solche Systeme muss man entweder in den SPF-Record aufnehmen, ohne das Lookup-Limit zu überschreiten, oder sie bekommen besser eigene DKIM-Keys und signieren selbst. Hier geht der Überblick schnell verloren. Viele Verantwortliche wissen gar nicht genau, welche Systeme überhaupt Mails im Namen der Organisation versenden.

Ich empfehle, einmal im Quartal alle Systeme zu prüfen, die mit der eigenen Domain Mails verschicken, und die DKIM- und SPF-Konfiguration einschließlich der DNS-Records zu dokumentieren. So bleiben unangenehme Überraschungen aus, etwa nach dem Wechsel eines Tools oder Providers.

Besonders häufig stolpern Teams über diese Punkte:

  • SPF-DNS-Lookup-Limit erreicht (keine weiteren Includes möglich)
  • DKIM-Einträge fehlen oder sind falsch
  • DMARC-Policy „reject“ aktiviert, aber Drittanbieter nicht eingebunden

In Projekten setze ich mich deshalb gern dafür ein, das Thema fest in die Change- und Dokumentationsprozesse aufzunehmen.

Eine Grafik zeigt das technische Zusammenspiel der Prüfungen

Wenn mehrere Systeme und Authentifizierungsverfahren zusammenwirken, hilft eine schlichte Übersicht. Die folgende Mermaid-Grafik zeigt, auf welchem Weg eine Mail von Exchange Online (und gegebenenfalls von Drittsystemen) zum Empfänger kommt und welche Prüfungen sie dabei durchläuft:

flowchart LR
    MailClient["Mailversender (Exchange Online)"] --> MTASend["SMTP-Server (Microsoft)"]
    ThirdPartySender["Drittanbieter (z.B. Newsletter)"] --> ExternalMTA["SMTP-Server (Drittanbieter)"]
    MTASend --> RecipientMTA["Empfänger-Mailserver"]
    ExternalMTA --> RecipientMTA
    RecipientMTA --> SPFCheck["SPF-Check"]
    RecipientMTA --> DKIMCheck["DKIM-Check"]
    RecipientMTA --> DMARCCheck["DMARC-Check"]
    SPFCheck --> Decision["Entscheidung (Annehmen, Quarantäne, Ablehnen)"]
    DKIMCheck --> Decision
    DMARCCheck --> Decision

Abbildung: SPF-, DKIM- und DMARC-Prüfungen beim Empfang einer Mail im Überblick

An der Grafik erkennt man schnell, wo Abhängigkeiten bestehen und wo etwas brechen kann, gerade wenn nicht alle Mails aus Exchange Online kommen.

Gute Prozesse und etwas Geduld wiegen so viel wie saubere DNS-Einträge

Ohne die richtige Technik geht es nicht, im Alltag entscheiden aber oft Prozesse und das Bewusstsein im Team. Wer regelmäßig nachsieht, welche Systeme im Namen der eigenen Domain E-Mails verschicken und wie SPF, DKIM und DMARC sie absichern, bleibt von plötzlich blockierten Mails und den dazugehörigen Support-Tickets weitgehend verschont. Vor allem im Zusammenspiel mit Conditional Access und weiteren Sicherheitsmechanismen (siehe /blog/conditional-access-entra-id-best-practices) ist Mailauthentifizierung keine Aufgabe, die man einmal erledigt und dann vergisst. Ich halte es für klüger, mit DMARC und DKIM behutsam anzufangen und die Fehlerberichte genau zu lesen, statt vorschnell auf „reject“ umzustellen. So bleiben die Postfächer auch 2024 sauber und erreichbar.