DKIM-Eintrag: Selektoren, Rotation und Fehlersuche

Sinken die Öffnungsraten, prüfen Sie neben Inhalt und Messgrenzen auch DNS, insbesondere Ihren DKIM-Eintrag. Die Öffnungsrate allein beweist jedoch keinen DKIM-Fehler.

SPF prüft die verbindende IP für eine Envelope-Domain. DKIM, DomainKeys Identified Mail, wirkt eher wie ein Siegel für ausgewählte signierte Daten. Es ermöglicht deren kryptografische Prüfung, garantiert aber weder persönliche Identität noch unveränderte Inhalte bis zum Posteingang. Seit 2024 gelten bei Google und Yahoo strengere Anforderungen für betroffene Massenversender. Fehlendes gültiges DKIM kann Ablehnung oder Filterung verursachen; es macht nicht pauschal jede Nachricht unsichtbar.

Für einen Einzelgründer kann die Einrichtung im Beispiel zehn Minuten Aufwand bedeuten, ohne feste Zeitgarantie. Bei einem MSP mit 500 Domains sind Rotation, falsche Selektoren und DNS-Syntaxfehler dauerhafte Betriebsaufgaben, die auch freitags um 9 Uhr abends auffallen können.

Dieser Betriebsleitfaden erklärt Ihren DKIM-Eintrag auf DNS-Ebene, die Grenze von 255 Bytes je TXT-Zeichenkette und die Diagnose, wenn eine grüne Anzeige beim ESP nicht mehr dem tatsächlichen Versand entspricht.

Was ist ein DKIM-Eintrag?

Ein DKIM-Eintrag veröffentlicht einen kryptografischen öffentlichen Schlüssel im DNS, normalerweise als TXT. Empfänger prüfen damit eine Signatur der angegebenen Signierdomain und die zugehörigen signierten Daten. Das bestätigt nicht automatisch, dass die sichtbare From-Domain oder eine bestimmte Person legitim ist.

Der Schlüssel steht unter selector._domainkey.yourdomain.com, wobei selector den vom Signierer gewählten Schlüssel bezeichnet. Ein verkürztes Beispiel ist:

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

v=DKIM1 bezeichnet die Version, k=rsa den Algorithmus und p= den Base64-kodierten öffentlichen Schlüssel. Das gezeigte Fragment ist unvollständig und nicht einsetzbar. Der zugehörige private Schlüssel bleibt geschützt beim Signierer und gehört niemals ins DNS. Der Leitfaden zum Erstellen eines DKIM-Eintrags erläutert die Felder und den vollständigen Ablauf.

Was DKIM signiert und warum das zählt

DKIM ist nicht nur ein Kontrollkästchen. Es verknüpft signierte Daten mit einer Signierdomain und schützt deren überprüfbare Integrität nach den gewählten Regeln, nicht die persönliche Identität oder sämtliche Nachrichtendaten.

Der Signierer verarbeitet ausgewählte Header, typischerweise From, Subject, Date, To und Message-ID, sowie den Nachrichtenkörper nach der Kanonisierung, meist mit SHA-256. From muss signiert sein; die übrigen genannten Header sind typische Beispiele. Mit dem privaten Schlüssel erzeugt er die Signatur über die vorgesehenen Daten. Sie steht im Header DKIM-Signature und reist mit der Nachricht.

Gmail, Outlook oder ein anderer Empfänger führt dazu unter anderem diese Schritte aus:

1. Im Header DKIM-Signature Signierdomain und Selektor ablesen.
2. Den öffentlichen Schlüssel unter selector._domainkey.yourdomain.com im DNS abrufen.
3. Die kryptografische Signatur mit dem öffentlichen Schlüssel prüfen, nicht den Nachrichteninhalt entschlüsseln.
4. Die vorgesehenen Hashwerte aus den empfangenen signierten Daten neu berechnen.
5. Die Ergebnisse und weitere Gültigkeitsbedingungen prüfen. Übereinstimmung kann DKIM pass ergeben; Fehler können DKIM fail verursachen.

Ein Erfolg bestätigt zwei begrenzte Eigenschaften: Authentizität der Signatur bezüglich des veröffentlichten Schlüssels und Integrität der abgedeckten Daten nach Kanonisierung und Signaturumfang. Nicht jede erlaubte Normalisierung ist byteidentisch, und nicht alle Header müssen signiert sein. Ein passender öffentlicher Schlüssel macht die Prüfung möglich. Das Verfahren beschreibt RFC 6376, hilfreich auch bei der Abstimmung über konforme Implementierungen.

Weiterleitung und die Grenzen von DKIM

Ein Geschäftsführer sendet eine Rechnung an einen Firmenkontakt, der an sein privates Gmail weiterleitet. Bleibt die ursprüngliche Envelope-Domain bestehen und ist die IP des Weiterleiters dort nicht autorisiert, kann SPF scheitern. DMARC scheitert aber erst, wenn weder erfolgreiches ausgerichtetes SPF noch eine gültige ausgerichtete DKIM-Signatur vorliegt. Filterung oder Ablehnung hängen anschließend vom Empfänger ab.

DKIM kann Weiterleitung überstehen, wenn die Signatur und ihre abgedeckten Daten nach Kanonisierung gültig bleiben und der passende Schlüssel erreichbar ist. Der letzte Empfänger kann die ursprüngliche Signatur prüfen, obwohl eine andere IP verbindet. Ein Zwischenhop ist daher nicht automatisch schädlich, kann durch Änderungen aber die Prüfung beeinflussen.

Verlassen Sie sich bei wichtigen Versandpfaden nicht ausschließlich auf SPF. Ergänzen Sie einen passenden DKIM-Eintrag und eine durchdachte SPF-Konfiguration; die Grundlagen erklärt SPF für E-Mail. DMARC kann dann einen von zwei ausgerichteten Authentifizierungswegen nutzen, ohne beide zugleich zu verlangen.

Bei entsprechend unterstützter Weiterleitung kann TrekMail SRS verwenden. Es schreibt den Envelope-Absender auf die Domain des Weiterleiters um und ermöglicht deren SPF-Prüfung, stellt aber nicht die ursprüngliche From-Ausrichtung wieder her. DKIM-Unterstützung und Signierung sind für die tatsächlichen Managed- oder BYO-Versandpfade nach aktueller Dokumentation zu prüfen; nicht jede Route ist automatisch abgedeckt.

Selektoren für mehrere DKIM-Schlüssel

Der DKIM-Selektor sagt dem Empfänger, welchen öffentlichen Schlüssel er abrufen soll. Falsche Selektoren sind eine häufige Fehlerquelle, aber nicht nachgewiesenermaßen die Ursache der meisten Einrichtungsausfälle.

SPF erlaubt nur eine SPF-Richtlinie je geprüftem DNS-Namen. DKIM kann mehrere Schlüssel unter verschiedenen Selektornamen wie selector._domainkey.yourdomain.com veröffentlichen. Bei Bedarf können zehn Selektoren gleichzeitig aktiv sein, beispielsweise einer je Versanddienst. Anbietergrenzen und die tatsächliche Konfiguration bleiben zu beachten.

Warum mehrere Selektoren sinnvoll sind

Nutzen Sie Google Workspace für Unternehmensmail und Mailchimp für Newsletter, sind getrennte Schlüssel und Selektoren in der Regel sinnvoll. Gemeinsame private Schlüssel zwischen Anbietern vergrößern den Zugriffs- und Widerrufsbereich. Geben Sie jedem Dienst seine eigene, passend abgesicherte Konfiguration:

• Google Workspace: Ein möglicher Selektor ist google mit Veröffentlichung unter google._domainkey.yourdomain.com.
• Mailchimp: Beispiele sind k1 oder k2 mit dem Namen k1._domainkey.yourdomain.com. Aktuelle Anbieterwerte prüfen.
• TrekMail: Ein Beispiel ist tm1 unter tm1._domainkey.yourdomain.com. TXT oder CNAME sind nach der tatsächlichen Anbieteranleitung zu veröffentlichen.

Bei einer Kompromittierung des Marketingdienstes lässt sich dessen Selektor k1 gezielt widerrufen, ohne absichtlich den Google-Schlüssel zu ändern. Das garantiert dennoch keine störungsfreie Zustellung oder vollständige Reputationsisolation. Der Selektorleitfaden erklärt Syntax, Namenswahl und das Auffinden der vom ESP vorgegebenen Werte.

Ein klassischer Einrichtungsfehler

Eine DNS-Oberfläche ergänzt die Domain automatisch. Statt google._domainkey.yourdomain.com entsteht dann google._domainkey.yourdomain.com.yourdomain.com. Der falsch benannte Eintrag kann existieren, während die Abfrage des richtigen Namens NXDOMAIN ergibt. Eine frühere ESP-Bestätigung muss das nicht erkennen. Die Anleitung DNS-Status prüfen hilft bei der gezielten Abfrage, ohne eine sofortige Diagnose zu garantieren.

Schlüssellänge und Rotation

Die Stärke des Schlüssels ist ein wichtiger Bestandteil der DKIM-Sicherheit. Anforderungen ändern sich; was vor fünf Jahren angemessen erschien, sollte heute anhand aktueller Vorgaben überprüft werden.

RSA-Schlüssel mit 2048 Bit

1024-Bit-RSA war lange üblich. Google verlangt mindestens die in seinen Regeln angegebene Mindestlänge und empfiehlt 2048 Bit bei Unterstützung; Anforderungen von Yahoo sind separat aktuell zu prüfen. Ein alter cPanel- oder Postfix-Aufbau mit 1024 Bit, etwa aus der Zeit vor 2019, verdient eine Prüfung, ist aber nicht allein aufgrund des Alters automatisch ungültig.

512-Bit-Schlüssel sind für heutige DKIM-Anforderungen unzureichend. Ein Ergebnis wie dkim=perm_fail mit „weak key“ oder „policy“ kann darauf hinweisen, muss aber anhand der konkreten Diagnose bewertet werden. Bereiten Sie einen neuen 2048-Bit-Schlüssel vor und wechseln Sie kontrolliert; alte öffentliche Schlüssel dürfen nicht unüberlegt für noch unterwegs befindliche Signaturen entfernt werden. Aktuelle Regeln stehen in Googles Absenderrichtlinien.

Wie oft rotieren?

Ein jährlicher Wechsel kann als Betriebsrichtlinie dienen, ist aber kein für alle Umgebungen verbindlicher Mindestturnus. Nach Offenlegung eines privaten Schlüssels, etwa durch Servereinbruch oder zu breite Zugriffsrechte, braucht es einen umgehenden kontrollierten Widerruf und Ersatz. Ein Angreifer kann den Schlüssel nutzen, solange Empfänger ihn akzeptieren; das ist nicht zwingend unbegrenzt oder erst an zerstörter Domainreputation erkennbar.

Behandeln Sie den privaten DKIM-Schlüssel wie ein sensibles Geheimnis. Fünf Jahre ohne Prüfung sind kein sinnvoller Automatismus für ein Produktivsystem. Rotation, Zugriffsschutz und Reaktion auf Vorfälle gehören zusammen.

Die TXT-Grenze von 255 Bytes richtig behandeln

Bei einem Wechsel auf 2048 Bit kann die Länge überraschen. Ein öffentlicher 2048-Bit-Schlüssel in Base64 ist ungefähr 400 Zeichen lang. Eine DNS-TXT-Zeichenkette hat jedoch eine Grenze von 255 Bytes. Manche Oberflächen teilen lange Inhalte automatisch auf, andere lehnen sie ab oder verarbeiten sie fehlerhaft. Eine pauschale stille Kürzung durch die meisten Anbieter lässt sich nicht voraussetzen.

Lange Inhalte können als mehrere zitierte Zeichenketten in einem TXT-Eintrag veröffentlicht werden. RFC 6376 sieht deren Verkettung für die Schlüsselprüfung vor. Mehrere separate Schlüssel-TXT-Einträge sind nicht dasselbe.

Unvollständige Einzelzeichenkette: nicht als fertigen Schlüssel übernehmen.

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

Aufteilungsprinzip mit zwei Zeichenketten; die Platzhalter müssen durch den vollständigen echten Schlüssel ersetzt werden.

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

Die Eingabesyntax hängt vom DNS-Anbieter ab. Klammern gehören etwa zur Zonendateisyntax; Weboberflächen können andere Eingaben verlangen. Die Anleitung DNS bei gängigen Anbietern einrichten behandelt unter anderem Cloudflare, Route 53 und GoDaddy. Achten Sie darauf, dass tatsächlich ein TXT-Eintrag entsteht.

Eine unterstützte CNAME-Delegierung kann die lokale Eingabe eines langen Schlüssels vermeiden. Der veröffentlichte Name ist im Beispiel deutlich kürzer als 255 Zeichen, wobei für CNAME andere DNS-Grenzen gelten. Am selben Namen darf kein TXT neben dem CNAME stehen. Der Anbieter verwaltet das Ziel; Rotation, Caches und die Gültigkeit unterwegs befindlicher Signaturen bleiben dennoch zu planen und zu prüfen.

Einrichtung überprüfen

Nach Veröffentlichung reicht ein „Verified“-Badge des ESP nicht allein. Anzeigen und DNS-Resolver können Daten cachen, während Namen oder Inhalte inzwischen anders sind. Prüfen Sie DNS aus passenden Perspektiven und anschließend eine tatsächliche Nachricht; eine einzelne Live-Abfrage beweist nicht alles.

Schritt 1: Den veröffentlichten Namen abfragen

Unter Linux/macOS können Sie folgende Befehle nutzen. Unter Windows verwenden Sie in der Eingabeaufforderung nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Ersetzen Sie selector durch den tatsächlichen Selektor und yourdomain.com durch Ihre Domain.

Prüfen Sie die aufgelösten Schlüsseldaten; v=DKIM1 kann die Version kennzeichnen, ist im Schlüssel-TXT aber nicht zwingend vorhanden. NXDOMAIN bedeutet, dass der abgefragte Resolver den Namen nicht kennt. Bei NXDOMAIN prüfen Sie Selektor, vollständigen Namen, autoritative Antworten und Caches. 30 Minuten Wartezeit sind nur ein möglicher Prüfzeitpunkt, keine Garantie weltweiter Verfügbarkeit.

Schritt 2: Den Schlüsselinhalt validieren

Existiert der Name, untersuchen Sie bei Fehlern die tatsächliche Antwort:

dig txt selector._domainkey.yourdomain.com +short

Achten Sie auf zwei Bereiche:

• Kürzung: Eine Base64-Zeichenkette mit weniger als 200 Zeichen kann bei einem erwarteten 2048-Bit-Schlüssel auf unvollständige Daten hindeuten. Länge allein ist keine vollständige Diagnose; prüfen Sie Verkettung und dekodierten Schlüssel.
• Veränderte Daten: Oberflächen können beim Einfügen die Base64-Daten anders darstellen oder verändern. Nicht jede zulässige Leerraumbehandlung ist ein Fehler. Vergleichen Sie den tatsächlich dekodierten öffentlichen Schlüssel mit der vertrauenswürdigen Quelle und unterscheiden Sie Anzeige-Escapes von echten Zeichen.

Schritt 3: Testmail und Header prüfen

Senden Sie an ein kontrolliertes Gmail-Konto und öffnen Sie über das Drei-Punkte-Menü „Original anzeigen“. Prüfen Sie im Rohtext das vom vertrauenswürdigen Empfangssystem hinzugefügte Authentication-Results:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass zeigt einen erfolgreichen Prüffall, garantiert aber weder DMARC-Alignment noch Posteingangsplatzierung. Ergebnisse wie fail, neutral, perm_fail oder temperror sind mit der Implementierung und ihrem Begründungstext zu bewerten. Bezeichnungen können abweichen. Der DKIM-Einrichtungsleitfaden und TrekMails Checkliste für die Ersteinrichtung unterstützen die Prüfung verwandter Authentifizierungsschritte.

DKIM-Fehler: drei praktische Fälle

Der Name existiert, der Selektor stimmt und DNS scheint erreichbar, doch die Prüfung schlägt fehl. Jetzt müssen tatsächliche Daten und Verarbeitungsschritte untersucht werden; „das müsste funktionieren“ genügt nicht.

Der ausführliche DKIM-Fehlerleitfaden behandelt weitere Ergebnisse. Die folgenden drei Fälle sind praktische Beispiele, keine belegte Rangliste der häufigsten Produktionsfehler.

Fall 1: „Body Hash Did Not Verify“

Eine nicht passende Prüfsumme des Nachrichtenkörpers kann die E-Mail-Zustellung beeinträchtigen. Sie bedeutet, dass die empfangenen abgedeckten Körperdaten nach Kanonisierung nicht zum signierten Hash passen. Daraus folgt nicht automatisch, dass die Header-Signatur bereits kryptografisch gültig war oder die Ursache allein beim Absender liegt.

Mögliche Auslöser:

• Warnbanner für externe Absender: Ein Gateway ergänzt einen Hinweis wie „EXTERNE E-MAIL: VORSICHT“. Passiert das vor der DKIM-Prüfung, kann die Änderung abgedeckter Körperdaten die Signatur ungültig machen. Das ist etwa bei Microsoft 365 mit entsprechenden Mailflow-Regeln zu untersuchen.
• Juristische Fußzeilen: Ein Gateway fügt einen Disclaimer mit 15 Zeilen hinzu. Wird vorher signiert, kann die Ergänzung den Körperhash verändern. Gegebenenfalls sollte nach der letzten kontrollierten Änderung am Gateway signiert werden.
• URL-Umschreibung durch Sicherheitsdienste: Mimecast, Proofpoint und Defender for Office 365 können Links verändern, etwa google.com zu protect.mimecast.com/s/.... Änderungen an signierten Körperdaten können die Prüfung brechen, abhängig von Kanonisierung und Signaturumfang.

Signieren Sie möglichst nach der letzten Änderung innerhalb Ihrer kontrollierten Infrastruktur. Änderungen nach Empfang müssen dagegen vor der Modifikation geprüft oder im konkreten Ablauf anders berücksichtigt werden; spätes Signieren beim Absender verhindert sie nicht. TrekMails tatsächlichen Signierpunkt sollten Sie für den jeweiligen Versandpfad prüfen, nicht als Garantie unveränderter Empfängerdaten ansehen. Weitere Hinweise bietet Fehlersuche beim Versand.

Fall 2: Die Alignment-Frage

Ein zunächst widersprüchlicher Fall: In vertrauenswürdigen Headern steht:

dkim=pass (signature was valid)

DKIM ist erfolgreich, DMARC kann dennoch scheitern. Eine mögliche Ursache ist fehlendes DKIM-Alignment, sofern auch kein anderer gültiger ausgerichteter Authentifizierungsweg vorhanden ist. Spamplatzierung folgt daraus nicht automatisch.

DMARC prüft nicht nur die Signaturgültigkeit, sondern die Domain aus d= gegenüber der Domain in Header From. Strict verlangt genaue Übereinstimmung; relaxed kann dieselbe organisatorische Domain akzeptieren.

Ein Beispiel:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

Die SendGrid-Signatur ist für sendgrid.net gültig. Der Empfänger bewertet anhand der Absenderdomain und ihrer DMARC-Richtlinie die Ausrichtung zu yourcompany.com. sendgrid.net != yourcompany.com zeigt hier fehlendes Alignment dieser Signatur. DMARC scheitert nur, wenn weder erfolgreiches ausgerichtetes SPF noch eine andere gültige ausgerichtete DKIM-Signatur vorliegt.

Unterstützte ESP-Domainauthentifizierung oder eigenes Signieren kann einen passenden DKIM-Schlüssel verwenden, sodass d= etwa yourcompany.com statt sendgrid.net nennt. Verfügbarkeit und konkrete Werte hängen vom Anbieter ab. Prüfen Sie dessen Anleitung und verstehen Sie DMARC-Alignment, statt allein eine gültige Dienstleistersignatur als Fehler zu behandeln.

Fall 3: Alte oder zu schwache Schlüssel

Ein veralteter Schlüssel kann dauerhafte DKIM-Fehler verursachen. dkim=perm_fail mit „policy“ oder „weak key“ kann etwa auf einen 512- oder 768-Bit-Schlüssel hinweisen, beweist diese Länge aber nicht. Solche Schlüssel erfüllen heutige maßgebliche Anforderungen nicht; prüfen Sie die konkrete Empfängerdiagnose. Ein permanenter DKIM-Prüffehler ist nicht selbst gleichbedeutend mit einer permanenten SMTP-Ablehnung.

Bereiten Sie ein neues 2048-Bit-Schlüsselpaar mit neuem Selektor vor, veröffentlichen und prüfen Sie es vor dem Wechsel. Behalten Sie den alten öffentlichen Schlüssel für noch geprüfte alte Nachrichten, soweit ein Sicherheitsvorfall nicht einen sofortigen Widerruf verlangt. Die folgenden Hinweise zur lokalen Erzeugung und der DKIM-Generatorleitfaden unterstützen den Ablauf.

Schlüssel sicher erzeugen

Für Ihren DKIM-Eintrag benötigen Sie ein Schlüsselpaar. Der erste Treffer eines DKIM-Generators im Web mag einen Schlüssel direkt anzeigen. Prüfen Sie vor Nutzung, wo die Erzeugung stattfindet und wer Zugriff auf das Geheimnis erhält.

Eine Anzeige im Browser beweist nicht automatisch eine Kompromittierung, etwa bei nachvollziehbarer lokaler Erzeugung. Ein unbekannter Dienst, der private Schlüssel serverseitig erzeugt, kann sie jedoch speichern oder offenlegen. Ohne belastbares Vertrauen sollten solche Schlüssel nicht produktiv eingesetzt werden. Missbrauch ist möglich, solange ein offengelegter Schlüssel akzeptiert wird, nicht zwangsläufig für immer oder ohne erkennbare Hinweise.

Geeignete Erzeugungsmodelle vergleichen

Auf einem eigenen sicher verwalteten Server können Sie OpenSSL verwenden:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

Schützen Sie die private Datei durch passende Zugriffsrechte; sie gehört nicht ins DNS oder in unkontrollierte Übertragungen. Der letzte Befehl zeigt nur die öffentliche PEM-Datei und entfernt deren Header nicht automatisch. Für den DKIM-Wert muss der öffentliche Schlüssel korrekt aufbereitet werden. Eine Bitte, den privaten Schlüssel zur „Verifikation“ per Mail zu senden, ist ein ernstes Warnsignal.

Gründer, Agenturen und andere Betreiber können die Erzeugung einem passend abgesicherten Anbieter überlassen. Klären Sie dessen Schutzmaßnahmen und Verantwortlichkeiten, statt allein auf die Bezeichnung „verwaltet“ zu vertrauen.

Manuelle und automatisierte Verwaltung

Bei Rotation wird der Aufwand pro DKIM-Eintrag sichtbar. Veröffentlichte Schlüssel brauchen regelmäßige Kontrolle. Ein jährlicher Beispielablauf sieht so aus:

Manueller jährlicher Beispielablauf je Domain

1. Ein neues RSA-Schlüsselpaar mit neuem Selektor, etwa s2026, erzeugen.
2. Den neuen öffentlichen Schlüssel unter s2026._domainkey.yourdomain.com veröffentlichen.
3. 48 Stunden sind ein Beispielpuffer; tatsächliche Veröffentlichung und relevante Caches prüfen, bevor umgestellt wird.
4. Den Signierer kontrolliert auf den neuen privaten Schlüssel umstellen und Testnachrichten prüfen.
5. Beide öffentlichen Selektoren im Beispiel 7 Tage verfügbar halten; tatsächlich müssen alte Nachrichten in Warteschlangen und unterwegs berücksichtigt werden.
6. Den alten öffentlichen Selektor erst nach angemessener Übergangszeit oder nach begründetem Sicherheitswiderruf entfernen.
7. Den alten privaten Schlüssel nach dem sicheren Wechsel entsprechend Ihrer Aufbewahrungs- und Vorfallrichtlinie vernichten.

Das sind 7 Beispielschritte je Domain und Jahr, bei 50 Domains also 350 Schritte. Der echte Aufwand und die Fehlertoleranz hängen von Werkzeugen ab. Wird Schritt 5 ausgelassen, können alte Signaturen beeinträchtigt werden. Bei Schritt 6 muss zwischen notwendiger Übergangsverfügbarkeit und unnötig langem Vertrauen unterschieden werden.

Eine einzelne Domain ist manuell oft gut zu betreuen. Bei 50 Domains können Inventar, Monitoring und Automatisierung helfen, Rotationen nicht zu übersehen. Ohne sie ist ein Freitagsvorfall möglich, aber nicht unvermeidlich.

DKIM-Verwaltung mit TrekMail

TrekMail richtet sich an Betreiber mehrerer Domains, etwa Gründer mit fünf Nebenprojekten oder MSPs mit 800 Kundendomains. Die verfügbaren DKIM-Verwaltungsfunktionen sind anhand der aktuellen Anleitung zu prüfen.

CNAME-basierte Rotation

Bei unterstützter CNAME-Einrichtung kann der Assistent einen Eintrag wie diesen vorgeben. Verwenden Sie die tatsächlich zugewiesenen Namen und Ziele:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Die Delegierung kann lokale DNS-Änderungen bei Rotation verringern. Der Anbieter verwaltet das Schlüsselziel; ein Austausch unter demselben Selektor kann alte oder unterwegs befindliche Signaturen ungültig machen. Überlappende Selektoren und ein koordinierter Übergang müssen Caches und alte Signaturen berücksichtigen. Eine unveränderte CNAME-Zeile garantiert weder Ausfallfreiheit noch fehlenden Kontrollbedarf. Bei 80 Domains kann zentrale Verwaltung helfen, ohne jede Erinnerung oder Prüfung entfallen zu lassen.

Der Ausgangstext nennt für Pro $8 monatlich und 100 Domains und vergleicht 700 manuelle Schritte pro Jahr. Preise, Grenzen und der tatsächliche Vergleichsaufwand sind aktuell zu prüfen; diese Rechnung ist keine zugesicherte Einsparung.

Geführte DNS-Einrichtung

Ein verfügbarer DNS-Assistent kann MX, SPF, DKIM und DMARC an einem Ort vorbereiten und prüfen. Senderinventar, tatsächliche Werte, DNS-Veröffentlichung, Caches und reale Testnachrichten bleiben zu kontrollieren. Ein Badge ist auch hier keine universelle Garantie. Details stehen in der Anleitung Erforderliche DNS-Einträge.

Pauschalmodell statt reiner Nutzerabrechnung

Im Ausgangstext werden Starter mit $3.50 monatlich, 50 Domains und 100 Nutzern je Domain sowie Pro mit $8 monatlich, 100 Domains und 300 Nutzern je Domain genannt. Agency wird mit 1,000+ Domains beschrieben. Diese historischen Angaben und die gemeinsame Speicherzuweisung sind anhand aktueller Tarife zu prüfen. Mehr Postfächer sind nicht pauschal unbegrenzt oder immer ohne Zusatzkosten möglich.

Verfügbarkeit, Einrichtung und Signierpfade von DKIM können vom aktuellen Tarif und SMTP-Modell abhängen. Prüfen Sie den Leistungsumfang, statt gleiche Authentifizierung auf jeder Route allein aus dem Pauschalmodell abzuleiten.

Eigenverwaltung und TrekMail im Vergleich

Fazit

Ein passender DKIM-Eintrag gehört zu einer belastbaren Mailkonfiguration in 2025 und danach und ist für entsprechend betroffene Absender vorgeschrieben. Sein Fehlen bedeutet aber nicht automatisch DMARC-Fehler bei jeder Nachricht oder Reputationsverlust bei jeder Weiterleitung. Prüfen Sie die jeweiligen Anforderungen und sämtliche ausgerichteten Authentifizierungswege.

Beginnen Sie mit einem passenden 2048-Bit-RSA-Schlüssel bei Unterstützung, richtigem Selektor, vollständigem TXT-Inhalt und geprüftem Alignment zur sichtbaren From-Domain. Ergänzen Sie kontrollierte Rotation, passende DMARC-Richtlinien und verfügbare Daten aus Google Postmaster Tools. Diese Daten können unvollständig oder verzögert sein.

Der Vergleich SPF, DKIM und DMARC erklärt die Beziehungen und sinnvolle Einrichtungsschritte. Bei akuten Problemen bietet verhindern, dass E-Mails im Spam landen eine Ausgangsreihenfolge, die Sie an bestätigte Ursachen anpassen sollten.

Bei vielen Domains kann manuelle DKIM-Verwaltung Aufwand und Fehlerquellen erhöhen. Falsche Namen, gekürzte Schlüssel oder eine unpassende Rotation können betroffene Versandpfade beeinträchtigen. CNAME-Verwaltung kann lokale Aufgaben reduzieren, beseitigt aber nicht diese gesamte Fehlerklasse. Tarife ansehen oder das kostenlose Angebot prüfen: 10 Domains und keine Kreditkarte sind Angaben des Ausgangstextes, deren aktuelle Bedingungen zu bestätigen sind.