Syntax

wie ist ein DMARC-Record aufgebaut?


Version

TAG: "v"
Der Versions-Tag definiert den Record als DMARC-Record. Dabei sind nur 2 Sachen zu beachten:
Dieser Tag muss an erster Stelle im Record stehen.
Es muss eine valide Version definiert sein. (Aktuell nur 'DMARC1')
Beispiel: "v=DMARC1"

Richtline (Policy)

TAG: "p"
Der Policy-Tag bestimmt, was der Empfänger der Mails machen soll, sobald eine Mail den DMARC-Check nicht besteht.
Dieser Tag muss an zweiter Stelle im Record stehen.
Es gibt folgende Werte für p:

none Mails, welche den DMARC-Check nicht bestanden haben, werden normal zugestellt. Diese Option bietet keinerlei Spoofing-Schutz und sollte nur zum Monitoring verwendet werden.
quarantine Mails, welche den DMARC-Check nicht bestanden haben, werden zugestellt und zusätlich als Spam markiert.
reject Mails, welche den DMARC-Check nicht bestanden haben, werden nicht zugestellt.

Beispiel: "p=quarantine"

Subdomain-Richtline (Subpolicy)

TAG: "sp"
Der Subpolicy-Tag bestimmt, was der Empfänger der Mails einer Supdomain machen soll, sobald sie den DMARC-Check nicht besteht.
Dieser Tag ist optional. Wird kein Wert definiert, so ist die Subpolicy gleich der normalen Policy.
Es gibt folgende Werte für sp:
none Mails, welche den DMARC-Check nicht bestanden haben, werden normal zugestellt. Diese Option bietet keinerlei Spoofing-Schutz und sollte nur zum Monitoring verwendet werden.
quarantine Mails, welche den DMARC-Check nicht bestanden haben, werden zugestellt und zusätlich als Spam markiert.
reject Mails, welche den DMARC-Check nicht bestanden haben, werden nicht zugestellt.

Beispiel: "sp=reject"

RUA

TAG: "rua"
Der RUA-Tag beinhaltet verschiedene Adressen, an welche Aggregate-Berichte gesendet werden sollen.
Es können verschiedene URI als Adressen definiert werden. Dabei ist zu beachten, dass ausschließlich URIs im 'mailto:'-Schema verarbeitet werden müssen.
Adressen werden durch Komma (,) getrennt gelistet. Mehr als 2 Adressen sind nicht empfohlen, da nur diese garantiert mit Berichten beliefert werden.
Sollten eine Domain in einer Adresse definiert sein, welche nicht mit der Domain des DMARCs übereinstimmt, so müssen Sie sicherstellen, dass diese Fremddomain den Empfang von Berichten erlaubt. Dazu können Sie einen einfachen DMARC ('v=DMARC1') unter 'domain._report._dmarc.fremddomain.de'
Alternativ kann auch eine Wildcard unter '*._report._dmarc.fremddomain.de' eingerichtet werden. Dies akzeptiert jedoch alle DMARC-Berichte.

Dieser Tag ist optional.
Beispiel: 'rua=mailto:info@beispiel.de'

RUF

TAG: "ruf"
Der RUF-Tag beinhaltet verschiedene Adressen, an welche Forensic-Berichte gesendet werden sollen.
Es können verschiedene URI als Adressen definiert werden. Dabei ist zu beachten, dass ausschließlich URIs im 'mailto:'-Schema verarbeitet werden müssen.
Adressen werden durch Komma (,) getrennt gelistet. Mehr als 2 Adressen sind nicht empfohlen, da nur diese garantiert mit Berichten beliefert werden.
Sollten eine Domain in einer Adresse definiert sein, welche nicht mit der Domain des DMARCs übereinstimmt, so müssen Sie sicherstellen, dass diese Fremddomain den Empfang von Berichten erlaubt. Dazu können Sie einen einfachen DMARC ('v=DMARC1') unter 'domain._report._dmarc.fremddomain.de'
Alternativ kann auch eine Wildcard unter '*._report._dmarc.fremddomain.de' eingerichtet werden. Dies akzeptiert jedoch alle DMARC-Berichte.

Dieser Tag ist optional.
Beispiel: 'ruf=mailto:info@beispiel.de'

Aggregate Intervall

TAG: "ri"
Der RI-Tag gibt den Intervall an, in dem Aggregate-Berichte zugestellt werden sollen.
Der Standard-Wert beträgt 24 Stunden.
Die Zeitspanne wir in Sekunden angegeben.
Ersteller von Berichten handeln nach eigenem Gewissen und können nicht garantieren unter 24 Stunden Berichte zuzustellen.

Dieser Tag ist optional.
Beispiel: "ri=172800"

Forensic Format

TAG: "rf"
Der RF-Tag bestimmt das Format in dem Forensic Berichte erstellt werden.
Aktuell ist 'afrf' das einzig gültige Format. Dies ist gleichzeitig der Standard-Wert

Dieser Tag ist optional.
Beispiel: "rf=afrf"

Forensic Optionen

TAG: "fo"
Der FO-Tag beinhaltet die Einstellungen für die Erstellung von Fehlerberichten.
Es können mehrere Optionen gewählt werden. Diese sind durch ':' getrennt.
Ein gültiger RUF-Tag muss definiert sein, damit 'fo' Anwendung findet.
Der Standard-Wert ist 0.

Dieser Tag ist optional.

0
 Ein Fehlerbericht wird erstellt wenn DKIM- und SPF-Check kein 'pass' Resultat erzeugen.
1
 Ein Fehlerbericht wird erstellt sobald DKIM- und/oder SPF-Check kein 'pass' Resultat erzeugen.
d
 Erstellt einen DKIM Fehlerbericht, unabhängig von der DKIM Ausrichtung
s Erstellt einen SPF Fehlerbericht, unabhängig von der SPF Ausrichtung

Beispiel: "fo=1:d"

DKIM Ausrichtung

TAG: "adkim"
Der ADKIM-Tag bestimmt den Modus für die DKIM-Unterprüfung.
Der Standard-Wert ist der relaxed Modus (r).

Dieser Tag ist optional.

r
Entspannt / Relaxed Modus
Organisationsdomain von DKIM-Signaturdomain und From-Header Domain müssen übereinstimmen. (Subdomains erlaubt)
s
Strenger Modus
DKIM-Signaturdomain und From-Header Domain müssen exakt übereinstimmen. (Subdomains verboten)

Beispiel: "adkim=s"

SPF Ausrichtung

TAG: "aspf"
Der ASPF-Tag bestimmt den Modus für die SPF-Unterprüfung.
Der Standard-Wert ist der relaxed Modus (r).

Dieser Tag ist optional.

r
Entspannt / Relaxed Modus
SPF-authentifizierte Domain und From-Header Domain muss dieselbe Organisationsdomain haben. (Subdomains erlaubt)
s
Strenger Modus
SPF-authentifizierte Domain und From-Header Domain muss exakt dieselbe Domain sein. (Subdomains verboten)

Beispiel: "aspf=s"

Abdeckung

TAG: "pct"
Der PCT-Tag den Prozentsatz der Mails an, an welchen ein DMARC-Check durchgeeführt werden soll.
Der Standard-Wert beträgt 100% und ist immer empfohlen.
Ein geringerer Wert verringert ebenfalls die Sicherheit welche der DMARC bietet.
Es ist nur empfohlen während eines Rollouts die Abdeckung anzupassen.

Dieser Tag ist optional.
Beispiel: "pct=100"