DKIM einrichten: Anleitung für eigene Domains

DKIM einzurichten ist ein wichtiger Bestandteil einer zuverlässigen Versandkonfiguration für eigene Domains. Fehlende, ungültige oder abgeschnittene Schlüssel sowie eine unpassende Signaturdomain können Authentifizierung und Posteingangsplatzierung beeinträchtigen. Dieser Leitfaden beschreibt den praktischen Ablauf: Schlüssel erzeugen, DNS-Eintrag veröffentlichen, per Kommandozeile prüfen und Alignment-Fehler erkennen, die DMARC trotz grüner Statusanzeige scheitern lassen können.

Für die vollständige Grundkonfiguration mit MX, SPF, Postfächern und Mailclients beginnen Sie mit E-Mail mit eigener Domain erstellen. Wenn Sie zunächst eine Plattform auswählen, hilft der Überblick zur Geschäftsmail.

Die häufigsten DKIM-Probleme entstehen nicht durch Kryptografie, sondern durch Kopierfehler im DNS, doppelt angehängte Domainnamen, beschädigte 2048-Bit-Schlüssel oder einen E-Mail-Dienstleister, der mit seiner eigenen statt Ihrer Domain signiert. Die Suche an der falschen Stelle kostet Zeit. Ein wiederholbarer Ablauf hilft.

Was die DKIM-Einrichtung tatsächlich bewirkt

Bei der DKIM-Einrichtung veröffentlichen Sie einen öffentlichen Schlüssel im DNS. Ihr Mailserver signiert Nachrichten mit dem zugehörigen privaten Schlüssel. Empfangsserver prüfen die Signatur und damit die Verantwortung der Signaturdomain sowie die Integrität der signierten Header und des erfassten Nachrichtentextes.

DKIM nutzt asymmetrische Kryptografie. Das sendende System hält den privaten Schlüssel, DNS stellt den öffentlichen bereit. Eine ausgehende Nachricht erhält den Header DKIM-Signature mit Signaturdomain (d=) und Selektor (s=). Der Empfangsserver fragt den Selektor im DNS ab und prüft die Signatur anhand der Nachricht. Das Verfahren ist in RFC 6376 definiert.

Seit Februar 2024 gelten bei Google strengere Anforderungen für Massenversender. Google verlangt für diese Absender SPF und DKIM; mindestens eines muss zur Domain im sichtbaren From-Header passen, damit DMARC-Alignment erfüllt ist. Den aktuellen Wortlaut finden Sie in Googles FAQ zu den Absenderrichtlinien.

Eine technisch gültige Signatur allein genügt also nicht für jeden Zweck. Fehlerhaftes oder nicht passendes DKIM kann weiterhin mit DMARC-Problemen und schlechter Posteingangsplatzierung verbunden sein.

Vor der DNS-Änderung: das signierende System bestimmen

Eine gute DKIM-Einrichtung beginnt damit, das tatsächliche signierende System zu bestimmen. Gerade bei Migrationen, geänderter Weiterleitung oder Anbieterwechseln wird das leicht übersehen. Wo Sie DKIM-Einträge erzeugen oder abrufen, hängt vollständig vom Versandweg ab.

Klären Sie zuerst: Wer versendet ausgehende Nachrichten dieser Domain?

1. Bei Google Workspace erzeugen Sie den DKIM-Schlüssel in Google Admin.
2. Bei Microsoft 365 aktivieren Sie DKIM dort.
3. Bei SendGrid, Mailgun oder Amazon SES authentifizieren Sie die Domain beim jeweiligen Anbieter.
4. Bei verwaltetem TrekMail-SMTP verwenden Sie die in TrekMail angezeigten DKIM-Werte.
5. Verwaltet TrekMail die Postfächer, während externes SMTP sendet, folgen Sie dessen Signaturanleitung und konfigurieren Sie gegebenenfalls SMTP in TrekMail.

TrekMail beschreibt beide Wege. Nano verwendet BYO SMTP; kostenpflichtige Tarife können verwaltetes SMTP nutzen. Die Dokumentation zu Bring Your Own SMTP zeigt Beispiele für SES, SendGrid und Mailgun. Laut TrekMails Fehlerbehebung signiert verwaltetes SMTP mit dem DKIM-Schlüssel Ihrer Domain. Das kann DMARC bei Weiterleitungen und Relays unterstützen, sofern die Signatur gültig und ausgerichtet bleibt. Prüfen Sie die aktuellen Tarifleistungen.

Beispiel: Ihr Postfach liegt bei TrekMail, ausgehende Nachrichten laufen aber über SendGrid. Dann muss SendGrid signieren. TrekMail kann das Postfach speichern, richtet die DKIM-Signierung bei SendGrid dadurch jedoch nicht automatisch ein.

Die erste Grundregel lautet deshalb: Erzeugen Sie die Schlüssel im System, das tatsächlich signiert. Anderswo erzeugte Schlüssel können als DNS-Eintrag vorhanden sein, ohne für den Versand genutzt zu werden.

DKIM-Eintragstypen: TXT oder CNAME

Meist veröffentlichen Sie für DKIM einen TXT-Eintrag mit öffentlichem Schlüssel. Einige Anbieter verlangen stattdessen einen oder mehrere CNAME-Einträge auf ihre gehosteten Schlüssel. Beide Verfahren sind möglich. Entscheidend ist, exakt die Angaben des sendenden Anbieters zu übernehmen.

Klassisches DKIM verwendet einen TXT-Eintrag unter:

selector._domainkey.example.com

Der Wert sieht etwa so aus:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Verwaltete Dienste nutzen häufig CNAME, um Schlüsselrotationen ohne erneute DNS-Änderung durch den Kunden durchführen zu können. TXT gibt Ihnen direkte Kontrolle, bedeutet aber auch, dass Sie notwendige Aktualisierungen selbst verantworten.

Eine typische Falle ist das Host-Feld. Bei der Domain example.com und dem Selektor k1 lautet der Host häufig:

k1._domainkey

Nicht:

k1._domainkey.example.com

Viele DNS-Panels hängen die Hauptdomain automatisch an. Geben Sie dort den vollständigen Namen ein, kann k1._domainkey.example.com.example.com entstehen. Der Eintrag liegt dann nicht an der Stelle, an der Empfangsserver ihn suchen.

Als TrekMail-Referenz dienen die erforderlichen DNS-Einträge. Dort wird auch erläutert, dass manche DNS-Anbieter DKIM-TXT-Werte in mehrere Teile in Anführungszeichen aufgeteilt benötigen.

DKIM Schritt für Schritt im DNS einrichten

Der praktische Ablauf: Selektor abrufen, Eintrag veröffentlichen, DNS-Aktualisierung abwarten, die genaue Antwort prüfen und bei Bedarf die Signierung beim Anbieter aktivieren. Ohne Verifikation bleibt die Einrichtung unbestätigt.

Nutzen Sie diesen Ablauf:

1. Beim Versandanbieter den DKIM-Eintrag erzeugen oder anzeigen lassen.
2. Den Selektor exakt kopieren. Nur umbenennen, wenn der Anbieter dies unterstützt.
3. Den DNS-Eintrag unter selector._domainkey erstellen.
4. Den vollständigen TXT-Wert oder das CNAME-Ziel unverändert einfügen.
5. TTL auf 3600 setzen, sofern keine anderen Anforderungen bestehen.
6. Die DNS-Aktualisierung abwarten.
7. Vor dem produktiven Versand mit dig oder nslookup prüfen.
8. Die Signierung beim Anbieter aktivieren, falls ein abschließender Schalter vorhanden ist.

Beispiel mit TXT:

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Beispiel mit CNAME:

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

DNS-Änderungen können rasch sichtbar werden, aber nicht sofort überall. TrekMails Fehlerbehebung nennt etwa 5 bis 15 Minuten als häufigen Zeitraum, nicht als Zusage. Bleibt der Status unverändert, prüfen Sie Formatierung, doppelte Einträge und Hostnamen sowie TTL und zwischengespeicherte Antworten.

DKIM und das Problem mit 2048-Bit-Schlüsseln

Für moderne DKIM-Konfigurationen sind 2048-Bit-RSA-Schlüssel sinnvoll, wenn Versand- und DNS-Anbieter sie unterstützen. Sie bieten eine höhere kryptografische Stärke, sind jedoch länger. Ältere DNS-Panels können damit Probleme haben. Ein abgeschnittener Schlüssel ist besonders irreführend: Der Eintrag erscheint vorhanden, die Prüfung schlägt aber fehl.

Googles dokumentierte Empfehlung lautet ebenfalls 2048 Bit, sofern unterstützt, mit 1024 Bit als Rückfalloption für Hosts, die längere Einträge nicht verarbeiten können. Oft ist nicht DNS selbst das Problem, sondern seine Verwaltungsoberfläche.

Fehler bei einer 2048-Bit-DKIM-Konfiguration sehen häufig so aus:

1. Das Panel kürzt den Wert ohne Hinweis.
2. Es verlangt getrennte Zeichenketten in Anführungszeichen, ohne dies zu erklären.
3. Es fügt Zeilenumbrüche in den Base64-Schlüssel ein.
4. Es maskiert Zeichen anders als vom Anbieter erwartet.

Benötigt Ihr DNS-Anbieter getrennte Zeichenketten, veröffentlichen Sie den Wert so:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

Der Empfänger setzt die Teile zusammen. Das ist vorgesehen. Zusätzliche Leerzeichen im eigentlichen Schlüsselmaterial dagegen können die Signaturprüfung verhindern. Schon ein falsches Zeichen kann die Einrichtung unbrauchbar machen.

Bei vielen Domains wird daraus spürbarer Betriebsaufwand. Ein Registrar verarbeitet lange TXT-Werte korrekt, ein anderer nicht, ein weiterer verändert sie. Agenturen vereinheitlichen deshalb häufig ihre Registrarlandschaft oder nutzen, wo möglich, anbietergehostete CNAME-Schlüssel. Für mandantenfähige Umgebungen ist E-Mail-Hosting für mehrere Domains der umfassendere Betriebsansatz.

DKIM prüfen: DNS und echte Nachrichten kontrollieren

Eine Anzeige „aktiv“ allein reicht nicht. Eine vollständige DKIM-Prüfung fragt öffentliches DNS direkt ab, kontrolliert den zurückgegebenen Eintrag und bestätigt anhand realer Mailheader die erwartete Signaturdomain und den Selektor. Alles andere ist nur eine Teilprüfung.

Beginnen Sie mit der Kommandozeile:

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

Sie sollten den vollständigen v=DKIM1-Eintrag oder Zeichenkettenteile sehen, die zusammen den vollständigen Schlüssel ergeben. Bei leerem Ergebnis prüfen Sie nacheinander:

1. Ist der Selektor korrekt?
2. Wurde die Domain im Host-Feld nicht doppelt angehängt?
3. Entspricht der Eintragstyp der Anbietervorgabe?
4. Ist der Wert vollständig und nicht abgeschnitten?
5. Ist noch eine alte Antwort im Cache?

Senden Sie anschließend eine Testnachricht an Gmail oder ein anderes Postfach mit einsehbaren Headern. Suchen Sie Authentifizierungsergebnisse und DKIM-Signatur:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

Ist DNS korrekt, die Posteingangsplatzierung aber weiterhin schlecht, prüfen Sie weitere Faktoren. TrekMails Leitfaden zu Nachrichten im Spam nennt DNS-Status, Domain-Warm-up, Listenqualität und Inhalt. DKIM behebt einen Teil der Authentifizierung, verschafft jedoch nicht automatisch eine gute Reputation.

Beachten Sie auch Weiterleitungen: Dabei scheitert SPF häufig. Eine gültige, ausgerichtete DKIM-Signatur kann DMARC in vielen solchen Abläufen weiterhin bestehen lassen, sofern signierte Inhalte unverändert bleiben. Lesen Sie bei Bedarf E-Mail-Weiterleitung, um einen SPF-Fehler durch Weiterleitung nicht mit vollständig fehlgeschlagener Authentifizierung zu verwechseln.

DKIM und die Alignment-Falle

Am Alignment scheitern viele scheinbar funktionierende Konfigurationen. DKIM kann gültig sein und DMARC trotzdem scheitern, wenn die Signaturdomain nicht zur sichtbaren From-Domain passt und kein ausgerichtetes SPF besteht. Manchmal liegt es am DNS, häufig jedoch an der Anbieterkonfiguration.

Ein typischer Fall:

From: ceo@example.com
DKIM-Signaturdomain: d=sendgrid.net
Ergebnis: DKIM kann bestehen, aber DMARC-Alignment kann scheitern, weil die Signaturdomain nicht zu example.com passt.

Google verlangt bei Massenversendern, dass die sichtbare From-Domain mindestens auf Ebene der Organisationsdomain zu SPF oder DKIM passt. Signiert der E-Mail-Dienstleister nur mit seiner eigenen Domain, unterstützt diese Signatur Ihr DKIM-Alignment nicht.

Je nach Anbieter heißt die erforderliche Einrichtung Domainauthentifizierung oder White-Labeling. Ein eigener Return-Path betrifft dagegen insbesondere SPF-Alignment und ersetzt nicht die DKIM-Signaturdomain. Für DKIM sollte die endgültige Signatur etwa so aussehen:

DKIM-Signature: ... d=example.com; s=s1; ...

Ausgerichtetes DKIM unterstützt DMARC. Es ist ein wichtiger Teil der Zustellkonfiguration, aber keine Garantie für die Platzierung im Posteingang.

Alter und neuer Ansatz bei der DKIM-Einrichtung

Der alte Ansatz ist manuell und fehleranfällig: Jede Domain, jeder Anbieter, Selektor und DNS-Sonderfall wird einzeln bearbeitet. Der neue Ansatz standardisiert den Versandweg, bündelt DNS-Prüfungen und verwendet denselben nachvollziehbaren Ablauf für mehrere Domains.

TrekMail beschreibt ein entsprechendes Modell: mehrere eigene Domains in einem Dashboard, gemeinsamer Speicher statt Abrechnung pro Postfach, IMAP-Migration vorhandener Postfächer sowie BYO SMTP oder enthaltenes SMTP je nach Tarif. Die beschriebenen kostenpflichtigen Tarife beginnen bei $3.50 pro Monat. Prüfen Sie die aktuellen Preise und Leistungen. Die Plattform richtet sich an Teams, kleine und mittlere Unternehmen, Agenturen und MSPs, die den Infrastrukturaufwand reduzieren möchten.

Liegt das größere Problem im Prozess statt im DNS, lesen Sie Verwaltung von Kunden-E-Mail. In Mehrdomain-Umgebungen sind unklare Zuständigkeiten häufig ein wichtiger Auslöser von Zustellproblemen.

Abschließende DKIM-Prüfliste

Eine belastbare DKIM-Einrichtung umfasst das richtige Signiersystem, den korrekten DNS-Namen, einen vollständigen Schlüssel, die Prüfung im öffentlichen DNS und Alignment für DMARC. Fehler in einem dieser Teile beeinträchtigen die gesamte Konfiguration.

1. Das System für die Signierung ausgehender Post bestimmen.
2. Selektor und Eintragstyp des Anbieters exakt veröffentlichen.
3. selector._domainkey als Host verwenden, sofern der DNS-Anbieter nicht ausdrücklich den vollständigen Namen verlangt.
4. 2048-Bit-Schlüssel vollständig erhalten. Zeichenketten nur aufteilen, wenn das DNS-Panel dies verlangt.
5. Mit dig oder nslookup prüfen.
6. Testnachricht senden und Header auf dkim=pass sowie ausgerichtetes header.d prüfen.
7. DMARC-Ergebnisse nach dem Produktivstart kontrollieren.

Darauf kommt es an: DKIM ist vor allem präzise Konfigurationsarbeit. Für weniger Abhängigkeiten können Sie Domains und Versandwege in TrekMail vereinheitlichen und DNS-Prüfungen zentral sichtbar halten. Prüfen Sie dabei jede tatsächlich verwendete Versandroute.