SPF, DKIM und DMARC für Microsoft 365 richtig einrichten

Wer aus einem Microsoft-365-Postfach heraus B2B-Kaltakquise betreibt, stößt bei der Authentifizierung schneller auf Stolperfallen als bei einfacheren Setups: SPF liegt im DNS, DKIM wird im Exchange-Admin-Center pro Domain aktiviert, und CNAME-Einträge müssen exakt im vorgegebenen Format stehen. Für deutsche Vertriebsteams, die Outlook und Exchange gewohnt sind, ist gerade der DKIM-Schritt der häufigste Punkt, an dem die Einrichtung unvollständig bleibt.

Warum Microsoft-365-Setups bei Vertriebsteams besonders oft hakt

Microsoft 365 verteilt die Einrichtung von SPF, DKIM und DMARC auf mehrere Orte: SPF gehört ins DNS des Domain-Providers, DKIM wird im Exchange-Admin-Center aktiviert, und DMARC landet wieder zurück im DNS. Diese Aufteilung ist an sich nicht ungewöhnlich, führt aber in der Praxis häufiger zu halb fertigen Einrichtungen als bei einheitlicheren Systemen, weil die Zuständigkeit oft zwischen IT-Abteilung, Domain-Provider und Vertriebsteam wechselt.

Ein zusätzlicher Punkt, der speziell bei deutschen B2B-Vertriebsteams auftaucht: Viele nutzen Outlook und Exchange für die interne und die Kunden-Kommunikation, verschicken Kaltakquise-Kampagnen aber über ein separates Cold-Email- oder CRM-Tool. Bleibt dieses zweite Tool bei der SPF- und DKIM-Einrichtung unberücksichtigt, weil „die IT ja schon SPF für Microsoft 365 eingerichtet hat“, fehlt genau die Versandquelle, die für die eigentliche Kaltakquise zählt.

Hinzu kommt bei Microsoft 365 häufig eine organisatorische Hürde: DNS-Zugriff liegt beim Domain-Provider oder bei einer externen IT-Dienstleistung, während das Exchange-Admin-Center dem internen IT-Verantwortlichen oder einem Microsoft-Partner vorbehalten ist. Ein Vertriebsteam, das eine neue Kaltakquise-Subdomain aufsetzen will, ist damit auf zwei unterschiedliche Zuständigkeiten angewiesen, die selten dieselbe Person betreffen — ein Grund, warum sich Einrichtungen über Wochen hinziehen, obwohl die technischen Schritte selbst wenig Zeit kosten.

SPF-Eintrag für Microsoft 365 im DNS setzen

Der Grundbaustein für Microsoft 365 lautet include:spf.protection.outlook.com. Legen Sie diesen als TXT-Eintrag im DNS der Domain oder Subdomain an, über die versendet wird — nicht im Microsoft-Admin-Center, das für SPF keine eigene Eingabemaske bietet, sondern lediglich bei der Domain-Verifizierung darauf verweist.

Versendet ein Vertriebsteam Kaltakquise zusätzlich über ein separates Tool, muss dessen Quelle in denselben Eintrag als weiterer include ergänzt werden. Zwei getrennte SPF-Einträge funktionieren nicht — DNS liest nur den ersten gefundenen v=spf1-Eintrag, jeder weitere wird ignoriert, was die zweite Versandquelle unautorisiert lässt, ohne dass eine Fehlermeldung erscheint.

Beachten Sie zusätzlich das SPF-eigene Limit von zehn erlaubten DNS-Lookups je Prüfung. Der Baustein include:spf.protection.outlook.com verbraucht davon bereits mehrere, weil er selbst wieder auf weitere Einträge verweist. Wer über die Zeit zusätzliche Tools ergänzt, ohne alte, nicht mehr genutzte Includes zu entfernen, überschreitet dieses Limit irgendwann unbemerkt — die Folge ist ein permafail, bei dem SPF für sämtliche Versandwege als ungültig gilt, unabhängig davon, welcher davon tatsächlich fehlerhaft war.

DKIM im Exchange-Admin-Center aktivieren

Öffnen Sie im Microsoft 365 Admin Center beziehungsweise im Exchange Admin Center den Bereich Mailflow → DKIM, teils auch unter Sicherheit → E-Mail-Authentifizierung zu finden, je nach Lizenz und Oberflächenversion. Wählen Sie die betreffende Domain aus — DKIM ist bei neu hinzugefügten Domains standardmäßig deaktiviert.

Microsoft zeigt daraufhin zwei CNAME-Einträge an, die exakt so ins DNS übernommen werden müssen, üblicherweise im Muster selector1._domainkey und selector2._domainkey, jeweils zeigend auf eine von Microsoft vorgegebene Ziel-Domain. Ein häufiger Fehler ist, nur einen der beiden CNAME-Einträge zu setzen oder Tippfehler im Zielwert zu übernehmen — beide Einträge sind für die Aktivierung zwingend erforderlich.

Erst nachdem beide CNAME-Einträge im DNS gefunden werden, lässt sich der Schalter „DKIM aktivieren“ im Admin-Center erfolgreich umlegen. Versucht man es vorher, meldet Microsoft, dass die CNAME-Einträge nicht existieren, auch wenn sie kurz zuvor gespeichert wurden — hier hilft in der Regel nur abwarten, bis die DNS-Propagation abgeschlossen ist.

Nutzt das Vertriebsteam zusätzlich zu Exchange ein separates Cold-Email-Tool, das nicht über Microsofts Server versendet, deckt die soeben aktivierte DKIM-Signatur diesen zweiten Versandweg nicht ab. Das Tool muss über seine eigene Admin-Oberfläche einen eigenen DKIM-Selector bereitstellen, der wiederum als eigener CNAME-Eintrag ins selbe DNS gehört — technisch unabhängig von den beiden Microsoft-Selectoren, aber in derselben Domain gemeinsam aktiv.

DMARC-Eintrag ergänzen

Wie bei anderen Setups auch ist DMARC bei Microsoft 365 kein Admin-Center-Feature, sondern ein eigener TXT-Eintrag unter _dmarc.ihredomain.de im DNS. Setzen Sie ihn erst, wenn SPF steht und DKIM im Exchange-Admin-Center erfolgreich aktiviert ist, damit die DMARC-Auswertung von Anfang an auf einer vollständigen Basis aufsetzt.

Für den Einstieg genügt eine Beobachtungs-Policy mit p=none, die Berichte sammelt, ohne Zustellungen zu beeinflussen. Das ist bei Microsoft-365-Setups mit parallel genutztem Cold-Email-Tool besonders ratsam, weil sich auf diese Weise beobachten lässt, ob beide Versandwege tatsächlich sauber authentifiziert ankommen, bevor eine strengere Policy in Betracht gezogen wird.

Setzen Sie den Eintrag beim Domain-Provider, nicht im Microsoft 365 Admin Center — auch hier gibt es keine eigene Eingabemaske für DMARC. Achten Sie darauf, dass der Eintrag exakt unter dem _dmarc.-Präfix der Domain liegt, über die tatsächlich versendet wird. Bei einer Kaltakquise-Subdomain bedeutet das einen eigenen DMARC-Eintrag für diese Subdomain, nicht nur einen Eintrag auf der Hauptdomain, der die Subdomain lediglich per Vererbung mitträgt.

Eigene Subdomain trennt Vertriebs-Reputation vom Haupt-Exchange-Postfach

Auch bei Microsoft 365 lässt sich eine dedizierte Subdomain für Kaltakquise als zusätzliche Domain im Microsoft 365 Admin Center hinzufügen, etwa outreach.musterfirma.de neben der bestehenden musterfirma.de. Für jede zusätzliche Domain sind SPF, DKIM und DMARC erneut separat einzurichten, eine automatische Vererbung von der Hauptdomain findet nicht statt.

Für ein Team wie den Vertrieb der Musterfirma GmbH bedeutet das: Interne Kommunikation und Kundenkontakt laufen weiter über das gewohnte Exchange-Postfach auf musterfirma.de, während gezielte Kaltakquise-Kampagnen über ein separat authentifiziertes Postfach auf der Subdomain verschickt werden — mit eigenem Aufwärmverlauf, unabhängig vom täglichen Geschäftsverkehr.

Praktisch läuft das Hinzufügen einer solchen Subdomain im Microsoft 365 Admin Center über den Bereich Einstellungen → Domänen → Domäne hinzufügen. Microsoft verlangt dabei zunächst einen eigenen TXT-Eintrag zur Verifizierung der Inhaberschaft, bevor SPF, DKIM und DMARC für diese Subdomain überhaupt konfigurierbar werden — ein Schritt, der bei der Zeitplanung einer neuen Kaltakquise-Domain gerne vergessen wird und die Einrichtung um einen zusätzlichen DNS-Zyklus verlängert.

Testen, bevor der erste Kampagnen-Batch startet

Verschicken Sie nach Abschluss aller Schritte eine Testmail aus dem Microsoft-365-Postfach an ein externes Konto mit einsehbarem Header-Quelltext, etwa über die Funktion „Nachrichtenquelle anzeigen“ in Outlook oder ein separates Testkonto bei einem anderen Anbieter. Im Authentication-Results-Header sollten spf=pass, dkim=pass mit dem korrekten Microsoft-Selector und dmarc=pass erscheinen.

Schlägt einer der drei Werte fehl, ist die häufigste Ursache entweder ein noch nicht propagierter CNAME-Eintrag für DKIM oder ein SPF-Eintrag, der nur Microsoft 365 abdeckt, während ein zusätzliches Cold-Email-Tool separat versendet. Erst wenn beide Versandwege bei einer echten Testmail sauber durchlaufen, ist die Domain bereit für den ersten realen Kaltakquise-Batch — ein Start mit halb aktivierter Authentifizierung lässt sich in Exchange technisch zwar nicht verhindern, kostet aber unnötig Zustellbarkeit von Anfang an.

Technische Einrichtung ersetzt keine rechtliche Prüfung

Eine über Microsoft 365 sauber authentifizierte Domain sorgt für technische Glaubwürdigkeit, sagt aber nichts über die rechtliche Zulässigkeit einer konkreten Kaltakquise-Kampagne aus. Für B2B-Kaltakquise in Deutschland bleibt die Grundlage eine Abwägung nach DSGVO sowie die Anforderungen aus § 7 UWG zu unerlaubter Werbung — unabhängig von SPF, DKIM und DMARC.

Praktisch bedeutet das: Auch ein technisch einwandfreies Microsoft-365-Setup schützt nicht vor einer Abmahnung, wenn Impressum, Abmeldemöglichkeit oder ein erkennbarer geschäftlicher Bezug zum Angebot in der Nachricht fehlen. Beide Themen — Zustellbarkeit und rechtliche Zulässigkeit — sollten vor dem ersten Kampagnenversand unabhängig voneinander geprüft werden.

Häufige Fragen