SPF, DKIM, DMARC: Fälschungsrisiko im Rechnungseingang
Drei DNS-Einträge (SPF, DKIM und DMARC) entscheiden darüber, ob sich jemand als Ihr Lieferant ausgeben kann. Die meisten KMU kennen diese Einträge nicht. Viele Lieferanten haben sie nicht eingerichtet. Der Dienst macht das sichtbar, ohne IT-Kenntnisse, ohne Konfiguration.
- BSI empfiehlt SPF, DKIM und DMARC als Stand der Technik (TR-03182)
- Ca. 32 % der deutschen Organisationen ohne DMARC-Schutz
- Prüfung ohne eigene DNS-Kenntnisse möglich
- Kein Einrichten, nur Prüfen und Entscheiden
Warum eine E-Mail-Adresse kein Echtheitsbeweis ist
Eine Rechnung von buchhaltung@lieferant.de sieht echt aus. Das bedeutet nichts. Das E-Mail-Protokoll erlaubt es jedem, einen beliebigen Absender einzutragen, wie ein Brief mit gefälschtem Absender-Aufkleber. Technisch ist das kein Aufwand, es erfordert keine Hacker-Kenntnisse.
Drei DNS-Einträge schließen diese Lücke, aber nur wenn der Absender sie korrekt gesetzt hat:
- SPF legt fest, welche Server für eine Domain E-Mails versenden dürfen (RFC 7208).
- DKIM versieht ausgehende Mails mit einer kryptografischen Signatur; der Empfänger prüft sie gegen einen öffentlichen DNS-Schlüssel (RFC 6376).
- DMARC verbindet beides mit einer klaren Handlungsregel: Was passiert mit Mails, die die Prüfung nicht bestehen? Ablehnen, Quarantäne oder ignorieren (RFC 9989)?
Fehlt DMARC oder steht die Policy auf p=none, kann jeder E-Mails im Namen dieser Domain versenden, und kein Empfänger bemerkt es automatisch.
Was das für Ihren Rechnungseingang bedeutet
Laut dem PowerDMARC Germany DMARC Adoption Report 2025 haben rund 32 % der deutschen Organisationen keinen DMARC-Eintrag. Von jenen mit einem Eintrag stehen über 80 % auf p=none, das bedeutet: Monitoring ohne Schutzwirkung. Eine gefälschte Rechnung von dieser Domain würde Ihren Mailserver unbemerkt passieren.
Das ist kein theoretisches Szenario. Zahlungsumleitung per gefälschter Lieferanten-Mail gehört zu den häufigsten Betrugsformen im Rechnungseingang, bekannt als „CEO-Fraud" oder „Fake-Supplier"-Angriff.
Wer Rechnungen per E-Mail freigibt, ohne die Absenderdomain seiner Lieferanten zu kennen, verlässt sich auf einen offenen Briefkasten.
Das BSI empfiehlt SPF, DKIM und DMARC als Stand der Technik für alle E-Mail-Dienste (TR-03182, Februar 2024).
Was der Dienst sichtbar macht
Für jede eingehende E-Mail-Rechnung prüft der Dienst automatisch, ob die Absenderdomain SPF, DKIM und DMARC korrekt konfiguriert hat und wie streng die Policy eingestellt ist.
Sie sehen auf einen Blick:
| Eintragstyp | Was geprüft wird | Was „grün" bedeutet |
|---|---|---|
| SPF | Darf dieser Server für die Domain senden? | Autorisierter Versand-Server |
| DKIM | Ist die Signatur gültig und unvergälscht? | Nachricht wurde nicht verändert |
| DMARC | Welche Policy greift bei Prüfungsfehlern? | p=reject oder p=quarantine |
Das erfordert keine IT-Kenntnisse auf Ihrer Seite und keine Änderungen an Ihrer eigenen DNS-Konfiguration. Sie prüfen: Der Dienst arbeitet im Hintergrund.
Mehr zu den Sicherheitsgrundlagen des Dienstes: Sicherheit im Überblick
Zwei Perspektiven auf dasselbe Thema
Wie funktioniert das technisch?
SPF-Record-Syntax, DKIM-Selektoren, DMARC-Policy-Typen, Alignment-Modi und Reporting: für ERP-Verantwortliche, IT und Steuerberater, die fremde Domains selbst auslesen und bewerten wollen.
Zum Technik-Post →
Ich habe dieses Problem. Was jetzt?
Alltagsnahe Erklärung für Buchhaltung und Geschäftsführung: was SPF, DKIM und DMARC bedeuten, warum das mit Ihrer Rechnung zusammenhängt und wie Sie erkennen, ob ein Lieferant gefährdet ist.
Zum Buchhaltungs-Post →
Müssen meine Lieferanten SPF, DKIM und DMARC selbst einrichten?
Ja. Diese Einträge werden vom **Absender** in seiner DNS-Zone gesetzt. Als Empfänger können Sie nicht eingreifen, aber Sie können prüfen, ob ein Lieferant die Einträge korrekt konfiguriert hat, und ihn bei Bedarf ansprechen.
Reicht SPF allein nicht aus?
Nein. SPF allein schützt unvollständig: Es prüft nur den Versand-Server, nicht den sichtbaren Absender im E-Mail-Client. Erst die Kombination aus SPF, DKIM **und** DMARC mit einer aktiven Policy (`quarantine` oder `reject`) verhindert zuverlässig, dass jemand im Namen einer Domain fälscht.
Was bedeutet `p=none` bei DMARC?
`p=none` bedeutet: Der DMARC-Eintrag ist vorhanden, bewirkt aber nichts. Mails, die die Prüfung nicht bestehen, werden trotzdem zugestellt. Es handelt sich um einen reinen Beobachtungs-Modus ohne Schutzwirkung: Die Domain bleibt spoofbar.
Bin ich als Empfänger für die DMARC-Konfiguration meiner Lieferanten verantwortlich?
Nein. Die Konfiguration liegt beim Absender. Was Sie tun können: prüfen, ob ein Lieferant das Minimum konfiguriert hat, und daraus eine Risikoeinschätzung für Ihren Rechnungsfreigabeprozess ableiten.
Seit wann ist das ein Thema?
Seit Februar 2024 verlangen Google und Yahoo von Massenversendern SPF, DKIM und DMARC als Voraussetzung für sichere Zustellung. Microsoft zog 2025 nach. Das Thema ist damit aus dem Nischenbereich der IT-Administratoren herausgewachsen und betrifft jeden, der Geschäftsmails empfängt.
Gibt es eine gesetzliche Pflicht für DMARC?
Für Unternehmen als Endkunden besteht im Regelfall keine direkte gesetzliche Verpflichtung zur DMARC-Konfiguration. Das BSI empfiehlt die Einrichtung als Stand der Technik (TR-03182). Fragen zur konkreten Haftung im Schadensfall klären Sie im Zweifel mit Ihrem Rechtsanwalt oder IT-Sicherheitsberater.
Jede freigegebene Rechnung, belegbar geprüft
Wer den DMARC-Status seiner Lieferanten kennt, bevor er zahlt, schließt die häufigste Lücke im Rechnungsfreigabeprozess. Gegenüber Bank, Versicherung und Prüfer lässt sich dann nachweisen, dass die Echtheitsprüfung dokumentiert war, nicht rekonstruiert.
Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.
