Lieferanten-Domains per DNS auf SPF/DKIM/DMARC prüfen

Auf dieser Seite

• 1. Welche DNS-Records über die Fälschbarkeit einer Domain entscheiden
• SPF: Sender Policy Framework (RFC 7208)
• DMARC: Domain-based Message Authentication, Reporting and Conformance (RFC 7489)
• DKIM: DomainKeys Identified Mail (RFC 6376)
• 2. DNS-Lookups im Browser: DNS-over-HTTPS (DoH)
• 3. Bewertungsmatrix: Was ist „sicher genug"?
• 4. Batch-Prüfung ganzer Lieferantenlisten
• Option A: API-Dienste (empfohlen für schnellen Einstieg)
• Option B: Open-Source-Eigenbau
• Serverless-Architektur für den Batch-Dienst
• 5. Einhängen in den Beschaffungs- und Freigabe-Workflow
• 6. Grenzen: Was DMARC nicht schützt

Für ERP- und IT-Verantwortliche: Dieser Artikel erklärt, wie sich die DNS-Authentifizierungsrecords einer Lieferanten-Domain programmatisch auslesen und bewerten lassen, vom Einzel-Lookup im Browser über DNS-over-HTTPS bis zur Batch-Prüfung ganzer Lieferantenlisten und der Anbindung an Beschaffungs- und Freigabe-Workflows.

Den nichttechnischen Einstieg und das direkte Prüf-Tool finden Sie unter Lieferanten-Mail-Sicherheit prüfen.

---

1. Welche DNS-Records über die Fälschbarkeit einer Domain entscheiden

Drei DNS-Record-Typen legen zusammen fest, wie schwer eine Absender-Domain zu fälschen ist. Alle drei werden als TXT-Records im DNS veröffentlicht und sind ohne Authentifizierung öffentlich abfragbar.

SPF: Sender Policy Framework (RFC 7208)

Der SPF-Record ist ein TXT-Eintrag direkt an der Apex-Domain (z. B. lieferant.de). Er listet auf, welche IP-Adressen und Mailserver berechtigt sind, E-Mails im Namen dieser Domain zu versenden.

Abfragebefehl:

TXT-Lookup: lieferant.de
Relevanter Record beginnt mit: v=spf1

Entscheidende Tags:

Bewertungsregel: -all ist korrekt konfiguriert. ~all bietet nur eingeschränkten Schutz, weil empfangende Server Mails von unberechtigten Quellen lediglich als verdächtig markieren, nicht ablehnen. +all oder kein SPF-Record bedeuten: die Domain ist per E-Mail frei fälschbar.

Typische Falle: Zu viele include:-Ketten (SPF-Lookup-Limit: 10 DNS-Lookups). Wird das Limit überschritten, schlägt SPF mit PermError fehl, was manche empfangende Server wie einen Fehler behandeln, andere wie ~all.

DMARC: Domain-based Message Authentication, Reporting and Conformance (RFC 7489)

Der DMARC-Record liegt als TXT-Eintrag unter _dmarc.<domain> und steuert, was empfangende Mailserver mit Nachrichten tun sollen, die SPF- und/oder DKIM-Alignment nicht bestehen.

Abfragebefehl:

TXT-Lookup: _dmarc.lieferant.de
Relevanter Record beginnt mit: v=DMARC1

Kritische Tags:

Bewertungsregel: p=none bedeutet reinen Monitoring-Modus: jeder kann Mails unter dieser Domain versenden, ohne dass sie abgelehnt werden. p=quarantine ist ein Zwischenschritt. Nur p=reject mit pct=100 bietet echten Schutz gegen Domain-Spoofing.

Stand Juni 2026 erreichen weniger als 15 % der deutschen Domains den Gold-Standard p=reject mit pct=100. Von den Domains mit DMARC-Record stehen rund 56 % weiterhin auf p=none, technisch kein aktiver Schutz (dmarcreport.com, 2026).

DKIM: DomainKeys Identified Mail (RFC 6376)

DKIM signiert ausgehende E-Mails mit einem privaten Schlüssel; den zugehörigen öffentlichen Schlüssel publiziert die Domain als TXT-Record. Der Lookup erfordert den Selektor-Namen, der im DKIM-Signature-Header jeder echten E-Mail dieser Domain steht (Tag s=).

Abfragebefehl (Beispiel mit Selektor google):

TXT-Lookup: google._domainkey.lieferant.de
Relevanter Record beginnt mit: v=DKIM1; k=rsa; p=<PublicKey>

Praxisproblem ohne Eingangsmail: Der Selektor ist unbekannt. Gängige Workarounds:

• Häufig verwendete Selektoren ausprobieren: default, google, k1, dkim, mail, selector1, selector2
• Selektor aus dem rua-URI des DMARC-Records ableiten (sofern vorhanden und aussagekräftig)
• Batch-Dienste wie EasyDMARC oder dmarcreport.com erkennen verbreitete Selektoren automatisch durch Heuristik

---

2. DNS-Lookups im Browser: DNS-over-HTTPS (DoH)

Für eine reine Client-Lösung ohne eigenes Backend funktioniert DNS-over-HTTPS direkt aus dem Browser. Beide großen öffentlichen Resolver bieten eine JSON-API ohne Authentifizierung:

Cloudflare (https://cloudflare-dns.com/dns-query):

GET https://cloudflare-dns.com/dns-query?name=_dmarc.lieferant.de&type=TXT
Accept: application/dns-json

Google Public DNS (JSON API Dokumentation) (https://dns.google/resolve):

GET https://dns.google/resolve?name=_dmarc.lieferant.de&type=TXT

Beide Endpunkte antworten mit JSON und liefern die TXT-Records im Feld Answer[].data. Die Auswertung (z. B. v=DMARC1; p=reject; … parsen) erfolgt dann clientseitig in JavaScript.

CORS-Hinweis: Beide Endpunkte senden Access-Control-Allow-Origin: *, sodass ein Cross-Origin-Request aus dem Browser ohne Backend funktioniert. Für SPF- und DMARC-Lookups reicht das. Für DKIM-Lookups, bei denen mehrere Selektoren durchprobiert werden müssen, empfiehlt sich eine dünne Serverless-Funktion (Cloudflare Workers, AWS Lambda, Vercel Edge Functions), die die Selektor-Liste serverseitig abarbeitet.

---

3. Bewertungsmatrix: Was ist „sicher genug"?

Die folgende Matrix zeigt, wie die drei Records zusammenspielen und wie eine Domain für den Rechnungseingang zu bewerten ist:

Hinweis zu pct=: Ein p=reject-Record mit pct=10 schützt nur 10 % des Mailaufkommens. Für eine vollständige Bewertung muss pct= mitgeprüft werden. Standard ist 100, aber manche Domains befinden sich noch im Rollout.

Zur DMARC-Alignment-Logik: DMARC prüft nicht nur, ob SPF oder DKIM bestehen, sondern ob die authentifizierte Domain mit der From:-Header-Domain übereinstimmt (Alignment). Eine E-Mail kann SPF für eine Relay-Domain bestehen, aber DMARC-Alignment dennoch scheitern. Für die Bewertung zählt das Alignment-Ergebnis, nicht das rohe SPF-Ergebnis.

---

4. Batch-Prüfung ganzer Lieferantenlisten

Option A: API-Dienste (empfohlen für schnellen Einstieg)

EasyDMARC API (developers.easydmarc.com):

GET https://api.easydmarc.com/v1.0/dns/dmarc?domain={domain}
Authorization: Bearer <API_KEY>

JSON-Antwort; Batch-Endpoints für mehrere Domains in einem Request verfügbar. Unterstützt SPF, DKIM, DMARC und BIMI. Asynchrone Job-Verarbeitung mit Polling für große Listen.

PowerDMARC API (powerdmarc.com/dmarc-api): RESTful JSON, Swagger-Dokumentation und Postman-Collections vorhanden; CSV-Import, JSON-Export; SIEM-Konnektoren (Splunk, Elastic, Sumo Logic).

dmarcreport.com: CSV-Domainliste hochladen → DMARC und SPF werden automatisch abgefragt; DKIM bei bekannten Selektoren. Export als JSON oder CSV, geeignet für Ad-hoc-Prüfungen ohne Programmieraufwand.

WhoisXML API: API-first, per-Query-Abrechnung, JSON-Antworten. Sinnvoll, wenn die Prüfung in eine bestehende Datenanreicherungs-Pipeline eingebettet werden soll.

Option B: Open-Source-Eigenbau

Für Szenarien mit hohem Volumen, vollständiger Datenkontrolle oder spezifischen Compliance-Anforderungen:

Python mit asyncio und dnspython:

import asyncio
import dns.asyncresolver

async def check_domain(domain: str) -> dict:
    results = {"domain": domain, "spf": None, "dmarc": None}
    try:
        ans = await dns.asyncresolver.resolve(domain, "TXT")
        results["spf"] = next(
            (str(r) for r in ans if "v=spf1" in str(r)), None
        )
    except Exception:
        pass
    try:
        ans = await dns.asyncresolver.resolve(f"_dmarc.{domain}", "TXT")
        results["dmarc"] = str(ans[0])
    except Exception:
        pass
    return results

async def batch_check(domains: list[str]) -> list[dict]:
    sem = asyncio.Semaphore(200)  # max. 200 parallele Lookups
    async def bounded(d):
        async with sem:
            return await check_domain(d)
    return await asyncio.gather(*[bounded(d) for d in domains])

Durchsatz: ca. 1.000 bis 5.000 Lookups/Sekunde bei lokalem Caching-Resolver; bei DoH-Upstream entsprechend weniger. TTL-bewusstes Caching vermeidet redundante Upstream-Abfragen.

Go mit miekg/dns: Geeignet für sehr hohe Parallelität. Goroutinen erlauben Worker-Pools mit 500 bis 1.000 parallelen Resolvern ohne nennenswerten Overhead.

ProjectDiscovery dnsx (CLI):

dnsx -l domains.txt -txt -resp -o results.jsonl

Liefert JSONL-Output direkt weiterverarbeitbar in jq oder Python-Skripten.

massdns: Ultra-schnell für reine DNS-Volumenauflösung; JSONL-Output. Sinnvoll, wenn SPF- und DMARC-Records aus dem TXT-Pool großer Domain-Listen extrahiert werden sollen.

Serverless-Architektur für den Batch-Dienst

Für die Integration als dünner asynchroner Dienst (z. B. Cloudflare Workers, AWS Lambda):

CSV-Upload (Lieferantenliste)
  → Job-Queue (SQS / Cloudflare Queue)
    → Worker: DNS-Lookup (DoH oder nativer Resolver)
      → Bewertungslogik (Matrix oben)
        → Result-Store (S3 / KV-Store)
          → Webhook / API-Response an ERP

Rate-Limiting: DoH-Endpunkte tolerieren mehrere hundert Requests/Sekunde. Bei Listen mit mehr als 10.000 Domains empfiehlt sich ein eigener Caching-Resolver oder eine Premium-API mit SLA. Backoff-Strategie: exponentielles Backoff mit Jitter bei HTTP-429-Antworten.

---

5. Einhängen in den Beschaffungs- und Freigabe-Workflow

Die Bewertung einer Lieferanten-Domain wird erst operativ wirksam, wenn sie im Rechnungseingangs-Prozess direkt sichtbar ist: nicht als separates Security-Tool, sondern eingebettet in die Zahlungsfreigabe.

Typische Integrationspunkte:

1. Ersterfassung Lieferant im ERP: Beim Anlegen automatisch Domain prüfen und Risiko-Flag setzen (grün / gelb / rot).
2. Rechnungseingang: Absender-Domain jeder eingehenden Rechnungsmail gegen aktuellen DNS-Status prüfen; bei p=none oder fehlendem DMARC-Record: Warnung im Freigabe-Step und Pflicht zur manuellen IBAN-Verifikation.
3. Periodisches Monitoring: Lieferantenliste wöchentlich neu prüfen, da DNS-Records sich jederzeit ändern können. Verschlechterungen (z. B. p=reject → p=none) als Alert behandeln.
4. IBAN-Änderungserkennung: Trifft eine Rechnung mit geänderter IBAN von einer Rot-bewerteten Domain ein, sollte das zwingend eine manuelle Prüfpflicht auslösen.

Konnektoren der gängigen DMARC-Plattformen:

• REST-Webhook (JSON POST bei Domain-Statusänderung)
• SIEM-Integration: Splunk, Elastic, Sumo Logic
• Ticketing: Jira, ServiceNow
• Direkte API-Abfrage aus ERP-Middleware (SAP, Dynamics 365, DATEV-Konnektoren)

Event-Payload enthält typischerweise: domain, change_type, old_value, new_value, timestamp.

Der Dienst übernimmt das laufende Monitoring für Ihre gesamte Lieferantenliste: täglich, automatisiert, mit Alert bei Verschlechterung. Details und den direkten Einstieg finden Sie auf der Übersichtsseite Lieferanten-Mail-Sicherheit.

Für den übergeordneten Kontext Rechnungseingang per E-Mail ist auch PDF-Rechnungen per E-Mail verarbeiten lesenswert. Dort werden Eingangskanäle und deren jeweilige Sicherheitseigenschaften verglichen.

---

6. Grenzen: Was DMARC nicht schützt

Ein korrekt konfiguriertes p=reject schützt zuverlässig davor, dass jemand E-Mails unter genau dieser Domain fälscht. Es schützt nicht vor:

• Look-alike-Domains: lieferant-gmbh.de statt lieferantgmbh.de, rn-Substitution statt m, Homoglyphen in internationalisierten Domains (IDN-Homograph-Angriffe). Diese Domains haben eigene DNS-Records; DMARC der Originaldomäne greift dort nicht.
• Kompromittierten Postfächern: Wenn das echte Konto des Lieferanten gehackt wurde, ist die Mail technisch vollständig authentisch: SPF, DKIM und DMARC bestehen alle.
• Fehlender Subdomain-Policy: Ist sp= nicht gesetzt, gilt die DMARC-Policy nicht zwingend für alle Subdomains der Lieferanten-Domain, je nach adkim=- und aspf=-Alignment-Modus.
• SPF-Bruch bei Weiterleitungen: SPF bricht bei Mailweiterleitungen (neuer Envelope-Sender). DKIM übersteht Weiterleitungen, solange der Header unverändert bleibt. DMARC sollte daher primär auf DKIM-Alignment gestützt werden (adkim=r).

Empfehlung: DMARC-Prüfung als erste Filterlinie einsetzen. Bei Domains mit p=none oder fehlendem Record zusätzlich manuelle Prüfpflicht für IBAN-Änderungen einführen. Look-alike-Domain-Erkennung erfordert separate Domainüberwachungs-Dienste (Brand-Monitoring, Certificate-Transparency-Logs).

Für Unternehmen, die den Rechnungsempfang schrittweise auf strukturierte Formate umstellen, eliminiert der Wechsel auf verifizierte Netzwerke den E-Mail-Kanal als primäre Angriffsfläche. Mehr dazu unter E-Rechnungspflicht 2025 bis 2028.

---