Mail-Authentifizierung: SPF, DKIM und DMARC

SPF, DKIM und DMARC beantworten drei verschiedene Fragen zur verwendeten Absenderdomain. SPF prüft die sendende IP, DKIM eine kryptografische Signatur und DMARC den Bezug beider Ergebnisse zur sichtbaren From-Domain. Keiner dieser Mechanismen authentifiziert eine Person oder beweist, dass eine Nachricht ungefährlich ist. Ein DMARC-Pass sagt lediglich, dass die Verwendung der Author Domain nach den veröffentlichten Regeln autorisiert wurde (RFC 7208, Abschnitt 1, RFC 6376, Abschnitt 1, RFC 9989, Abschnitt 1).

Für Messaging-Administratoren ist das System vor allem eine Kette von Zuständigkeiten. Der ausgehende Dienst muss passende Envelope-Domains und DKIM-Signaturen erzeugen. Der autoritative DNS muss SPF-Policy, DKIM-Schlüssel und DMARC-Policy korrekt und rechtzeitig ausliefern. Der empfangende SMTP-Randserver benötigt die ursprüngliche Client-IP, einen Resolver, kryptografische Verifikation und eine definierte Vertrauensgrenze für die Resultate. Ein Report-Collector muss nicht vertrauenswürdiges XML sicher verarbeiten, Duplikate erkennen und Daten über Zeit auswertbar machen. Ein dmarc=pass ist nur das Endergebnis dieser verteilten Pipeline.

Die Erklärung folgt den Identitäten einer E-Mail: Envelope-Absender, sichtbare From-Domain und DKIM-Signatur. SPF und DKIM werden zuerst einzeln erklärt, danach verbindet DMARC ihre Ergebnisse über Alignment, Policy und Reporting.

Identitäten und Vertrauensgrenzen

Eine Nachricht führt mehrere Absenderbegriffe, die nicht austauschbar sind. Der RFC5321.MailFrom ist der Reverse Path des SMTP-Envelopes und das primäre SPF-Objekt. Bei einem leeren Reverse Path, wie er für Zustellberichte vorgesehen ist, leitet SPF die Identität aus HELO/EHLO ab. Der RFC5322.From steht im Nachrichtenkopf, wird vom Mailclient angezeigt und liefert DMARC die Author Domain. Eine DKIM-Signatur benennt mit d= ihre Signing Domain und mit s= den Selektor für den öffentlichen Schlüssel. SMTP AUTH wiederum authentisiert einen Client gegenüber einem Submission-Dienst, ist aber weder SPF noch DKIM noch DMARC (RFC 5321, Abschnitte 3.3 und 4.5.5, RFC 5322, Abschnitt 3.6.2, RFC 7208, Abschnitte 2.3 und 2.4, RFC 6376, Abschnitt 3.5).

Diese Trennung ist eine Sicherheitsgrenze. Ein Angreifer kann mit einer eigenen Domain SPF und DKIM vollständig bestehen und trotzdem im Anzeigenamen eine fremde Marke nennen. DMARC begrenzt die unautorisierte Verwendung der Domain im sichtbaren From:, nicht Look-alike-Domains, Anzeigenamenbetrug, kompromittierte legitime Absender oder schädliche Inhalte (RFC 7208, Abschnitt 11.2, RFC 9989, Abschnitte 2.2 und 11.4).

SPF: Autorisierung der verbindenden IP

Das Sender Policy Framework ist eine DNS-basierte Autorisierung für die Domain in MAIL FROM oder HELO. Der Empfänger wertet die Client-IP, die geprüfte Domain, die Absenderidentität und den lokalen Hostnamen mit der in RFC 7208 definierten Funktion check_host() aus. Der Record liegt als TXT-Ressource direkt an der betreffenden Domain und beginnt mit v=spf1; der aufgegebene DNS-RR-Typ SPF wird nicht verwendet (RFC 7208, Abschnitte 3.1 und 4.1).

Ein Record wie v=spf1 ip4:192.0.2.0/24 include:_spf.sender.example -all wird von links nach rechts ausgewertet. Ein Mechanismus, der passt, beendet die Verarbeitung mit seinem Qualifier. + bedeutet pass und ist der Default, - bedeutet fail, ~ bedeutet softfail, ? bedeutet neutral. all, ip4 und ip6 benötigen während der normalen Auswertung keine zusätzlichen DNS-Lookups; include, a, mx, ptr, exists und redirect tun es (RFC 7208, Abschnitte 4.6.1 bis 4.6.4).

Lookup-Budget und Abhängigkeiten

SPF begrenzt die Summe von include, a, mx, ptr, exists und redirect über die gesamte rekursive Auswertung auf zehn Terme. Eine Überschreitung muss permerror ergeben. Für mx und ptr gelten weitere Adress-Limits; mehr als zwei leere Antworten oder NXDOMAIN-Ergebnisse, sogenannte Void Lookups, sollen ebenfalls zu permerror führen (RFC 7208, Abschnitt 4.6.4).

Das Budget ist eine Laufzeitgrenze und keine blosse Zeichenprüfung. Ein einzelnes include kann weitere Includes, MX-Auflösungen und Ausfallbereiche einführen. include delegiert nur die Frage, ob der aktuelle Host dort ein pass erzielt; redirect übernimmt nach erfolgloser Mechanismenprüfung die gesamte Policy einer anderen Domain. RFC 7208 empfiehlt include zum Überschreiten administrativer Grenzen und redirect eher zum Zentralisieren gleich verwalteter Domains (RFC 7208, Abschnitte 5.2 und 6.1). Für den Betrieb gehören deshalb Besitzer, Zweck, Änderungsweg und gemessenes Worst-Case-Budget jedes Fremd-Includes ins Inventar.

Weiterleitung und SPF-Domain

Ein klassischer Forwarder verbindet sich mit seiner eigenen IP zum nächsten Empfänger, lässt den ursprünglichen MAIL FROM aber bestehen. Damit wird eine IP gegen die SPF-Policy einer fremden Domain geprüft und SPF kann scheitern, obwohl die ursprüngliche Einlieferung legitim war. RFC 7208 beschreibt das Umschreiben des Reverse Path auf eine Domain des Vermittlers als Gegenmassnahme; Mailinglisten tun dies häufig ohnehin (RFC 7208, Anhang D.2). Das behebt den SPF-Pass für die neue Envelope-Domain, erzeugt aber nur dann DMARC-Pass, wenn diese neue Domain mit dem sichtbaren From: aligned ist. Für indirekte Wege ist eine erhaltende, aligned DKIM-Signatur daher besonders wichtig.

DKIM: Signatur einer Domain

DomainKeys Identified Mail fügt ein DKIM-Signature-Headerfeld hinzu. Der Signer kanonisiert ausgewählte Header und den Body, bildet den Body-Hash bh=, signiert die festgelegten Daten und veröffentlicht den Schlüssel unter s=._domainkey.d=. Der Verifier rekonstruiert dieselben Daten, fragt den DNS-TXT-Schlüssel ab und prüft Signatur und Body-Hash. Ein Pass weist nach, dass die signierten Bestandteile seit der Signatur nicht in einer erkannten Weise geändert wurden und dass der Signer den privaten Schlüssel der Signing Domain kontrollierte. DKIM weist weder eine natürliche Person noch die Wahrheit des Inhalts nach (RFC 6376, Abschnitte 3.5 bis 3.8).

Wichtige Tags sind a= für Algorithmus, c= für Header-/Body-Kanonisierung, d= für Signing Domain, s= für Selektor, h= für die signierten Headernamen, bh= für den Body-Hash und b= für die Signatur. t= und x= können Signaturzeitpunkt und Ablaufzeitpunkt transportieren, sind aber kein zuverlässiger Replay-Schutz. Das optionale l= begrenzt den signierten Bodybereich und kann damit das Anhängen nicht signierter Inhalte ermöglichen; RFC 6376 beschreibt diese Missbrauchsfläche ausdrücklich (RFC 6376, Abschnitte 3.5 und 8.2).

Die Kanonisierung simple toleriert nahezu keine Änderung. relaxed normalisiert unter anderem bestimmte Schreibweisen und Whitespace, damit übliche Transportänderungen eine Signatur nicht unnötig brechen. Header und Body können verschiedene Verfahren verwenden; ohne c= gilt simple/simple. Kanonisierung verändert die übermittelte Nachricht nicht, sondern nur deren Eingabeform für Signatur beziehungsweise Verifikation (RFC 6376, Abschnitt 3.4).

Schlüssel, Algorithmen und Rotation

RFC 8301 verlangt für RSA mindestens 1024 Bit, empfiehlt Signern mindestens 2048 Bit und erklärt RSA-SHA1 für historisch. RFC 8463 ergänzt Ed25519-SHA256 und erlaubt zur Übergangskompatibilität parallele Signaturen mit unterschiedlichen Selektoren (RFC 8301, Abschnitte 3.1 und 3.2, RFC 8463, Abschnitte 5 und 6). Welcher Algorithmus eingesetzt wird, bleibt eine Interoperabilitätsentscheidung: Eine standardisierte Pflicht auf Verifier-Seite belegt nicht automatisch, dass jede reale Empfangsplattform sie fehlerfrei umsetzt.

Selektoren trennen Schlüsselwechsel von der Domain. Für eine Rotation wird zuerst der neue öffentliche Schlüssel publiziert, danach mit dem neuen privaten Schlüssel signiert und der alte DNS-Key erst entfernt, wenn alte Nachrichten nicht mehr regulär überprüft werden müssen. RFC 6376 rät davon ab, einen Selektor mit neuem Schlüssel wiederzuverwenden, weil sich dann alte Signaturfehler nicht von Fälschungen unterscheiden lassen. Ein leeres p= im Key-Record widerruft den Schlüssel (RFC 6376, Abschnitte 3.1 und 6.1.2).

Der private Schlüssel gehört nicht ins DNS und nicht in allgemeine Konfigurations-Repositories. Der Betriebsentwurf muss Schlüsselbesitzer, Generation, geschützte Ablage, Zugriff des Signers, Rotation, Notfallwiderruf, Backupentscheid und Auditspur festlegen. RFC 6376 verlangt Sorgfalt beim Schutz privater Schlüssel und nennt verschlüsselte Ablage sowie kryptografische Hardware als mögliche Schutzmassnahmen. Mehrere Versandplattformen sollten getrennte Selektoren besitzen, damit eine kompromittierte Plattform ohne globalen Schlüsselwechsel isoliert werden kann. Diese Architektur folgt der von DKIM vorgesehenen administrativen Aufteilung des Selektor-Namensraums (RFC 6376, Abschnitte 3.1 und 8.3 sowie Anhang C).

SPF kann nach einer Weiterleitung scheitern, obwohl die Nachricht unverändert blieb. DKIM kann dagegen eine Weiterleitung überstehen, aber an einem geänderten Footer brechen. DMARC verbindet deshalb beide Verfahren über das sogenannte Alignment.

DMARC: Alignment, Policy und Auswertung

DMARC setzt ein einzelnes, korrekt geformtes RFC5322.From-Feld voraus und extrahiert daraus genau eine Author Domain. Es betrachtet die SPF-authentisierte Domain und alle erfolgreich verifizierten DKIM-Signing-Domains. Ein DMARC-Pass liegt vor, wenn mindestens ein SPF- oder DKIM-Ergebnis pass ist und dessen Domain mit der Author Domain aligned ist. Beide Mechanismen müssen also nicht gleichzeitig bestehen; im Betrieb sind beide erwünscht, weil sie an unterschiedlichen indirekten Flüssen scheitern können (RFC 9989, Abschnitte 4.2 bis 4.4 und 5.1).

Bei strict alignment müssen die Domains identisch sein. Bei relaxed alignment müssen sie dieselbe Organizational Domain besitzen. adkim=s beziehungsweise aspf=s fordert strict; ohne diese Tags gilt relaxed. Die Ermittlung der Organizational Domain erfolgt nach RFC 9989 über einen begrenzten DNS Tree Walk und nicht mehr allein über eine Public Suffix List. Der Walk fragt höchstens acht Namensebenen ab und berücksichtigt psd=y beziehungsweise psd=n (RFC 9989, Abschnitte 4.4 und 4.10). Diese Änderung ist bei gemischten alten und neuen Verifiern relevant; RFC 9989 weist selbst auf mögliche unterschiedliche Alignment-Ergebnisse hin.

Policy-Record und Tags

Der DMARC-Record liegt unter _dmarc.<domain> und verwendet Tag/Wert-Syntax. v=DMARC1 kennzeichnet das Format. p= beschreibt die gewünschte Behandlung nicht bestandener Nachrichten der Policy-Domain: none, quarantine oder reject. sp= kann bestehende Subdomains abweichend behandeln, np= nicht existierende Subdomains. rua= nennt Ziele für Aggregate Reports, ruf= optionale Ziele für Failure Reports. t=y markiert den in RFC 9989 definierten Testmodus. Unbekannte Tags werden ignoriert (RFC 9989, Abschnitte 4.5 bis 4.8).

Der frühere prozentuale Rollout mit pct= gehört nicht mehr zum Protokoll nach RFC 9989. Betriebserfahrung zeigte uneinheitliche Anwendung; t= ersetzt nur die frühere Sonderwirkung von pct=0, nicht beliebige Prozentschritte. Stufenweise Einführung muss daher über getrennte Author Domains, Subdomain-Policies, gezielte Mailstreams und belastbare Reportauswertung geplant werden, nicht über einen vermeintlich normierten Prozentregler (RFC 9989, Anhang A.6).

Eine Policy ist eine veröffentlichte Präferenz des Domain Owners. Der Empfänger darf wegen lokaler Policy, Reputation, indirekter Flüsse oder anderer Erkenntnisse abweichen und dokumentiert Overrides gegebenenfalls in Reports. p=reject macht eine Nachricht nicht im SMTP-Sinn automatisch unzustellbar bei jedem Empfänger; es schafft eine eindeutige, automatisierbare Aussage für den Umgang mit DMARC-Fail (RFC 9989, Abschnitte 5.3 und 5.4).

Eine DMARC-Policy sollte erst verschärft werden, wenn alle legitimen Versandpfade bekannt sind. Aggregate Reports liefern die Daten für diese Bestandsaufnahme und zeigen, welche Systeme unter einer Domain tatsächlich senden.

Reporting als betriebliche Datenpipeline

RFC 9990 trennt Aggregate Reporting von der DMARC-Kernspezifikation. Ein Report fasst Nachrichten nach Quell-IP, ausgewerteter Policy, Disposition, Alignment und Authentifizierungsresultaten zusammen. Das Datenformat ist XML; die Datei soll mit GZIP komprimiert werden und trägt dann die Endung .xml.gz. Einzelne Records enthalten unter anderem source_ip, count, header_from, SPF- und DKIM-Ergebnisse sowie mögliche Policy-Override-Gründe (RFC 9990, Abschnitte 3.1 und 3.4).

Ein Collector ist deshalb ein sicherheitsrelevanter Ingest-Dienst. Er empfängt unaufgeforderte E-Mail und Anhänge, dekomprimiert fremde Daten, parst XML, dedupliziert Reports und aggregiert Volumen. Grössenlimits, Dekompressionsbudget, XML-Parser ohne externe Entitäten, Malware-Schutz, Quarantäne für fehlerhafte Dateien, Idempotenz und Aufbewahrung sind Teil der Architektur. RFC 9989 warnt vor absichtlich fehlerhaften Reports und DoS gegen Reporting-Ziele; RFC 9990 regelt Duplikate und externe Ziele (RFC 9989, Abschnitt 11.2, RFC 9990, Abschnitte 3.5.4 und 4).

Liegt rua= ausserhalb der Organizational Domain, muss der Report-Empfänger diese Beziehung über einen zusätzlichen DNS-TXT-Record autorisieren. Damit kann eine Domain nicht beliebige Dritte mit Reports fluten (RFC 9990, Abschnitt 4). Failure Reports nach RFC 9991 können einzelne Nachrichteninformationen offenlegen. Wegen der Datenschutzrisiken schränken viele Betreiber sie ein; Aggregate Reports sind der empfohlene Sichtbarkeitskanal ohne Endnutzerinhalt (RFC 9991, Abschnitt 7).

Für die Admin-Auswertung sind Zeitreihen wichtiger als ein einzelner Tageswert: Volumen je Quell-IP und Author Domain, aligned SPF, aligned DKIM, DMARC-Fail, temperror, permerror, unbekannte Selektoren, Policy-Overrides und Reporterabdeckung. Reports sind Beobachtungen einzelner Empfänger und keine vollständige Versandbuchhaltung; Empfänger sind nicht verpflichtet, jede gewünschte Auswertung oder Disposition zu liefern (RFC 9989, Abschnitte 1 und 6).

Authentication-Results richtig vertrauen

Der empfangende Prüfdienst kann SPF-, DKIM- und DMARC-Ergebnisse im Headerfeld Authentication-Results ablegen. authserv-id identifiziert den Dienst oder die Administrative Management Domain, die geprüft hat. Dieses Feld ist nur innerhalb einer definierten Vertrauensgrenze beweiskräftig. Ein externer Absender kann selbst ein überzeugendes Authentication-Results: ... dmarc=pass einfügen (RFC 8601, Abschnitte 1.5.4 bis 1.6).

Der Border-MTA muss deshalb fremde Instanzen entfernen oder nur ausdrücklich vertrauenswürdige Produzenten zulassen. Interne Consumer benötigen eine Liste zulässiger authserv-id-Werte und müssen die Position in der vertrauenswürdigen Received-Kette beziehungsweise internes Metadaten-Provenienzmodell berücksichtigen. RFC 8601 warnt explizit davor, das Headerfeld ohne verifizierten, konformen Border-MTA für Filterentscheidungen zu aktivieren (RFC 8601, Abschnitte 5 und 7.1).

ARC nach RFC 8617 kann Authentifizierungsresultate und nachfolgende Änderungen über Vermittler hinweg in einer signierten Kette transportieren. ARC ist als experimentelles Protokoll veröffentlicht und stellt keine globale Vertrauenswurzel bereit: Der Endempfänger entscheidet weiterhin, welchen ARC-Sealern er vertraut. Ein valider ARC-Chain-Status ist daher Kontext für lokale Policy, kein Ersatz für DMARC und keine automatische Annahmeentscheidung (RFC 8617, Abschnitte 1 und 5).

Bis hierhin ging es um direkte Zustellung. Weiterleitungen, Listen und Gateways verändern jedoch IP-Adresse, Envelope oder Inhalt – und damit genau die Eingaben der drei Prüfungen.

Indirekte Flüsse und typische Bruchstellen

Weiterleitungen, Mailinglisten, Security-Gateways und Ticketing-Systeme verändern unterschiedliche Teile der Nachricht. Eine Weiterleitung ändert die verbindende IP und kann SPF brechen. Eine Mailingliste kann Subject, List-Header, Body-Footer oder MIME-Struktur ändern und damit DKIM brechen. Sie kann zusätzlich den Envelope-Absender und das sichtbare From: umschreiben. RFC 7960 beschreibt diese Interoperabilitätsprobleme und die jeweiligen Nebenwirkungen; es gibt keine universelle Korrektur, die Identität, Listenfunktion und bestehende Empfängerpolicy gleichzeitig unverändert lässt (RFC 7960, Abschnitte 3 und 4).

Für die Fehlersuche müssen Administratoren deshalb den Zustand vor und nach jedem Mediator vergleichen: Client-IP, HELO, MailFrom, RFC5322.From, vorhandene DKIM-Signaturen, Authentication-Results, neue Received-Felder und inhaltliche Mutationen. Ein Endresultat dmarc=fail zeigt allein nicht, welcher Hop die aligned Identität verloren hat.

Technischer Aufbau einer produktiven Plattform

Mail-Authentifizierung ist keine einzelne Appliance, sondern eine verteilte Kontroll- und Datenebene:

Programmiersprache und Produkt sind austauschbar, Protokollobjekte und Vertrauensgrenzen nicht. Ein MTA kann Signatur und Prüfung in C, Rust, Java, Go oder über einen separaten Filterprozess implementieren. Entscheidend für den Betrieb sind dieselben Fragen: Woher stammt die Client-IP nach Load-Balancern? Welcher Resolver und Cache wird genutzt? Wo liegt der private Schlüssel? Welcher Prozess darf signieren? Welche Header werden vor der Vertrauensgrenze entfernt? Wie werden Policy-Version, DNS-Antwort, Message-ID, Queue-ID und Resultat korreliert? Die RFCs definieren Wire- und Auswertungssemantik, nicht das konkrete Prozessmodell.

Kontrollierter Einführungs- und Änderungsprozess

RFC 9989 beschreibt eine belastbare Reihenfolge für Domain Owner: aligned SPF veröffentlichen, aligned DKIM konfigurieren, Aggregate-Report-Mailbox einrichten, DMARC zunächst im Monitoring Mode mit p=none publizieren, Reports auswerten, Lücken beheben und erst danach über Enforcement entscheiden (RFC 9989, Abschnitt 5.1). Daraus folgt für Change Management ein überprüfbarer Ablauf:

1. Alle Author Domains, Envelope-Domains, HELO-Namen, Versandprodukte, Mandanten, Relays, Forwarder und Schlüsselbesitzer inventarisieren.
2. Für jeden legitimen Mailstream mindestens eine aligned Identität nachweisen; SPF und DKIM gemeinsam reduzieren Abhängigkeit von einem einzelnen indirekten Pfad.
3. Reportannahme und sichere Auswertung vor rua= produktionsfähig machen.
4. p=none als Messphase betreiben, aber nicht mit Schutzwirkung verwechseln.
5. Unbekannte Quellen klassifizieren: legitim und falsch konfiguriert, stillgelegt, missbräuchlich oder durch indirekten Fluss verfälscht.
6. Enforcement pro kontrollierbarer Domain einführen, Ausnahmen dokumentieren und anhand von Reports sowie Zustelltelemetrie beobachten.
7. Schlüsselrotation, Providerwechsel, DNS-Rollback, Reportausfall und kompromittierten Signer regelmässig üben.

Eine Freigabe sollte nicht nur einen syntaktisch gültigen TXT-Record abnehmen. Sie braucht Testnachrichten über jeden Versandweg, den Headerbeweis beim Empfänger, Reportdaten aus mehreren Empfängerdomänen, Messung des SPF-Budgets, Prüfung der Selector-TTLs und einen Rollback, der die Author Domain nicht ungeschützt oder unzustellbar zurücklässt.

Aus diesen Abhängigkeiten ergibt sich eine feste Diagnosereihenfolge: erst die verwendeten Domains identifizieren, dann DNS und Signatur prüfen, zuletzt Alignment und DMARC-Policy bewerten.

Diagnosewerkzeuge

Die folgenden Abfragen verwenden example.ch und den beispielhaften Selektor s2026a. Produktive Namen und lokal gespeicherte Nachrichten dürfen nur in autorisierten Umgebungen untersucht werden.

SPF, DMARC und DKIM im DNS lesen

Resolve-DnsName example.ch -Type TXT -DnsOnly
Resolve-DnsName _dmarc.example.ch -Type TXT -DnsOnly
Resolve-DnsName s2026a._domainkey.example.ch -Type TXT -DnsOnly

dig +noall +answer example.ch TXT
dig +noall +answer _dmarc.example.ch TXT
dig +noall +answer s2026a._domainkey.example.ch TXT

Resolve-DnsName und dig zeigen die TXT-RRsets, nicht bereits deren vollständige Protokollauswertung. Mehrere Character Strings eines einzelnen TXT-Records müssen ohne zusätzliche Zeichen zusammengesetzt werden; mehrere SPF- oder DMARC-Records am selben Namen sind dagegen ein Fehler (RFC 7208, Abschnitte 3.2 und 4.5, RFC 9989, Abschnitt 4.5). Für Split-Horizon- oder DNSSEC-Fragen sind autoritative und rekursive Sicht getrennt zu prüfen.

Vertrauenswürdige Resultate im Nachrichtenkopf finden

Get-Content .\message.eml |
  Select-String -Pattern '^(Authentication-Results|DKIM-Signature|Received):' -Context 0,8

grep -E -A8 '^(Authentication-Results|DKIM-Signature|Received):' message.eml

Get-Content und Select-String beziehungsweise grep helfen bei der ersten Sichtung. Wegen Header-Folding und mehrfachen Feldern ersetzt Textsuche keinen RFC-konformen Parser. Entscheidend sind der vertrauenswürdige authserv-id, dessen Position relativ zur eigenen Received-Grenze, die tatsächlich geprüften Domains und das Auseinanderhalten von Rohresultat und Alignment.

Aggregate Report strukturell prüfen

[xml]$report = Get-Content .\report.xml -Raw
$report.SelectNodes("//*[local-name()='record']").Count
$report.SelectSingleNode("//*[local-name()='org_name']").InnerText

xmllint --noout report.xml
xmllint --xpath 'count(//*[local-name()="record"])' report.xml
xmllint --xpath 'string(//*[local-name()="org_name"])' report.xml

Get-Content lädt hier eine bereits entpackte lokale XML-Datei; xmllint prüft Struktur und XPath-Abfragen. Unbekannte Reports sollten nicht interaktiv mit privilegierten Desktop-Tools geöffnet werden. Diese Einzelprüfung belegt weder Schema-Konformität noch sichere Massenverarbeitung, Duplikaterkennung oder korrekte Aggregation.

Fehler systematisch einer Grenze zuordnen

Technische Geschichte

SPF entstand aus mehreren Vorschlägen zur SMTP-Absenderautorisierung und wurde 2006 als experimentelles RFC 4408 veröffentlicht. RFC 7208 überführte SPF 2014 auf den Standards Track, entfernte den separaten DNS-RR-Typ SPF und präzisierte unter anderem DNS- und Void-Limits (RFC 4408, RFC 7208, Anhang B). Seine Architektur blieb bewusst an der SMTP-Verbindung und dem Reverse Path orientiert.

DKIM vereinte Erfahrungen aus DomainKeys und Identified Internet Mail. RFC 4871 standardisierte DKIM 2007; RFC 6376 ersetzte es 2011 und schärfte Signatur-, Schlüssel- und Verifikationsmodell. RFC 8301 aktualisierte 2018 Algorithmen und RSA-Schlüssellängen, RFC 8463 ergänzte Ed25519-SHA256 (RFC 4871, RFC 6376, RFC 8301, RFC 8463).

DMARC wurde zunächst 2015 mit RFC 7489 als informatives Dokument veröffentlicht. RFC 9989 ersetzte 2026 RFC 7489 und die PSD-Erweiterung RFC 9091 als Standards-Track-Spezifikation; Aggregate Reporting und Failure Reporting wurden gleichzeitig in RFC 9990 und RFC 9991 ausgelagert. Der Wechsel führte unter anderem DNS Tree Walk, np, psd und t ein und entfernte pct (RFC 9989, Anhang C, RFC 9990, RFC 9991).

Die maschinenlesbare Weitergabe von Prüfergebnissen entwickelte sich von RFC 5451 über RFC 7001 und RFC 7601 zu RFC 8601. ARC wurde 2019 mit RFC 8617 als experimenteller Versuch veröffentlicht, Authentifizierungsergebnisse indirekter Flüsse signiert weiterzugeben (RFC 8601, Abschnitt 6, RFC 8617). Diese Historie erklärt, warum reale Plattformen nebeneinander alte DMARC-Tags, PSL-basierte Organizational Domains, verschiedene DKIM-Algorithmen und unterschiedliche Auth-Results-Vertrauensmodelle zeigen können.