SPF, DKIM und DMARC verständlich erklärt

Eine professionelle E-Mail-Adresse mit eigener Domain wirkt vertrauenswürdig – garantiert aber noch keine zuverlässige Zustellung. Empfangende Mailserver prüfen heute mehrere technische Signale. SPF, DKIM und DMARC helfen dabei zu bestätigen, welche Systeme für eine Domain senden dürfen und wie mit verdächtigen Nachrichten umzugehen ist.

SPF: Wer darf für die Domain senden?

SPF steht für Sender Policy Framework. Der Eintrag liegt im DNS der Domain und listet erlaubte Versandserver auf. Empfänger vergleichen den technischen Absender mit dieser Liste. Wichtig: Eine Domain sollte nur einen SPF-Eintrag besitzen. Mehrere getrennte Einträge führen häufig zu einem ungültigen Ergebnis.

Ein SPF-Eintrag kann eigene IP-Adressen und die Regeln externer Versanddienste enthalten. Die Anzahl verschachtelter DNS-Abfragen ist begrenzt. Wer über viele Newsletter-, Support- und Cloudsysteme sendet, sollte die Struktur prüfen statt weitere include-Angaben blind anzuhängen.

DKIM: Ist die Nachricht unverändert und autorisiert?

DKIM ergänzt ausgehende Nachrichten um eine kryptografische Signatur. Der öffentliche Schlüssel liegt als DNS-Eintrag vor, der private Schlüssel bleibt beim sendenden System. Der empfangende Server kann damit prüfen, ob relevante Bestandteile der E-Mail nach dem Versand verändert wurden und ob die Signatur zur Domain gehört.

DKIM arbeitet mit Selektoren. Dadurch können mehrere Versanddienste getrennte Schlüssel verwenden und alte Schlüssel kontrolliert ersetzt werden. Bei einer Migration darf der bisherige DNS-Eintrag nicht zu früh gelöscht werden, weil noch unterwegs befindliche Nachrichten sonst nicht mehr geprüft werden können.

DMARC: Welche Regel gilt bei Fehlern?

DMARC baut auf SPF und DKIM auf. Es verlangt zusätzlich eine Übereinstimmung zwischen der sichtbaren Absenderdomain und der erfolgreich geprüften Domain. Der Eintrag legt fest, ob fehlgeschlagene Nachrichten nur beobachtet, in Quarantäne verschoben oder abgelehnt werden sollen.

• p=none sammelt zunächst Berichte, ohne Nachrichten aktiv abzulehnen.
• p=quarantine signalisiert, verdächtige Nachrichten beispielsweise in Spam einzuordnen.
• p=reject fordert die Ablehnung nicht autorisierter Nachrichten.

Ein sofortiger Sprung auf reject kann legitime Systeme blockieren, wenn noch nicht alle Versandquellen bekannt sind. Deshalb beginnt eine saubere Einführung meist mit Beobachtung und Auswertung.

Die sinnvolle Reihenfolge

1. Alle Systeme erfassen, die mit der Domain E-Mails versenden.
2. SPF konsolidieren und auf technische Grenzen prüfen.
3. DKIM für jedes relevante Versandsystem aktivieren.
4. DMARC zunächst mit Berichten und einer vorsichtigen Richtlinie einführen.
5. Unbekannte oder falsch konfigurierte Quellen korrigieren.
6. Richtlinie schrittweise auf Quarantäne und später Ablehnung erhöhen.

Was diese Verfahren nicht leisten

SPF, DKIM und DMARC prüfen Domain-Autorisierung, nicht die inhaltliche Wahrheit einer Nachricht. Ein kompromittiertes legitimes Konto kann weiterhin signierte schädliche E-Mails senden. Deshalb bleiben starke Passwörter, Mehrfaktor-Authentifizierung, aktuelle Geräte, Spamfilter und aufmerksame Nutzer wichtig.

Zustellbarkeit braucht mehr als DNS

Auch Reputation, Inhalt, Versandmenge, Rückläufer und Empfängerreaktionen spielen eine Rolle. Newsletter müssen Einwilligungen und Abmeldungen sauber behandeln. Geschäftliche Systeme sollten keine großen Massen über normale Postfächer versenden. Eine gute Konfiguration schafft die technische Vertrauensbasis, ersetzt aber keinen verantwortungsvollen Versand.

Zustellung ist ein System, kein einzelner Haken

Ein Postfach funktioniert nur zuverlässig, wenn Benutzerkonto, Kennwort, IMAP/SMTP, TLS und DNS zusammenpassen. Für mobile Geräte und Desktop-Programme sollte IMAP statt POP3 verwendet werden, damit Ordner und Lesestatus synchron bleiben. Der Postausgang benötigt Authentifizierung; offene Relays sind ein Sicherheitsrisiko und werden von seriösen Anbietern blockiert.

Zur Absenderauthentifizierung gehören SPF, DKIM und DMARC. SPF benennt erlaubte Versandquellen, DKIM signiert Nachrichten kryptografisch und DMARC legt fest, wie Empfänger mit nicht bestandenen Prüfungen umgehen und wohin Berichte gesendet werden. Mehrere unkoordiniert angelegte SPF-Einträge sind ungültig; erlaubte Dienste werden in einem einzigen Eintrag zusammengeführt.

Prüfung nach der Einrichtung

• Versand und Empfang intern sowie mit zwei externen Anbietern testen.
• Header einer Testnachricht auf SPF-, DKIM- und DMARC-Ergebnis prüfen.
• Autodiscover-Angaben und Zertifikatsnamen kontrollieren.
• Postfachquote, Weiterleitungen und Abwesenheitsantworten dokumentieren.
• Passwort nicht per unverschlüsselter E-Mail weitergeben und bei Verdacht sofort ersetzen.

Ein Spamfilter sollte zunächst beobachten und markieren. Aggressive Löschregeln ohne Quarantäne führen schnell zum Verlust legitimer Anfragen. Besser ist eine nachvollziehbare Abstufung mit regelmäßiger Kontrolle.

So wird das Thema im Projekt umgesetzt

Für „SPF, DKIM und DMARC verständlich erklärt“ empfiehlt sich ein kontrollierter Ablauf in fünf Phasen. Zuerst wird der aktuelle Zustand dokumentiert: Einstellungen, Abhängigkeiten, Messwerte und betroffene Nutzerwege. Danach wird ein konkretes Ziel formuliert, das sich testen lässt. Es folgt eine möglichst kleine Änderung in einer Testumgebung. Erst nach fachlicher und technischer Prüfung wird sie produktiv übernommen. Der letzte Schritt ist die Dokumentation mit Verantwortlichem, Datum und Rückweg.

1. Bestand aufnehmen: Was funktioniert, was fehlt und welche Systeme sind beteiligt?
2. Risiko bewerten: Welche Nutzer, Daten, Domains oder Geschäftsprozesse könnten betroffen sein?
3. Änderung vorbereiten: Backup, Zugang, Wartungsfenster und Rollback festlegen.
4. Gezielt testen: Happy Path, Fehlersituation, Mobilansicht, Tastatur und Sicherheit prüfen.
5. Beobachten: Protokolle, Statusseite, Rückmeldungen und Messwerte nach der Veröffentlichung kontrollieren.

Häufige Fehler

Viele Probleme entstehen nicht durch fehlendes Wissen über einen einzelnen Menüpunkt, sondern durch ausgelassene Anschlussprüfungen. Dazu gehören ungetestete mobile Zustände, zu kurze Wartezeiten bei DNS, fehlende Backups, unklare Zuständigkeiten, gemeinsam genutzte Adminzugänge und Änderungen direkt im Produktivsystem. Ebenfalls kritisch ist eine Erfolgsmeldung ohne Beleg. Ein grüner Status sollte auf einer überprüfbaren Messung beruhen.

Wann Unterstützung sinnvoll ist

Professionelle Unterstützung lohnt sich, wenn mehrere Systeme zusammenspielen, produktive E-Mail betroffen ist, persönliche Daten verarbeitet werden oder ein Ausfall unmittelbar Anfragen und Umsatz kostet. Scapix verbindet Web- und App-Entwicklung mit Managed Hosting, Monitoring und nachvollziehbarer Dokumentation. Damit bleibt nicht nur die sichtbare Oberfläche, sondern auch der spätere Betrieb beherrschbar.

Entscheidungsmatrix: nicht nur „funktioniert“, sondern passend

Bewerten Sie „SPF, DKIM und DMARC verständlich erklärt“ nicht mit einer einzelnen Ja-Nein-Frage. Eine belastbare Entscheidung betrachtet Nutzen, Risiko, Aufwand, Betrieb und Zugänglichkeit gemeinsam. Nutzen beschreibt, welches konkrete Problem für welche Person gelöst wird. Risiko umfasst Ausfall, Datenverlust, Fehlbedienung und Abhängigkeit von Dritten. Aufwand enthält nicht nur die Einrichtung, sondern auch Tests, Schulung, Wartung und spätere Migration. Betrieb beantwortet, wer Warnungen erhält, Änderungen freigibt und bei einer Störung handeln kann.

Kriterium	Leitfrage	Nachweis
Nutzen	Welche Aufgabe wird schneller, sicherer oder verständlicher?	Konkreter Nutzerweg oder messbares Ziel
Sicherheit	Welche Rechte, Daten und externen Systeme sind betroffen?	Rollen, Protokoll und Rückweg
Barrierefreiheit	Bleibt die Funktion mit Tastatur, Zoom und reduzierter Bewegung nutzbar?	Manueller Test statt nur Scanner
Betrieb	Wer prüft Updates, Warnungen und Kapazität?	Verantwortlicher und Termin
Wirtschaftlichkeit	Welche laufenden Kosten und Abhängigkeiten entstehen?	Gesamtkosten über mindestens zwölf Monate

Fragen für die Abnahme

Die folgenden Fragen verhindern, dass ein Projekt nur auf dem Gerät des Entwicklers gut aussieht. Sie können als kurze Abnahmeliste in einem Ticket oder Protokoll verwendet werden:

• Ist das Ergebnis auf kleinen und großen Bildschirmen ohne horizontales Verschieben nutzbar?
• Erhalten Nutzer nach jeder Aktion eine verständliche Rückmeldung und bleibt der Fokus nachvollziehbar?
• Funktionieren lange Namen, leere Ergebnisse, Fehlermeldungen und langsame Verbindungen?
• Sind Geheimnisse ausschließlich serverseitig gespeichert und personenbezogene Daten auf das Nötige begrenzt?
• Gibt es ein aktuelles Backup und wurde der Wiederherstellungsweg mindestens einmal geprüft?
• Sind Monitoring, Zuständigkeit und ein Wartungszeitpunkt festgelegt?
• Wurden alle betroffenen Inhalte, Rechtstexte und Anleitungen aktualisiert?

Dokumentation, die später Zeit spart

Eine gute Dokumentation ist kurz genug, um gepflegt zu werden, und konkret genug, um im Fehlerfall zu helfen. Sie enthält Zweck, beteiligte Systeme, verantwortliche Person, letzte Änderung, Testschritte und bekannte Grenzen. Screenshots allein reichen nicht, weil Oberflächen sich ändern. Ergänzen Sie deshalb Pfade, IDs und fachliche Regeln in Textform – niemals jedoch Passwörter oder API-Geheimnisse.

Nach einigen Wochen lohnt ein Rückblick: Wird die Funktion verwendet? Haben sich Supportanfragen verändert? Sind Messwerte stabil? Eine Erweiterung ohne erkennbaren Nutzen darf vereinfacht oder entfernt werden. Diese Pflege hält die Website schneller, sicherer und verständlicher als eine dauernde Anhäufung neuer Elemente.