E-Mail-Authentifizierung mit SPF, DKIM und DMARC erklärt

E-Mail-Authentifizierung mit SPF, DKIM und DMARC gehört zur Grundkonfiguration einer sendenden Domain. Wenn Ihre Domain 2025 oder 2026 geschäftliche E-Mails versendet, beeinflussen diese Einträge, wie Empfänger Nachrichten einstufen oder ablehnen. Den Posteingang garantieren sie jedoch nicht. Für einen Überblick über den gesamten Stack beginnen Sie mit geschäftlichen E-Mails für kleine Unternehmen.

Bei SPF, DKIM und DMARC suchen viele Teams die Ursache zunächst im Inhalt. Manchmal liegt sie dort, oft ist aber die Domain falsch konfiguriert: ein fehlerhafter SPF-Eintrag, ein fehlender DKIM-Schlüssel oder eine nie veröffentlichte DMARC-Richtlinie. Dann können Ablehnungen bei Outlook, Begrenzungen bei Gmail, unerwünschte Einstufungen bei Yahoo und Weiterleitungsfehler auftreten.

Die Theorie ist einfach, die praktische Umsetzung verlangt Sorgfalt. SPF autorisiert IP-Adressen für die tatsächliche MAIL-FROM-Domain, DKIM bestätigt eine gültige Signatur über unverändert gebliebene signierte Daten, und DMARC veröffentlicht eine gewünschte Fehlerbehandlung und prüft die Ausrichtung zur sichtbaren From-Domain. Eine korrekte Einrichtung liefert Empfängern wichtige Signale, bestimmt deren Entscheidung aber nicht allein.

Was SPF, DKIM und DMARC tatsächlich leisten

Die drei Verfahren bilden ein mehrschichtiges System, mit dem Mailbox-Anbieter Nachrichten beurteilen. SPF prüft den Sendepfad, DKIM die Signatur und DMARC Alignment sowie Richtlinie. Für anwendbare Regeln bei Massenversand können veröffentlichte SPF- und DKIM-Konfigurationen erforderlich sein; für einen DMARC-Erfolg genügt ein erfolgreicher und ausgerichteter SPF- oder DKIM-Pfad.

Merken Sie sich: DMARC verlangt nicht, dass SPF und DKIM beide erfolgreich sind. Eines der beiden Verfahren muss erfolgreich und zur From-Domain ausgerichtet sein, die der Empfänger sieht.

SPF: Wer darf für Ihre Domain senden?

SPF bildet die erste Ebene der E-Mail-Authentifizierung und funktioniert als Absenderfreigabe. Der empfangende Server betrachtet die tatsächliche Envelope-Sender-Domain, also MAIL FROM, liest ihren SPF-TXT-Eintrag und prüft, ob die verbindende IP autorisiert ist. Das ist schnell und nützlich, reagiert aber empfindlich auf Weiterleitungen und lange Include-Ketten.

SPF wird als TXT-Eintrag in DNS veröffentlicht. Ein übliches Beispiel:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Die Bestandteile bedeuten:

1. v=spf1 deklariert den Eintragstyp.
2. include: verweist auf die veröffentlichte Versand-Infrastruktur einer anderen Domain.
3. -all legt für alle übrigen Quellen das Ergebnis fail fest.

Viele Konfigurationen stoßen hier an die erste Grenze: das Limit von 10 DNS-Lookups aus RFC 7208. Es umfasst relevante Mechanismen und Modifikatoren samt verschachtelten Abfragen hinter include. Wird es überschritten, kann der Empfänger PermError zurückgeben und die SPF-Auswertung nicht ordnungsgemäß abschließen.

Sie haben vor zwei Jahren ein CRM gekündigt, dessen include: jedoch behalten. Die Marketingplattform fügte drei weitere verschachtelte Quellen hinzu, das Supportsystem noch eine. Alles sah in Ordnung aus, bis ein Empfänger die gesamte Kette auswertete.

Bei Weiterleitung kann SPF ebenfalls scheitern. Leitet eine Universität Ihre Nachricht an Gmail weiter, sieht Gmail möglicherweise die IP der Universität statt Ihres Servers. Selbst ein korrektes SPF kann danach fehlschlagen. Deshalb reicht SPF allein nicht aus.

Wenn Sie TrekMail zum Senden verwenden, zeigt die Dokumentation das erforderliche Include und erklärt, wie es ohne doppelten Eintrag mit vorhandenem SPF zusammengeführt wird: Erforderliche DNS-Einträge.

DKIM: Wer hat die Nachricht signiert und wurde sie verändert?

Die zweite Ebene ist DKIM. Das sendende System signiert ausgewählte Daten mit einem privaten Schlüssel; der Empfänger prüft die Signatur mit dem öffentlichen Schlüssel aus DNS. Anders als SPF übersteht DKIM Weiterleitungen häufig, sofern die Signatur gültig bleibt und kanonisierte signierte Header und Inhalte nicht inkompatibel verändert wurden.

DKIM-Einträge liegen unter einem Selektor, etwa selector1._domainkey.example.com oder dkim._domainkey.example.com. Der Sender signiert mit dem passenden Selektor, der Empfänger ruft den öffentlichen Schlüssel aus DNS ab und validiert die Signatur.

Ein typischer DNS-Wert:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

Die Ursache ist im Betrieb meist unspektakulär:

1. Nach einer Schlüsselrotation verwendet der Mailserver weiterhin den alten Selektor.
2. Nach einem Anbieterwechsel wurde der neue öffentliche Schlüssel nie veröffentlicht.
3. Der DNS-Host hat den langen TXT-Wert beschädigt.
4. Eine Mailingliste schrieb den Inhalt um und machte die Signatur ungültig.

Für neue kompatible Bereitstellungen sind Schlüssel mit 2048 Bit heute meist ein sinnvoller empfohlener Standard, sofern Plattform und DNS sie unterstützen. Alte Systeme mit 1024 Bit gibt es 2026 noch, doch die Schlüsselgröße muss zu den Fähigkeiten des tatsächlichen Signaturdienstes passen.

Bei kostenpflichtigen TrekMail-Tarifen kann Domainpost bei verwaltetem SMTP nach den aktuellen Bedingungen mit dem DKIM-Schlüssel Ihrer Domain signiert werden. Gegenüber einer reinen SPF-Konfiguration kann dies bei Weiterleitungen helfen, wenn die Signatur gültig und ausgerichtet bleibt. Zur Fehlerbehebung nach der Einrichtung lesen Sie Meine E-Mails landen im Spam.

DMARC: das Regelwerk für die gewünschte Behandlung

DMARC bildet die Richtlinienebene über SPF und DKIM. Es veröffentlicht, welche Behandlung bei Authentifizierungsfehlern gewünscht ist, und prüft das Alignment zwischen sichtbarer From-Domain und der Domain eines erfolgreichen SPF- oder DKIM-Pfads. Ohne Alignment gibt es keinen DMARC-Erfolg.

Der DMARC-Eintrag wird unter _dmarc.example.com veröffentlicht. Beginnen Sie einfach:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Steigern Sie die Richtlinie erst nach Inventarisierung und Tests:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

p=none fordert keine DMARC-bedingte Einschränkung an. p=quarantine bittet Empfänger, Fehler als verdächtig zu behandeln, und p=reject bittet um Ablehnung. Das sind veröffentlichte Richtlinienwünsche, keine Garantie identischer Behandlung durch alle Empfänger.

Die größere Falle ist das Alignment. Beispiel:

Sichtbares From: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
DKIM-Domain: vendor.com

SPF kann erfolgreich sein. DKIM kann ebenfalls erfolgreich sein. DMARC scheitert dennoch, weil keiner der erfolgreichen Domains mit yourcompany.com übereinstimmt.

Das ist ein häufiger Fehler bei Mailchimp-, HubSpot-, Zendesk- und CRM-Konfigurationen: Das Dashboard des Versanddienstes kann grün anzeigen, während die echte Nachricht nicht ausgerichtet ist. Googles aktuelle Richtlinien verlangen für betroffene Massenversender an private Gmail-Konten SPF und DKIM; bei direkter Post muss mindestens eines mit der From-Domain ausgerichtet sein. Die Hinweise nennen außerdem einen minimalen DMARC-Eintrag, auch mit p=none: FAQ zu Googles Absenderrichtlinien.

SPF, DKIM oder DMARC: Was ist am wichtigsten?

Die Frage nach dem wichtigsten Verfahren führt in die Irre, denn jedes erfüllt eine andere Aufgabe. DKIM ist bei erfüllten Voraussetzungen robuster gegenüber Weiterleitungen, SPF bleibt ein wichtiges Autorisierungssignal, und DMARC ergänzt Alignment und Richtlinie. Für anwendbare Regeln und einen belastbaren Aufbau benötigen Sie den gesamten Stack.

Bei einfachen Installationen mit einem Mailserver und ohne SaaS-Absender ist die Einrichtung meist überschaubar. Nutzen Supportsystem, Newsletter, CRM und Weiterleitung dieselbe Domain, zeigen DMARC-Berichte, welche realen Pfade ausgerichtet sind und welche nur im Dashboard so wirkten.

Warum Weiterleitungen und Mailinglisten ungewöhnliche Fehler erzeugen

Weiterleitung beeinträchtigt SPF, weil der Weiterleitungsserver die Nachricht weitersendet. DKIM hilft häufig, wenn die Signatur gültig bleibt. Verändert ein Vermittler signierte Inhalte oder die Betreffzeile inkompatibel, kann auch DKIM scheitern.

Deshalb können Einträge auf dem Papier korrekt aussehen, während ein Empfänger die Nachricht unerwartet behandelt. SPF scheitert nach einer geänderten IP, DKIM nach einem von der Mailingliste eingefügten Zusatz und DMARC, weil kein erfolgreicher ausgerichteter Pfad verbleibt.

Wenn SPF, DKIM und DMARC bei weitergeleiteter Post scheitern, können Vermittler mit ARC die von ihnen beobachteten Ergebnisse aufzeichnen, damit ein späterer Empfänger diesen Kontext nach eigenen Regeln bewertet. ARC bewahrt Vertrauen nicht automatisch und verwandelt DMARC nicht in pass. Googles Hinweise nennen besondere Bedingungen für DMARC-Alignment bei Weiterleitungen und Mailinglisten und empfehlen ARC-Header für indirekte Post. Als Absender richten Sie ARC normalerweise nicht selbst ein. Wichtiger sind gültiges DKIM und möglichst wenig fragile Weiterleitungsketten. Ist Weiterleitung zentral, lesen Sie anschließend den Leitfaden zur E-Mail-Weiterleitung.

Zusätzliche Prüfungen, die die Zustellung beeinflussen

Auch korrekt veröffentlichte Authentifizierungseinträge garantieren keinen Posteingang. Empfänger berücksichtigen zusätzlich Reverse DNS, TLS, Beschwerderaten und Abmeldeverfahren. SPF, DKIM und DMARC bilden die Grundlage, aber nicht das ganze Gebäude.

1. Vorwärtsbestätigtes Reverse DNS: Die sendende IP benötigt einen PTR-Eintrag, dessen Hostname wieder zu derselben IP auflösen sollte. Google nennt gültiges Vorwärts- und Reverse-DNS als Anforderung für entsprechende Absender.
2. TLS: Große Anbieter erwarten Übertragung mit TLS. Googles FAQ nennt fehlendes TLS in anwendbaren Fällen als möglichen Grund für vorübergehende oder dauerhafte Fehler.
3. Spam-Beschwerden: Google empfiehlt betroffenen Absendern, die Rate unter 0.1% zu halten und 0.3% nicht zu erreichen.
4. Abmeldung mit einem Klick: Für betroffene Werbepost gelten Anforderungen an Abmelde-Header nach RFC 8058; ein versteckter Footer-Link allein reicht nicht.

Beim Aufwärmen einer neuen Domain ist dies besonders wichtig. Ohne längere Historie können eine plötzliche Kampagne und eine schlecht gepflegte Liste die Reputation früh beeinträchtigen.

SPF, DKIM und DMARC sicher in Produktion konfigurieren

Inventarisieren Sie zuerst alle Absender, veröffentlichen Sie abgestimmte Einträge einmal, prüfen Sie sie anhand echter Nachrichten und verschärfen Sie DMARC stufenweise. Ohne Inventar unterbrechen Sie möglicherweise einen vergessenen SaaS-Dienst.

1. Listen Sie alle Dienste auf, die Ihre Domain verwenden: Mailbox-Host, CRM, Support, Newsletter, Formulare, Rechnungsdienste und Server.
2. Fassen Sie alle Absender in einem SPF-Eintrag zusammen. Veröffentlichen Sie niemals zwei SPF-TXT-Einträge.
3. Veröffentlichen Sie DKIM für jeden Absender, der einen eigenen Selektor benötigt.
4. Beginnen Sie DMARC mit p=none und prüfen Sie Berichte unter Berücksichtigung ihrer Lücken.
5. Aktivieren Sie bei externen Absendern die eigene Domainauthentifizierung und prüfen Sie Alignment mit echten Nachrichten.
6. Wechseln Sie erst nach mehreren repräsentativen Zeiträumen, seltenen kritischen Abläufen und vorbereitetem Rückweg zu p=quarantine und danach p=reject.

Für eine TrekMail-Domain mit verwaltetem Versand können die Basiseinträge so aussehen; tatsächliche Werte müssen jedoch aus dem aktuellen Dashboard und der Dokumentation stammen:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

Den genauen Aufbau und die Live-Prüfung erläutern TrekMails Erforderliche DNS-Einträge und DNS-Status prüfen. Für eine frühere Einrichtungsphase ergänzt E-Mail auf der eigenen Domain einrichten diese Anleitung.

Getrennter und integrierter Ansatz

Traditionell zahlen Teams pro Nutzer für eine große Suite oder betreiben Mailserver, DNS, TLS, DKIM-Selektoren und Reputation selbst. Ein anderer Ansatz trennt Mailbox-Hosting und Versand und nutzt eine Plattform, die Einträge, Prüfung und Migration im Rahmen des gewählten Tarifs bereitstellt.

Hier kann TrekMail eingesetzt werden. Nach den im Artikel beschriebenen aktuellen Bedingungen erlaubt Nano bis zu 10 Domains mit 5 GB gemeinsamem Speicher und eigenem SMTP. Kostenpflichtige Tarife beginnen bei $3.50 pro Monat und können verwaltetes SMTP enthalten. Abhängig vom Tarif stehen benutzerdefinierte Domains, IMAP-Mailboxen, Catch-all, Weiterleitung, integrierte IMAP-Migration und API-Zugriff bereit. Für kostenpflichtige Tarife kann eine kostenlose 14-tägige Testphase verfügbar sein, die eine Kreditkarte erfordert. Nano kann nach den geltenden Bedingungen ohne Karte kostenlos bleiben. Prüfen Sie vorab aktuelle Preise, Funktionen und Limits.

Dieses Modell ist relevant, weil die Verwaltung von SPF, DKIM und DMARC laufende Betriebsarbeit ist. Bei vielen Domains können eine Oberfläche, gemeinsamer Speicher, vorbereitete DNS-Einträge und serverseitige Migration getrennte Abläufe reduzieren, ersetzen aber keine Prüfung. Für diesen Anwendungsfall vergleichen Sie E-Mail-Hosting für mehrere Domains. Aktuelle Zahlen finden Sie bei den TrekMail-Preisen.

Fazit: SPF, DKIM und DMARC sind heute die Grundlage

E-Mail-Authentifizierung mit SPF, DKIM und DMARC ist keine seltene Spezialmaßnahme mehr. SPF nennt autorisierte IP-Adressen für die Envelope-Domain, DKIM belegt eine gültige Signatur ausgewählter Daten, und DMARC verbindet einen erfolgreichen Pfad mit der sichtbaren From-Domain und veröffentlicht die gewünschte Richtlinie.

Wenn Sie diese Woche nur eine Aufgabe erledigen können, erstellen Sie ein Absenderinventar, veröffentlichen Sie einen gültigen SPF-Eintrag, einen funktionierenden DKIM-Eintrag und DMARC mit p=none. Prüfen Sie anschließend jeden realen Pfad samt seltener Abläufe und Weiterleitungen. Verschärfen Sie die Richtlinie erst nach mehreren repräsentativen Zeiträumen und mit Rückweg. Diese Vorbereitung reduziert das Risiko späterer Fehlersuche, garantiert aber weder Zustellung noch Einsparungen.