Stand: Juli 2026

Zusammenfassung: Der optionale Tag fo= (Failure Reporting Options) steuert, unter welchen genauen Bedingungen empfangende Mailserver einen forensischen Fehlerbericht (ruf=) generieren und versenden sollen. Er bietet vier Optionen (0, 1, d, s), die eine präzise Diagnose von Authentifizierungsfehlern ermöglichen.

Wenn du in deinem DMARC-Eintrag (Domain-based Message Authentication, Reporting, and Conformance) über den Tag ruf= forensische Einzelberichte anforderst, bestimmt der Parameter fo=, wann genau diese Berichte ausgelöst werden.

Grundlagen und Abhängigkeit von ruf=

Der Tag fo= funktioniert ausschließlich im Zusammenspiel mit dem ruf= Tag. Lässt du fo= im DNS weglassen, wendet DMARC standardmäßig den Wert 0 an.

Laut RFC 7489 ist der Tag wie folgt definiert: fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified.

Ein vollständiger DMARC-Record mit aktiviertem Fehler-Reporting und spezifischer Option sieht im DNS so aus:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Die vier Reporting-Optionen im Detail

Der Standard RFC 7489 definiert vier verschiedene Auslöser für Fehlerberichte, die du bei Bedarf auch kombinieren kannst (durch Doppelpunkte getrennt, z. B. fo=0:d):

Option 0 (Standardwert): Alle Mechanismen schlagen fehl

Wenn du fo=0 setzt oder den Tag weglässt, wird ein Bericht nur dann erstellt, wenn sowohl die SPF- als auch die DKIM-Prüfung das Alignment verfehlen: 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.

Diese Einstellung reduziert das Berichtsvolumen auf echte DMARC-Ausfälle, verbirgt jedoch partielle Konfigurationsprobleme, bei denen lediglich ein einzelner Mechanismus scheitert.

Option 1 (Empfehlung für Fehlersuche): Ein Mechanismus schlägt fehl

Wenn du fo=1 setzt, wird sofort ein Fehlerbericht generiert, sobald einer der beiden Mechanismen (entweder SPF oder DKIM) kein erfolgreiches Alignment erzielt: 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.

fo=1 ist die ideale Einstellung während der Einführungs- und Testphase. Sie warnt dich sofort, wenn beispielsweise deine DKIM-Signatur korrekt funktioniert, aber dein SPF-Eintrag aufgrund von Weiterleitungen oder fehlerhaften Return-Path-Domains das Alignment verfehlt.

Option d: DKIM-spezifische Fehler

Die Option fo=d löst einen Bericht aus, wenn die kryptografische DKIM-Signatur ungültig ist, völlig unabhängig vom DMARC-Alignment: d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.

Dies hilft Administratoren gezielt dabei, defekte Schlüssel, fehlerhafte Selektoren oder eine versehentliche Beschädigung des E-Mail-Inhalts auf dem Transportweg zu identifizieren.

Option s: SPF-spezifische Fehler

Die Option fo=s generiert einen Bericht, wenn die reine SPF-Auswertung fehlschlägt, ebenfalls unabhängig vom späteren DMARC-Alignment: s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

Konfiguration prüfen

Um zu testen, ob dein fo= Tag korrekt im DNS hinterlegt ist, ob deine ruf= Adresse gültig ist und ob keine Syntaxfehler im TXT-Record vorliegen, kannst du deine Konfiguration mit dem kostenlosen MXAudit-Scanner prüfen.

Weitere Hintergrundinformationen zum Aufbau von DMARC-Einträgen und praktische Schritt-für-Schritt-Anleitungen findest du in der DMARC-Übersicht und in Leitfäden wie DMARC bei IONOS einrichten.