Auf dieser Seite

Für ERP-Verantwortliche und IT-Administratoren, die wissen wollen, wie die drei Mechanismen technisch zusammenspielen – und wie man die Mail-Authentifizierungsqualität einer fremden Lieferantendomain mit wenigen DNS-Abfragen objektiv bewertet. Den kaufmännischen Kontext bieten die Lösungen im Überblick.

Hintergrund und Geschäftsperspektive: SPF, DKIM und DMARC – was das für Ihren Rechnungseingang bedeutet

SPF: Record-Syntax und das 10-Lookup-Limit

SPF (Sender Policy Framework, RFC 7208) veröffentlicht als DNS-TXT-Record, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden. Ein typischer Record:

v=spf1 ip4:203.0.113.5 include:_spf.versanddienst.de mx -all

Mechanismen und ihre Bedeutung

Mechanismus DNS-Lookup? Bedeutung
ip4: / ip6: nein Direkte IP-Angabe – kein Lookup, daher effizient
include: ja (1) Verweist auf SPF-Record einer anderen Domain
a: / mx: ja (je 1) A- bzw. MX-Record der genannten Domain
ptr: ja (1) Reverse-DNS – gilt als veraltet, nicht empfohlen
all nein Catch-All: -all = Hardblock, ~all = Softfail, +all = Pass für alles

Das 10-Lookup-Limit (RFC 7208, §4.6.4)

Pro SPF-Auswertung dürfen maximal 10 Mechanismen ausgewertet werden, die einen DNS-Lookup erfordern. Das Limit gilt für die gesamte Auflösungskette – inklusive transitiver include:-Verweise. Wer mehrere Versanddienste über include: einbindet (CRM, ERP-Ausgang, Marketing-Automation, Newsletter), überschreitet das Limit leicht.

Folge: Der empfangende Server antwortet mit permerror. Viele Empfänger-Mailserver behandeln das wie einen SPF-Fail – und wenn DMARC daneben keinen aligned DKIM-Pass liefert, kann die Mail abgelehnt werden.

Zusätzlich gilt ein Void-Lookup-Limit von 2: DNS-Abfragen ohne verwertbares Ergebnis zählen separat. Mehr als 2 davon → ebenfalls permerror.

Wichtig: Eine Domain darf exakt einen SPF-TXT-Record haben. Zwei SPF-Records auf derselben Domain führen sofort zu permerror (RFC 7208, §3.2).

Diagnose-Tool: nslookup -type=TXT beispiel.de liefert den Record. Die Lookup-Tiefe zählt ein SPF-Prüfer wie MXToolbox automatisch.

DKIM: Selektoren und Schlüsselpaar

DKIM (DomainKeys Identified Mail, RFC 6376) signiert ausgehende Mails kryptografisch. Der private Schlüssel liegt beim sendenden Mailserver oder Versanddienst. Der öffentliche Schlüssel wird per DNS veröffentlicht und ist von jedem abfragbar.

DNS-Pfad und Record-Format

Der öffentliche Schlüssel steht unter:

<selektor>._domainkey.<domain>

Beispiel: google._domainkey.beispiel.de

Record-Inhalt (TXT):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
Tag Bedeutung
v=DKIM1 Versionsmarker, obligatorisch
k=rsa Algorithmus – RSA mit 2048 Bit ist Standard; k=ed25519 ist moderner und empfohlen
p= Base64-kodierter öffentlicher Schlüssel
t=s Subdomain-Signing deaktiviert (optional)

Selektoren – mehrere parallel möglich

Eine Domain kann beliebig viele DKIM-Selektoren veröffentlichen. Das hat zwei praktische Vorteile:

  • Mehrere Versanddienste (CRM, ERP-Ausgang, Newsletter) bekommen je einen eigenen Selektor mit eigenem Schlüsselpaar – getrennte Verantwortlichkeit, unabhängig rotierbar.
  • Key Rotation: Der alte Selektor bleibt aktiv, bis alle unterwegs befindlichen Mails zugestellt sind. Dann wird er deaktiviert – nicht gelöscht, sondern p= auf leer setzen, damit der Empfänger weiß: war mal gültig, jetzt zurückgezogen.

Was der Empfänger prüft

Der DKIM-Signature:-Header der eingehenden Mail enthält u. a.:

d=beispiel.de; s=google; bh=<Body-Hash>; h=From:To:Subject:Date; b=<Signatur>

Der Empfänger löst google._domainkey.beispiel.de auf, holt den Public Key und verifiziert b= gegen die im h=-Feld aufgelisteten Header-Felder. Stimmt die Signatur: DKIM-Pass. Fehlt der DNS-Eintrag oder stimmt die Signatur nicht: DKIM-Fail.

Kritisch: Der From:-Header muss im h=-Feld aufgelistet sein, damit das DMARC-Alignment greifen kann. Fehlt er dort, ist DKIM für DMARC wertlos.

DMARC: Policy und Alignment

DMARC (RFC 9989) verknüpft die Ergebnisse von SPF und DKIM mit einer Policy für den Empfänger und gibt vor, wohin Berichte gesendet werden. (RFC 7489 von 2015 wurde im Mai 2026 durch RFC 9989 abgelöst; die Policy-Logik bleibt inhaltlich weitgehend unverändert.)

Record-Struktur

Veröffentlicht als TXT-Record unter _dmarc.<domain>:

v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc@beispiel.de; pct=100
Tag Werte Bedeutung
p= none / quarantine / reject Was bei Fail passiert
adkim= r / s DKIM-Alignment: relaxed / strict
aspf= r / s SPF-Alignment: relaxed / strict
rua= mailto:... Ziel für aggregierte XML-Reports
ruf= mailto:... Ziel für forensische Reports (Einzelmails)
pct= 0–100 Anteil der Mails, auf den die Policy angewendet wird
sp= none / quarantine / reject Subdomain-Policy (Standard: Hauptpolicy erben)

Policy (p=)

  • p=none – Monitoring-Modus. Keine Auswirkung auf Zustellung. Reports werden gesendet. Kein aktiver Schutz – die Domain bleibt spoofbar.
  • p=quarantine – Mails, die den Alignment-Check nicht bestehen, landen im Spam-Ordner. Basisschutz.
  • p=reject – Empfangende Server lehnen die Mail auf SMTP-Ebene ab. Stärkste Schutzwirkung. Google und Yahoo verlangen seit Februar 2024 von Massenversendern (>5.000 Mails/Tag) einen DMARC-Record – Mindest-Policy p=none, empfohlen p=quarantine oder p=reject (dmarcian). Microsoft zog ab Mai 2025 nach (Outlook/Hotmail/Live, Microsoft TechCommunity).

Alignment – das entscheidende Verbindungselement

Alignment prüft, ob die From:-Domain (die der Leser sieht) mit der per SPF oder DKIM authentifizierten Domain übereinstimmt. Ohne diesen Check könnte jemand From: rechnung@lieferant.de schreiben, aber über einen beliebigen Server senden – und SPF oder DKIM würden trotzdem passen, weil sie nur die technische Envelope-Domain prüfen.

Relaxed Alignment (r): Subdomain-Abgleich genügt. mail.beispiel.de alignt mit beispiel.de, weil sie die gleiche organisatorische Domain teilen.

Strict Alignment (s): Exakter Match erforderlich. mail.beispiel.de alignt nicht mit beispiel.de.

Fehlen adkim= und aspf= im Record, gilt jeweils r (relaxed) als Default.

DMARC gilt als bestanden, wenn entweder SPF oder DKIM aligned-pass liefert – nicht notwendigerweise beide. Wer Mails über Drittdienste (ESP, ERP-Ausgang) sendet, muss sicherstellen, dass mindestens einer der Mechanismen aligned passt: entweder den Drittdienst im SPF-Record eintragen und aspf-Alignment sicherstellen, oder den Drittdienst DKIM mit der eigenen Domain signieren lassen.

pct= – schrittweiser Rollout

pct=10; p=quarantine quarantisiert zunächst nur 10 % der nicht bestandenen Mails. Das ermöglicht einen kontrollierten Übergang von p=none zu p=reject, ohne den laufenden Mailverkehr abrupt zu unterbrechen.

Aggregierte Reports (rua) auswerten

rua=mailto:dmarc-reports@beispiel.de weist empfangende Mailserver an, täglich XML-Reports zu senden. Inhalt eines Reports:

  • Quell-IP der Mails
  • Anzahl der Mails von dieser IP im Berichtszeitraum
  • SPF-Ergebnis und SPF-Alignment-Ergebnis
  • DKIM-Ergebnis und DKIM-Alignment-Ergebnis
  • Angewandte DMARC-Policy

Die Berichte kommen als .xml.gz-Anhang. Für manuelle Auswertung reicht ein XML-Viewer; für kontinuierliches Monitoring empfiehlt sich ein DMARC-Analyse-Dienst.

Typische Analysemuster

  1. Unbekannte IPs mit SPF-Fail: Vergessener Versanddienst – SPF-Record aktualisieren.
  2. Eigene IPs mit DKIM-Fail: Selektor abgelaufen oder Key-Rotation nicht abgeschlossen.
  3. Fremde IPs mit hohem Volumen bei p=none-Policy: Aktiver Spoofing-Versuch – Policy auf quarantine oder reject erhöhen.

Empfohlener Rollout

Das BSI empfiehlt SPF, DKIM und DMARC als Stand der Technik für E-Mail-Authentifizierung (BSI TR-03182, Februar 2024). Ein bewährter Rolloutpfad:

  1. Mit p=none starten und rua= konfigurieren.
  2. Reports 2–4 Wochen auswerten, legitime Versandquellen identifizieren.
  3. Auf p=quarantine; pct=10 erhöhen – Schritt für Schritt bis pct=100.
  4. Nach Stabilisierung auf p=reject; pct=100 wechseln.

Fremde Lieferantendomain objektiv bewerten

Das Entscheidende für den Rechnungseingang: Nicht die eigene Domain ist das Risiko, sondern die des Lieferanten. Wer eine Rechnung von buchhaltung@lieferant.de erhält, kann per DNS in Sekunden prüfen, ob diese Domain gegen Spoofing gesichert ist – oder nicht.

Laut PowerDMARC Germany DMARC Report 2025 fehlt bei mehr als einem Drittel der deutschen Organisationen jeglicher DMARC-Record. Von jenen, die einen haben, stehen über 80 % auf p=none – ohne jede Schutzwirkung.

Schritt 1: SPF prüfen

Windows (nslookup):

nslookup -type=TXT lieferant.de

Linux/macOS (dig):

dig TXT lieferant.de +short

Suche nach einem Record, der mit v=spf1 beginnt.

Befund Einschätzung
-all am Ende Hardblock – stark
~all am Ende Softfail – legitime Mails zugestellt, Fakes nur markiert
+all oder fehlendes all Jeder Server darf senden – kritisch
Kein SPF-Record Keine Zustellbeschränkung – Domain frei spoofbar
Viele include:-Einträge Lookup-Limit-Risiko prüfen

Schritt 2: DKIM prüfen

Den Selektor kennt man von außen nicht. Häufige Selektornamen zum Ausprobieren: default, google, mail, selector1, selector2, k1.

nslookup -type=TXT default._domainkey.lieferant.de
nslookup -type=TXT selector1._domainkey.lieferant.de

Kein Ergebnis bei allen gängigen Selektoren: Die Domain signiert entweder nicht per DKIM, oder nutzt ungewöhnliche Selektornamen. Für eine vollständige Prüfung empfiehlt sich ein DKIM-Lookup-Tool, das systematisch vorgeht (EasyDMARC DKIM-Lookup).

Schritt 3: DMARC prüfen

Windows:

nslookup -type=TXT _dmarc.lieferant.de

Linux/macOS:

dig TXT _dmarc.lieferant.de +short
p=-Wert Schutzwirkung
p=reject Maximalschutz – Spoofing-Mails werden auf SMTP-Ebene abgelehnt
p=quarantine Basisschutz – Fälschungen landen im Spam
p=none Monitoring only – Domain ist spoofbar
Kein _dmarc-Record Keine Policy – vollständig ungeschützt

Schnell-Checkliste für den IT-Bericht

Prüfpunkt Befund „gut" Befund „Risiko"
SPF-Record vorhanden ja, endet auf -all fehlt oder +all
SPF-Lookup-Count ≤ 10 > 10 → permerror-Risiko
DKIM-Selektor auflösbar Public Key im DNS kein Eintrag gefunden
DMARC-Record p=quarantine oder p=reject p=none oder fehlt
DMARC-Alignment adkim= und aspf= gesetzt fehlt (relaxed-Default greift)
rua=-Adresse vorhanden fehlt – kein Reporting möglich

Zum Weitergeben an Ihre IT

Wenn Sie als kaufmännische Leitung oder ERP-Verantwortliche das Ergebnis intern eskalieren, hier die Zusammenfassung als Prüfauftrag:

Prüfauftrag: Mail-Authentifizierungsstatus der Lieferantendomains [Domain 1, Domain 2, …]

Methodik: DNS-TXT-Abfragen auf SPF (v=spf1-Record unter der Domain), DKIM (<selektor>._domainkey.<domain>) und DMARC (_dmarc.<domain>).

Mindestanforderung für als vertrauenswürdig eingestufte Absenderdomains:

  • SPF-Record vorhanden, endet auf -all
  • SPF-Lookup-Count ≤ 10
  • DKIM-Selektor auflösbar, Schlüssel mindestens 2048-Bit-RSA oder Ed25519
  • DMARC mit p=quarantine oder p=reject

Empfehlung bei p=none oder fehlendem Record: Lieferant auf die Konfigurationslücke hinweisen. Bis zur Behebung Rechnungen aus diesem Absenderbereich mit erhöhter manueller Prüfung behandeln – insbesondere bei abweichenden Kontodaten oder IBAN-Änderungen.

Wie der Dienst diesen Prüfschritt in den Rechnungseingang integriert und sichtbar macht: Sicherheit und Datenverarbeitung

Zum Risiko gefälschter Rechnungen und zur Haftungsfrage im Mittelstand: Krise und Haftung