none

E-Mails, die DMARC nicht bestehen, werden normal zugestellt. Sie erhalten nur Berichte.

quarantine

Fehlgeschlagene E-Mails landen im Spam-Ordner statt im Posteingang.

reject

Fehlgeschlagene E-Mails werden vollständig blockiert und nie zugestellt.

Beginnen Sie mit none, um zu erfahren, wer in Ihrem Namen E-Mails versendet, ohne die Zustellung zu beeinträchtigen. Wechseln Sie zu quarantine, sobald Sie Ihre DMARC-Berichte ausgewertet haben, und schließlich zu reject für vollständigen Schutz.

Unsere Empfehlung

Sie erhalten eine tägliche Zusammenfassung (XML), die zeigt, welche Server in Ihrem Namen E-Mails versendet haben und ob diese SPF und DKIM bestanden haben. Essenziell für die Überwachung.

Unsere Empfehlung Setzen Sie dies immer. Ohne diesen Tag fliegen Sie blind und wissen nicht, ob legitime E-Mails betroffen sind.

Sie erhalten einen forensischen DMARC-Bericht, sobald eine einzelne E-Mail die Authentifizierung nicht besteht. Nützlich zur Fehlersuche während der Einrichtung und zur Untersuchung von Angriffen.

Unsere Empfehlung Setzen Sie dies zur Fehlersuche. Beachten Sie, dass einige Anbieter (z. B. Gmail) aus Datenschutzgründen keine forensischen Berichte versenden.

none / quarantine / reject

Dieselben Optionen wie die Hauptrichtlinie, jedoch nur für Subdomains (z. B. mail.example.com, news.example.com).

Setzen Sie dies, wenn Subdomains eine andere Richtlinie als die Hauptdomain benötigen. Ohne diese Angabe erben Subdomains die Richtlinie der Hauptdomain.

Unsere Empfehlung Weglassen, um die Richtlinie aus dem p=-Tag zu erben, sofern Subdomains nicht anders versenden als die Hauptdomain.

Wenden Sie Ihre vollständige Richtlinie nur auf einen Teil der fehlgeschlagenen E-Mails an. Der Rest wird eine Stufe niedriger behandelt. Bei p=reject werden die übrigen Nachrichten unter Quarantäne gestellt, bei p=quarantine wie none behandelt. Beispiel: p=reject; pct=5 blockiert 5%% der fehlgeschlagenen Nachrichten und stellt die anderen 95%% unter Quarantäne.

Unsere Empfehlung Weglassen bei p=none (Überwachung). Beim Wechsel zu quarantine oder reject mit 5 beginnen und schrittweise erhöhen.

r – Relaxed (Standard)

Die DKIM-Signaturdomain darf eine Subdomain der From-Domain sein.
z. B. mail.example.com signiert für example.com – akzeptiert.

s – Strict

Die DKIM-Signaturdomain muss exakt mit der From-Domain übereinstimmen.
z. B. mail.example.com signiert für example.com – abgelehnt.

Verwenden Sie strict während der Überwachung (p=none), um genau zu sehen, wo Abgleichsprobleme bestehen, ohne die Zustellung zu beeinträchtigen. Wechseln Sie zu relaxed bei der Durchsetzung, wenn Drittanbieter-Absender Subdomain-Flexibilität benötigen.

Unsere Empfehlung

r – Relaxed (Standard)

Die Return-Path-Domain darf eine Subdomain der From-Domain sein.

s – Strict

Die Return-Path-Domain muss exakt mit der From-Domain übereinstimmen.

Viele E-Mail-Dienste (z. B. Mailchimp, Zendesk) versenden im Auftrag von example.com aus Subdomains wie bounces.example.com. Relaxed akzeptiert dies und vermeidet falsche Fehlschläge, während strict es ablehnen würde. Wählen Sie strict nur, wenn jeder Absender die exakte From-Domain verwendet.

Unsere Empfehlung

3600 – Berichte werden stündlich angefragt.

43200 – Berichte werden alle 12 Stunden angefragt.

86400 – Berichte werden einmal täglich angefragt (RFC-Standard).

Stündliche Berichte liefern schnelleres Feedback, vor allem bei Änderungen an SPF/DKIM. Nach der Stabilisierung reicht täglich. Hinweis: Manche Anbieter senden ohnehin nur täglich.

Unsere Empfehlung

0 – Bericht, wenn weder SPF noch DKIM einen abgeglichenen Pass ergeben (Standard).

1 – Bericht, sobald ein beliebiger Authentifizierungsmechanismus keinen abgeglichenen Pass liefert.

d – Bericht, wenn eine DKIM-Signatur die Validierung nicht besteht – unabhängig vom Abgleich.

s – Bericht, wenn SPF die Validierung nicht besteht – unabhängig vom Abgleich.

Mehrere Optionen mit Doppelpunkten kombinieren, z. B. fo=1:d:s

Der Standard 0 löst nur einen Bericht aus, wenn sowohl SPF als auch DKIM den Abgleich nicht bestehen, was Fälle verbirgt, in denen nur ein Mechanismus defekt ist. Durch Kombinieren der Optionen wird jeder Fehlertyp einzeln erfasst.

Unsere Empfehlung

afrf

Authentication Failure Reporting Format. Der einzige weit verbreitete Standard.

Dies ist das einzige aktuell genutzte Format. Es gibt keinen praktischen Grund, es zu ändern.

Unsere Empfehlung Standard belassen. Keine Aktion erforderlich.