Kurzantwort: Drei Einträge, drei Aufgaben
Welche Server dürfen für deine Domain senden?
Wurde die Nachricht unterwegs verändert?
Was passiert bei fehlender Authentifizierung?
Die drei Verfahren sind keine Garantie für den Posteingang. Sie beweisen, dass eine Mail von einem autorisierten Absender kommt und nicht unterwegs verändert wurde. Reputation, Inhalt und Empfänger-Feedback entscheiden weiterhin mit.
1. Warum E-Mail-Authentifizierung wichtig ist
Ohne Authentifizierung kann jede Person den Namen deiner Domain im Absender fälschen. Das wird für Phishing, Rechnungsbetrug und Spam missbraucht – und schadet langfristig deiner Domain-Reputation. Große Mailprovider verlangen für den Versand an ihre Nutzer zunehmend SPF, DKIM und DMARC. Wer Newsletter, Rechnungen oder Systemmails versendet, sollte die Einträge nicht dem Zufall überlassen.
Wichtig ist die Unterscheidung: Authentifizierung ist kein Spamfilter und keine Verschlüsselung. Sie beantwortet die Frage „Darf dieser Server diese Mail im Namen dieser Domain senden?“ – nicht „Ist diese Mail erwünscht oder sicher?“.
2. SPF: Wer darf senden?
SPF (Sender Policy Framework) ist ein DNS-TXT-Eintrag. Er listet die Server und Dienste, die für deine Domain senden dürfen. Ein Empfänger vergleicht die IP-Adresse des sendenden Servers mit dieser Liste.
example.at. TXT "v=spf1 include:_spf.example.net -all"Wichtig: Pro Domain gibt es nur einen SPF-Eintrag. Mehrere SPF-Records führen zu einem PermError. Der Eintrag hat außerdem ein Limit von zehn DNS-Lookups; viele Includes können dieses Limit sprengen. Und: SPF prüft den Envelope-Absender (Return-Path), nicht automatisch die sichtbare From-Adresse.
3. DKIM: Ist die Mail unverändert?
DKIM (DomainKeys Identified Mail) signiert die Nachricht mit einem privaten Schlüssel. Der passende öffentliche Schlüssel steht in einem DNS-Eintrag unter einem Selector. Der Empfänger kann damit prüfen, ob die signierten Header und Inhalte unterwegs verändert wurden.
selector._domainkey.example.at. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Der private Schlüssel bleibt auf dem Mailserver oder beim Versanddienst. Veröffentliche niemals den privaten Schlüssel im DNS. Für 2048-Bit-Schlüssel gibt es bei manchen DNS-Anbietern Längenlimits; dann muss der Eintrag aufgeteilt oder ein anderer Selector verwendet werden. Rotiere Schlüssel regelmäßig und dokumentiere, welcher Dienst welchen Selector nutzt.
4. DMARC: Was passiert bei einem Fehler?
DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet SPF und DKIM. Es prüft, ob die sichtbare From-Domain mit der authentifizierten Domain übereinstimmt (Alignment) und legt eine Policy fest.
_dmarc.example.at. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.at; adkim=s; aspf=s; pct=100"- ✓ p=none: nur beobachten, keine Zustellungsänderung.
- ✓ p=quarantine: verdächtige Mails in Quarantäne/Spam verschieben.
- ✓ p=reject: unauthentifizierte Mails ablehnen.
- ✓ rua: aggregierte Reports an eine Mailadresse senden.
- ✓ adkim/aspf: striktes oder lockeres Alignment festlegen.
Starte mit p=none und werte die Reports aus. Erst wenn alle legitimen
Versandwege erkannt und authentifiziert sind, solltest du auf quarantine und später
reject wechseln. Ein sofortiges reject kann Newsletter, Weiterleitungen oder
Systemmails abbrechen.
5. Das Zusammenspiel – und ein Beispiel
Eine typische Prüfung läuft so: Der Empfänger sieht eine Mail von office@example.at.
SPF prüft die IP des sendenden Servers, DKIM prüft die Signatur, DMARC vergleicht die
authentifizierte Domain mit der sichtbaren From-Domain und wendet die Policy an.
| Eintrag | Zweck | Typischer Fehler |
|---|---|---|
| SPF | Autorisierte Sender-IPs | Zwei SPF-Records oder Lookup-Limit überschritten |
| DKIM | Signatur und Integrität | Falscher Selector oder abgelaufener Schlüssel |
| DMARC | Alignment und Policy | Zu früh auf reject, Reports nicht ausgewertet |
Die Beispiele sind Platzhalter. Kopiere keine fremden Werte und teste Änderungen zuerst
mit einer kleinen Teilmenge (pct) und aussagekräftigen Reports.
6. Typische Fehler
Pro Domain nur ein SPF-TXT-Eintrag; Includes sauber zusammenführen.
SPF/DKIM müssen zur sichtbaren From-Domain passen, nicht nur irgendwo gültig sein.
SPF bricht bei manchen Weiterleitungen; DKIM bleibt oft stabiler.
Newsletter, CRM, Shop und Zeiterfassung senden oft über eigene Dienste.
Ohne rua-Adresse bleibt DMARC ein Blindflug.
Erst beobachten, dann quarantine, dann reject – nicht umgekehrt.
7. Archivierung, Migration und Betrieb
Authentifizierung ist nur ein Teil einer sauberen E-Mail-Infrastruktur. Dazu gehören Postfächer, Aliase, Spamfilter, TLS, Backups und ein dokumentierter Offboarding-Prozess. Bei einer Migration werden Mailboxen, Kalender und Kontakte übernommen, MX- und DNS-Einträge geprüft und die Umstellung begleitet.
Archivierung ist mehr als ein Postfach-Backup: Es braucht definierte Aufbewahrungsfristen, Export- und Wiederherstellungswege sowie klare Zuständigkeiten. Ob und wie lange du E-Mails aufbewahren musst, hängt von Branche und Rechtsform ab – das ist keine Rechtsberatung. Wir richten die technische Archivierung nach deinen Vorgaben ein und dokumentieren den Prozess.
8. Checkliste für die Einrichtung
Die Checkboxen sind eine Erinnerung, kein gespeicherter Status.
Fragen zu SPF, DKIM und DMARC
SPF ist eine DNS-Liste der Server, die für deine Domain senden dürfen. DKIM signiert jede E-Mail kryptografisch, damit Empfänger erkennen können, ob die Nachricht verändert wurde. DMARC verbindet beide Verfahren, prüft die Übereinstimmung mit deiner Domain und legt fest, was mit unauthentifizierten Mails passieren soll.
Nein. SPF prüft nur den Envelope-Absender und kann bei Weiterleitungen oder komplexen Versandwegen brechen. Für belastbare Ergebnisse brauchst du SPF, DKIM und DMARC zusammen – und eine regelmäßige Auswertung der DMARC-Reports.
p=none ist die Beobachtungsstufe: DMARC prüft die Authentifizierung, verschiebt aber keine Mails in Quarantäne und lehnt sie nicht ab. Sie ist der richtige Start, um Absender, Reports und Fehlkonfigurationen kennenzulernen. Erst danach solltest du auf quarantine oder reject wechseln.
Authentifizierung beweist nur, dass eine Mail von einem autorisierten Absender stammt. Sie sagt nichts über Inhalte, Reputation, Beschwerden, Blocklisten, Versandvolumen oder Empfänger-Feedback. Auch Spamfilter, Anhänge, Links und eine junge Domain können die Zustellung beeinflussen.
Das ist riskant. Wenn noch unbekannte Versandwege, Newsletter-Tools oder Weiterleitungen existieren, können legitime Mails verloren gehen. Der übliche Weg ist: p=none, Reports auswerten, alle legitimen Absender erfassen, dann schrittweise quarantine und später reject.
Nein. Die drei Verfahren authentifizieren den Absender und die Integrität der Nachricht, sie verschlüsseln sie nicht. Transportverschlüsselung läuft über TLS zwischen den Mailservern. Für Ende-zu-Ende-Vertraulichkeit brauchst du zusätzlich eine Ende-zu-Ende-Verschlüsselung.
Das hängt von der Zahl der Domains, Postfächer und Versandwege ab. Bei einer überschaubaren Konfiguration ist der Aufwand oft klein; bei mehreren Systemen, Migrationen oder Archivierung wird individuell kalkuliert. Du bekommst nach einer kurzen Prüfung einen Festpreis für den vereinbarten Umfang.