DKIM

DKIM (DomainKeys Identified Mail) ist ein Verfahren zur E-Mail-Authentifizierung, bei dem der sendende Mailserver jede ausgehende Nachricht mit einer digitalen Signatur versieht. Den passenden öffentlichen Schlüssel veröffentlichen Sie als DKIM-Eintrag im DNS (Domain Name System), damit jeder Empfänger prüfen kann, ob die Mail wirklich von Ihrer Domain signiert und unterwegs nicht verändert wurde. Zusammen mit SPF (Sender Policy Framework) und DMARC, das festlegt, was mit nicht bestätigten Mails geschieht, bildet DKIM die Grundlage dafür, dass Empfänger Ihre Mails als echt erkennen und Fälschungen Ihrer Absenderdomain abweisen können.

Wie funktioniert DKIM?

Der sendende Server bildet mit einem privaten Schlüssel, den nur er kennt, aus wichtigen Kopfzeilen der Mail (etwa Absender, Betreff und Datum) und aus dem Mailtext eine Signatur. Sie steht anschließend in der Kopfzeile „DKIM-Signature“:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=beispiel.de; s=selector1; h=From:Date:Subject:Message-ID;
 bh=…; b=…

Entscheidend sind zwei Angaben: d= nennt die Domain, die signiert hat, s= den Selector. Daraus setzt der empfangende Server den Namen des DNS-Eintrags zusammen, hier selector1._domainkey.beispiel.de, und holt sich dort den öffentlichen Schlüssel. Passt die Signatur, lautet das Ergebnis dkim=pass. Wurde ein signierter Teil der Mail nachträglich verändert, schlägt die Prüfung fehl.

Was ist ein DKIM-Selector?

Ein Selector (deutsch auch Selektor) ist der Name eines einzelnen Schlüssels. Weil eine Domain mehrere davon veröffentlichen kann, können verschiedene Systeme mit eigenen Schlüsseln für sie signieren, und ein neuer Schlüssel kann bereitliegen, bevor er den alten ablöst.

Warum ist DKIM für Unternehmen wichtig?

DKIM ist eine wichtige Voraussetzung für eine wirksame DMARC-Richtlinie. DMARC verlangt, dass SPF oder DKIM besteht und zur sichtbaren Absenderdomain passt. Zwei Gründe sprechen für DKIM zusätzlich zu SPF:

• Weiterleitungen: Leitet ein Empfänger Ihre Mail weiter, liefert ein Server sie ein, der nicht in Ihrem SPF-Eintrag steht, und SPF scheitert in der Regel. Die DKIM-Signatur reist dagegen mit der Nachricht.
• Anforderungen großer Postfachanbieter: Google, Yahoo und Outlook.com verlangen von Absendern mit großem Mailaufkommen SPF und DKIM. Schwellenwerte und Fristen stehen bei den Anforderungen großer Postfachanbieter im Eintrag DMARC.

Wichtig für Microsoft 365: Mails eigener Domains wie beispiel.de signiert Microsoft 365 laut Dokumentation erst, wenn Sie DKIM für diese Domain einrichten. Automatisch signiert werden nur Mails der onmicrosoft.com-Domain. Für DMARC muss die Signatur aber von der Domain aus der Absenderadresse stammen.

DKIM in Microsoft 365

Microsoft 365 erzeugt für jede eigene Domain, für die Sie DKIM einschalten, zwei Schlüsselpaare und verwahrt die privaten Schlüssel selbst. In Ihrer DNS-Zone legen Sie zwei CNAME-Records an, die auf die öffentlichen Schlüssel bei Microsoft verweisen. Einen DKIM-Record als TXT-Eintrag mit eigenem Schlüssel unterstützt Microsoft 365 nicht. Im Beispiel heißt die Domain beispiel.de und der Tenant, also die Microsoft-365-Umgebung, beispiel.onmicrosoft.com (je Eintrag Hostname und Typ, darunter das Ziel):

Neuere Domains (Format seit Mai 2025):
selector1._domainkey  CNAME
 selector1-beispiel-de._domainkey.beispiel.n-v1.dkim.mail.microsoft
selector2._domainkey  CNAME
 selector2-beispiel-de._domainkey.beispiel.n-v1.dkim.mail.microsoft

Bestehende Domains (bisheriges Format):
selector1._domainkey  CNAME
 selector1-beispiel-de._domainkey.beispiel.onmicrosoft.com
selector2._domainkey  CNAME
 selector2-beispiel-de._domainkey.beispiel.onmicrosoft.com

Neu hinzugefügte eigene Domains erhalten laut Microsoft seit Mai 2025 das neue Format, ältere behalten das bisherige. Für denselben Selector gilt nur eines der beiden. Den Buchstaben im neuen Format (im Beispiel n) vergibt Microsoft. Kopieren Sie die Werte deshalb aus dem Defender-Portal, statt sie selbst zusammenzusetzen, und setzen Sie die TTL (die Zeit, die andere Server den Eintrag zwischenspeichern) auf mindestens 3600 Sekunden.

DKIM im Microsoft Defender-Portal aktivieren

1. Öffnen Sie im Defender-Portal (security.microsoft.com) unter Email & collaboration > Policies & rules > Threat policies > Email authentication settings die Registerkarte DKIM.
2. Legen Sie in der Zeile Ihrer Domain den Schalter um. Microsoft meldet daraufhin einen Fehler mit den benötigten Werten und setzt den Status auf CnameMissing. Übersichtlicher stehen die Werte in der Detailansicht der Domain unter „Publish CNAMEs“.
3. Legen Sie beide CNAME-Einträge bei Ihrem DNS-Anbieter an.
4. Warten Sie einige Minuten, bis Microsoft die Einträge erkennt. Aktivieren Sie dann in der Detailansicht „Sign messages for this domain with DKIM signatures“. In der Übersicht lautet der Status danach Valid.

Schlüssellänge und Schlüsselwechsel

Der Standard RFC 8301 verlangt für Schlüssel nach dem üblichen Verfahren RSA mindestens 1024 Bit und empfiehlt 2048 Bit. Für das Anlegen per PowerShell nennt Microsoft 1024 Bit als Voreinstellung. Welche Länge Ihre Schlüssel haben und wie Sie auf 2048 Bit umstellen, zeigen zwei Befehle in der Kommandozeile Exchange Online PowerShell:

# Schlüssellänge beider Selectoren anzeigen
Get-DkimSigningConfig -Identity beispiel.de |
  Format-List Selector1KeySize,Selector2KeySize

# Schlüssel wechseln (Rotation) und auf 2048 Bit umstellen
Rotate-DkimSigningConfig -Identity beispiel.de -KeySize 2048

Der neue Schlüssel signiert erst nach vier Tagen (96 Stunden), bis dahin ist keine weitere Rotation möglich. Ohne Änderung der Länge rotieren Sie auch im Defender-Portal über „Rotate DKIM keys“. Die größere Länge gilt zunächst nur für den Selector, der als Nächstes aktiv wird, erst nach einer zweiten Rotation für beide. Deshalb braucht Microsoft 365 immer beide CNAME-Einträge: Aktiv ist stets nur ein Selector, der zweite steht für den Wechsel bereit.

Newsletter-Dienste und andere Drittanbieter

Mails von Newsletter-Diensten, CRM-Systemen (Kundenverwaltung) oder Ticketsystemen, die im Namen Ihrer Domain über ihre eigenen Server versenden, signiert Exchange Online nicht. Diese Dienste brauchen eigene DKIM-Einträge mit eigenem Selector, je nach Anbieter als TXT- oder CNAME-Eintrag, neben selector1 und selector2. Für DMARC zählt die Signatur nur, wenn der Dienst mit Ihrer Domain oder einer Subdomain davon signiert. Für Dienste, die Sie nicht selbst kontrollieren, empfiehlt Microsoft eine eigene Subdomain wie marketing.beispiel.de.

Typische Fehler bei DKIM

• Doppelte Domain im Hostnamen: Viele DNS-Anbieter hängen den Domainnamen selbst an. Geben Sie dort den vollen Namen ein, endet der Eintrag auf beispiel.de.beispiel.de. Richtig ist nur selector1._domainkey.
• Nur ein Eintrag: Fehlt selector2, scheitert die spätere Rotation.
• TXT statt CNAME: Der Status bleibt CnameMissing.
• Ziel selbst zusammengesetzt: Punkte statt Bindestriche, ein falscher Tenant-Name oder der fehlende Buchstabe des neuen Formats machen den Eintrag unbrauchbar.
• Punkt am Ende des Ziels: Manche DNS-Anbieter verlangen ihn, andere setzen ihn selbst. Fehlt er oder steht er doppelt, findet Microsoft den Eintrag nicht.
• TTL unter 3600 Sekunden: Laut Microsoft drohen Zeitüberschreitungen und sporadische Fehler wie dkim=temperror.
• Cloudflare-Proxy aktiv: Die DKIM-Einträge müssen auf „DNS only“ stehen. Mit eingeschaltetem Proxy (Umleitung über Cloudflare-Server) liefert das DNS nicht das Ziel bei Microsoft.
• DKIM für Parkdomains: Domains, die nie Mails versenden, bekommen keine DKIM-Einträge. Ohne öffentlichen Schlüssel besteht keine gefälschte Mail dieser Domain die Prüfung.

Praxis-Tipp: Senden Sie nach der Aktivierung eine Testmail an ein externes Postfach, etwa bei Gmail oder Outlook.com, denn innerhalb derselben Organisation setzt Microsoft 365 keine DKIM-Signatur. In den Kopfzeilen der Mail sollte bei den Prüfergebnissen dkim=pass stehen, dazu Ihre Domain, je nach Empfänger als header.d=beispiel.de oder header.i=@beispiel.de. Fehlt die Signatur oder nennt sie eine andere Domain, signiert Microsoft 365 noch nicht mit Ihrer.

Typische Fragen zu DKIM

Reicht DKIM allein gegen gefälschte Absender?

Nein. DKIM belegt nur, welche Domain eine Mail signiert hat und dass sie unverändert ist. Was mit Mails geschieht, die weder DKIM noch SPF passend zu Ihrer Domain bestehen, legt erst die DMARC-Richtlinie fest. Ähnlich aussehende Domains wie beispie1.de erkennt keines der drei Verfahren, mehr dazu unter E-Mail-Spoofing.

Übersteht DKIM eine Weiterleitung?

In der Regel ja, solange niemand die signierten Teile verändert. Fügt ein Verteiler oder ein zwischengeschalteter Mailfilter (Gateway) etwa einen Hinweistext ein, wird die Signatur ungültig. Dafür gibt es ARC (Authenticated Received Chain): Ein vertrauenswürdiger Zwischenserver bewahrt damit die ursprünglichen Prüfergebnisse.

Brauchen Subdomains eigene DKIM-Einträge?

In Microsoft 365 ja. Jede Subdomain, die Mails versendet, etwa marketing.beispiel.de, braucht dort eine eigene DKIM-Einrichtung mit eigenen CNAME-Einträgen. Die DMARC-Richtlinie der Hauptdomain erben Subdomains automatisch, den DKIM-Schlüssel nicht.

DKIM mit CodeKlar einrichten

Neben Microsoft 365 senden oft weitere Systeme im Namen der Domain. Sind sie nicht passend eingerichtet, würden ihre Mails bei einer strengen DMARC-Richtlinie abgewiesen. Wir richten die Einträge für Microsoft 365 deshalb sauber und vollständig ein:

• Bestandsaufnahme aller Systeme, die im Namen Ihrer Domain Mails versenden
• SPF-Eintrag bereinigen
• DKIM für Ihre Domains aktivieren
• DMARC stufenweise von p=none bis p=reject einführen

Danach übernehmen wir das DMARC-Tracking: Wir werten die DMARC-Reports laufend aus, finden vergessene Versender, deren Mails noch nicht passend signiert sind, und melden Ihnen Auffälligkeiten. Das gehört zu unserer Arbeit rund um Exchange Online und Microsoft 365 Security und Compliance, auch bei einem Umzug wie dem Wechsel von IONOS zu Exchange Online. Ob für Ihre Domain bereits DKIM-Einträge veröffentlicht sind, zeigt Ihnen vorab der kostenlose Microsoft 365 DNS-Checker.