Spezialfälle

E-Mail-Sicherheit: SPF, DKIM und DMARC verständlich erklärt

Was SPF, DKIM und DMARC tun, wie sie CEO-Fraud und Spoofing verhindern, und warum fehlende DNS-Einträge Ihre E-Mails im Spam-Ordner landen lassen.

Aktualisiert am 29.05.2026Lesezeit 6 Min.

Wenn Sie noch nie von SPF, DKIM und DMARC gehört haben, sind Sie in guter Gesellschaft. Die meisten Geschäftsführer kleiner und mittlerer Unternehmen haben das nicht auf dem Radar. Das Thema landet auf dem Tisch, wenn entweder E-Mails im Spam verschwinden oder wenn jemand bemerkt, dass Kriminelle unter dem Namen des Unternehmens E-Mails versenden.

Beides ist unangenehm. Beides lässt sich mit ein paar DNS-Einträgen erheblich entschärfen.

Die Grundidee: Wer darf im Namen Ihrer Domain mailen?

Das E-Mail-Protokoll ist historisch gewachsen und hat einen grundsätzlichen Konstruktionsfehler: Jeder kann technisch eine E-Mail versenden, bei der als Absender eine beliebige Adresse steht. Das System prüft von Haus aus nicht, ob der Absender wirklich der ist, für den er sich ausgibt.

Eine Analogie: Stellen Sie sich vor, jeder könnte Briefe verschicken und als Absender Ihre Firmenadresse draufschreiben, ohne dass die Post das prüft. Der Empfänger sieht einen Brief von Ihrer Firma und geht davon aus, dass er von Ihnen kommt.

Genau das passiert täglich im E-Mail-Verkehr. Angreifer versenden E-Mails mit einer gefälschten Absenderadresse aus Ihrer Domain, weil das Grundprotokoll das zulässt.

SPF, DKIM und DMARC schließen diese Lücke, nicht perfekt, aber wirksam genug, um die allermeisten automatisierten Angriffe abzublocken.

SPF: Welche Server dürfen für Ihre Domain mailen?

SPF steht für Sender Policy Framework. Der Grundgedanke ist einfach: Sie legen in einem DNS-Eintrag fest, welche Mail-Server berechtigt sind, E-Mails von Ihrer Domain zu versenden.

Wenn jemand eine E-Mail empfängt, die behauptet, von ihr-unternehmen.de zu kommen, prüft der empfangende Mailserver: Steht der sendende Server in der SPF-Liste dieser Domain? Wenn ja, ist die E-Mail legitim aus Sicht des Absenders. Wenn nein, gibt es einen Verdacht auf Spoofing.

Ein SPF-Eintrag sieht im DNS so aus:

v=spf1 include:spf.protection.outlook.com -all

Das bedeutet: E-Mails von dieser Domain dürfen nur von Microsofts Exchange Online-Servern kommen. Der -all am Ende sagt: Alles andere ablehnen.

Was in Ihren SPF-Eintrag muss, hängt davon ab, welche Dienste E-Mails in Ihrem Namen versenden. Der eigene Mailserver, Microsoft 365, ein Newsletter-Dienst, ein CRM-System, das automatische E-Mails schickt. Wer einen Dienst vergisst, riskiert, dass dessen E-Mails im Spam landen.

DKIM: Eine digitale Unterschrift für jede E-Mail

DKIM steht für DomainKeys Identified Mail. Es funktioniert über ein kryptografisches Schlüsselpaar. Der Mailserver, der eine E-Mail verschickt, hängt eine digitale Signatur an die E-Mail an. Der öffentliche Schlüssel, mit dem diese Signatur geprüft werden kann, liegt im DNS Ihrer Domain.

Wenn der empfangende Mailserver die E-Mail erhält, liest er die Signatur, holt den öffentlichen Schlüssel aus dem DNS und prüft, ob die E-Mail wirklich vom behaupteten Mailserver stammt und ob der Inhalt unterwegs verändert wurde.

Das bietet zwei Dinge gleichzeitig: Authentizitätsprüfung (kam die E-Mail wirklich von Ihrem Server?) und Integritätsprüfung (wurde die E-Mail auf dem Weg manipuliert?).

DKIM-Signaturen sind für den Nutzer unsichtbar. Sie laufen vollständig im Hintergrund. Bei Microsoft 365 ist DKIM-Signing über die Exchange-Verwaltungskonsole aktivierbar und erfordert zusätzlich zwei CNAME-Einträge im DNS.

DMARC: Die Richtlinie, die beides zusammenbringt

DMARC steht für Domain-based Message Authentication, Reporting and Conformance. Es baut auf SPF und DKIM auf und gibt vor, was passieren soll, wenn eine E-Mail die SPF- oder DKIM-Prüfung nicht besteht.

Ein einfacher DMARC-Eintrag:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@ihr-unternehmen.de

Das bedeutet: E-Mails, die SPF oder DKIM nicht bestehen, sollen in Quarantäne (Spam-Ordner). Reports über fehlgeschlagene Prüfungen sollen an die genannte Adresse geschickt werden.

Die drei DMARC-Policies:

p=none: Nur Monitoring. E-Mails werden trotzdem zugestellt, aber Reports werden generiert. Guter Einstieg, um zu sehen, was im eigenen Mail-Strom passiert, bevor man strengere Regeln aktiviert.

p=quarantine: Verdächtige E-Mails kommen in den Spam-Ordner des Empfängers.

p=reject: Verdächtige E-Mails werden vollständig abgelehnt und nicht zugestellt.

Für KMU, die das gerade einrichten, empfiehlt sich der Weg none zu quarantine zu reject. Erst schauen, was die Reports zeigen, sicherstellen, dass alle eigenen Dienste korrekt in SPF stehen, dann schrittweise verschärfen.

DMARC-Reports lesen: Was die Berichte zeigen

Wer einen DMARC-Eintrag mit rua (Reporting URI) konfiguriert, bekommt täglich oder wöchentlich XML-Berichte von empfangenden Mailservern. Diese Berichte zeigen, welche Server E-Mails mit Ihrer Domain als Absender verschickt haben und ob die Prüfungen bestanden wurden.

Das klingt trocken, ist aber praktisch nützlich. Die Reports zeigen zum Beispiel, wenn ein Drittanbieter-Dienst E-Mails in Ihrem Namen verschickt, der nicht im SPF-Eintrag steht. Oder wenn jemand aktiv versucht, Ihre Domain für Spam zu missbrauchen.

DMARC-Report-Analyse-Tools wie DMARC Analyzer oder Postmark DMARC machen die XML-Berichte lesbar und zeigen die Ergebnisse übersichtlich. ITCC übernimmt die Einrichtung und Auswertung der Reports als Teil der laufenden E-Mail-Sicherheitsbetreuung.

Was das mit CEO-Fraud zu tun hat

CEO-Fraud ist eine der häufigsten Betrugsformen im B2B-Bereich. Das Prinzip: Ein Mitarbeiter bekommt eine E-Mail, die scheinbar vom Geschäftsführer kommt, mit der Aufforderung, dringend eine Überweisung zu tätigen oder vertrauliche Informationen herauszugeben.

Die E-Mail kommt nicht wirklich vom Geschäftsführer. Sie kommt von einem Angreifer, der die Domain des Unternehmens als Absender eingesetzt hat. Weil das grundlegende E-Mail-Protokoll das zulässt, sieht die E-Mail für den Empfänger echt aus.

DMARC mit p=reject macht genau das schwerer. Wenn der empfangende Mailserver prüft und feststellt, dass die E-Mail von keinem autorisierten Server kommt und keine gültige DKIM-Signatur hat, wird sie abgelehnt, bevor sie im Postfach des Mitarbeiters landet.

Das verhindert nicht jeden Betrug. Angreifer können auch Domains registrieren, die der echten Domain ähneln (zum Beispiel ihr-unternehmen-gmbh.de statt ihr-unternehmen.de) und diese korrekt konfigurieren. Aber die einfachste und häufigste Angriffsvariante, die direkte Verwendung Ihrer Domain, wird damit unterbunden.

Zustellbarkeit: Warum korrekte Einträge auch Ihre eigenen Mails besser zustellen

Ein häufig vernachlässigter Aspekt: Korrekt konfigurierte SPF-, DKIM- und DMARC-Einträge verbessern die Zustellbarkeit Ihrer eigenen ausgehenden E-Mails.

Große E-Mail-Anbieter wie Gmail, Microsoft und andere prüfen diese Einträge zunehmend als Kriterium für die Spam-Klassifizierung. Eine Domain ohne DMARC-Eintrag oder mit fehlerhaftem SPF-Eintrag wird von manchen Empfängersystemen misstrauischer behandelt.

Das betrifft nicht nur Newsletter und Marketingmails, sondern reguläre Geschäftsmails. Wenn ein Angebot beim Kunden im Spam landet, weil die DNS-Einträge nicht stimmen, ist das ein Problem, das sich einfach beheben lässt.

Typische Fehler bei der Einrichtung

Zu viele SPF-Einträge. DNS erlaubt für eine Domain nur einen SPF-TXT-Eintrag. Wer mehrere anlegt, erzeugt einen ungültigen Zustand.

SPF-DNS-Lookups-Limit überschritten. Ein SPF-Eintrag darf maximal 10 DNS-Lookups auslösen. Wer viele include:-Einträge hat, kommt schnell ans Limit.

DKIM für alle sendenden Dienste fehlt. DKIM muss für jeden Dienst aktiviert werden, der E-Mails verschickt. Nur für den Hauptmailserver zu konfigurieren und den Newsletter-Dienst zu vergessen, führt zu halbem Schutz.

DMARC auf reject gesetzt ohne vorherige Testphase. Wer direkt mit reject startet, ohne vorher im none-Modus zu beobachten, was an E-Mails durch den eigenen Strom geht, riskiert, legitime E-Mails zu blockieren.

ITCC richtet SPF, DKIM und DMARC für KMU ein und begleitet den Weg von der initialen Konfiguration bis zur vollständigen Policy. Das ist kein großes Projekt, aber eines, das sauber gemacht werden sollte.

Häufige Fragen

Der nächste Schritt

Der nächste Schritt ist ein 30-Minuten-Gespräch.

Kostenlos. Unverbindlich. Maximal 30 Minuten.