DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein E-Mail-Authentifizierungsprotokoll. Es wurde entwickelt, um den Inhabern von E-Mail-Domänen die Möglichkeit zu geben, ihre Domäne vor unbefugter Nutzung zu schützen, die gemeinhin als E-Mail-Spoofing bekannt ist. Zweck und Hauptziel der DMARC-Implementierung ist es, eine Domäne davor zu schützen, dass sie für Angriffe auf geschäftliche E-Mails, Phishing-E-Mails, E-Mail-Betrug und andere Cyber-Bedrohungen verwendet wird. ⓘ

Sobald der DMARC-DNS-Eintrag veröffentlicht ist, kann jeder empfangende E-Mail-Server die eingehende E-Mail auf der Grundlage der vom Domänenbesitzer im DNS-Eintrag veröffentlichten Anweisungen authentifizieren. Wenn die E-Mail die Authentifizierung besteht, wird sie zugestellt und kann als vertrauenswürdig eingestuft werden. Wenn die E-Mail die Prüfung nicht besteht, kann die E-Mail je nach den Anweisungen im DMARC-Eintrag zugestellt, unter Quarantäne gestellt oder zurückgewiesen werden. Beispielsweise stellt ein E-Mail-Weiterleitungsdienst die E-Mail zu, allerdings mit dem Vermerk "From: no-reply@<forwarding service>". ⓘ

DMARC erweitert zwei bestehende E-Mail-Authentifizierungsmechanismen, Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM). Es ermöglicht dem administrativen Eigentümer einer Domäne, in seinen DNS-Einträgen eine Richtlinie zu veröffentlichen, um festzulegen, welcher Mechanismus (DKIM, SPF oder beide) beim Versenden von E-Mails von dieser Domäne verwendet wird; wie das Feld "From:", das den Endbenutzern präsentiert wird, zu überprüfen ist; wie der Empfänger mit Fehlschlägen umgehen soll - und einen Berichtsmechanismus für Aktionen, die im Rahmen dieser Richtlinien durchgeführt werden. ⓘ

DMARC ist in dem von der Internet Engineering Task Force veröffentlichten Dokument RFC 7489 vom März 2015 als "Informational" definiert. ⓘ

Es gibt viele weitere Parameter, die im DMARC-Eintrag verwendet werden können, wie z. B. Alignment Mode und rua/ruf, um sicherzustellen, dass Sie täglich DMARC-Berichte von den Mailservern der Empfänger erhalten. ⓘ

Überblick

Mit einer DMARC-Richtlinie kann die Domäne eines Absenders angeben, dass seine E-Mail-Nachrichten durch SPF und/oder DKIM geschützt sind, und dem Empfänger mitteilen, was zu tun ist, wenn keine dieser Authentifizierungsmethoden erfolgreich ist - z. B. die Nachricht zurückweisen oder in Quarantäne stellen. In der Richtlinie kann auch festgelegt werden, wie ein E-Mail-Empfänger die Domäne des Absenders über bestandene und/oder fehlgeschlagene Nachrichten informieren kann. ⓘ

Diese Richtlinien werden im öffentlichen Domain Name System (DNS) als Text-TXT-Einträge veröffentlicht. ⓘ

DMARC befasst sich nicht direkt mit der Frage, ob eine E-Mail Spam oder anderweitig betrügerisch ist oder nicht. Stattdessen kann DMARC verlangen, dass eine Nachricht nicht nur die DKIM- oder SPF-Validierung, sondern auch den Abgleich besteht. Im Rahmen von DMARC kann eine Nachricht auch dann fehlschlagen, wenn sie zwar SPF oder DKIM, nicht aber den Abgleich besteht. ⓘ

Die Einrichtung von DMARC kann die Zustellbarkeit von Nachrichten von legitimen Absendern verbessern. ⓘ

Abgleich

DMARC prüft, ob die Domäne im Absenderfeld der Nachricht (auch "RFC5322.From" genannt) mit anderen authentifizierten Domänennamen übereinstimmt. Wenn entweder die SPF- oder DKIM-Abgleichsprüfung erfolgreich ist, ist auch der DMARC-Abgleichstest erfolgreich. ⓘ

Der Abgleich kann als strikt oder entspannt angegeben werden. Bei strikter Ausrichtung müssen die Domänennamen identisch sein. Bei entspannter Ausrichtung muss die Top-Level "Organizational Domain" übereinstimmen. Die Organisationsdomäne wird durch Überprüfung einer Liste öffentlicher DNS-Suffixe und Hinzufügen des nächsten DNS-Labels ermittelt. So haben z. B. "a.b.c.d.example.com.au" und "example.com.au" die gleiche Organisationsdomäne, da es eine Registrierstelle gibt, die Kunden Namen in ".com.au" anbietet. Obwohl es zur Zeit der DMARC-Spezifikation eine IETF-Arbeitsgruppe für Domänengrenzen gab, kann die Organisationsdomäne heutzutage nur aus der öffentlichen Suffixliste abgeleitet werden. ⓘ

Wie SPF und DKIM verwendet auch DMARC das Konzept des Domänenbesitzers, d. h. der Entität oder der Entitäten, die berechtigt sind, Änderungen an einer bestimmten DNS-Domäne vorzunehmen. ⓘ

SPF prüft, ob die IP-Adresse des sendenden Servers vom Eigentümer der Domäne autorisiert ist, die im SMTP-Befehl MAIL FROM erscheint. (Die E-Mail-Adresse in MAIL FROM wird auch als Bounce-Adresse, envelope-from oder RFC5321.MailFrom bezeichnet.) DMARC verlangt nicht nur, dass die SPF-Prüfung erfolgreich ist, sondern prüft auch, ob RFC5321.MailFrom mit 5322.From übereinstimmt. ⓘ

Mit DKIM können Teile einer E-Mail-Nachricht kryptografisch signiert werden, und die Signatur muss das Feld "From" abdecken. Innerhalb des DKIM-Signatur-Mail-Headers geben die Tags d= (Domain) und s= (Selector) an, wo im DNS der öffentliche Schlüssel für die Signatur abgerufen werden soll. Eine gültige Signatur beweist, dass der Unterzeichner der Eigentümer der Domäne ist und dass das Absenderfeld seit dem Anbringen der Signatur nicht geändert wurde. Es kann mehrere DKIM-Signaturen für eine E-Mail-Nachricht geben; DMARC erfordert eine gültige Signatur, bei der die Domäne im d=-Tag mit der Domäne des Absenders übereinstimmt, die im From: Header-Feld angegeben ist. ⓘ

DNS-Eintrag

DMARC-Einträge werden im DNS mit der Subdomain-Bezeichnung _dmarc veröffentlicht, zum Beispiel _dmarc.example.com. Vergleichen Sie dies mit SPF unter example.com und DKIM unter selector._domainkey.example.com. ⓘ

Der Inhalt des TXT-Ressourcendatensatzes besteht aus name=value-Tags, die durch Semikolons getrennt sind, ähnlich wie bei SPF und DKIM. Zum Beispiel:

"v=DMARC1;p=keine;sp=Quarantäne;pct=100;rua=mailto:dmarcreports@example.com;" ⓘ

Hier steht v für die Version, p für die Richtlinie (siehe unten), sp für die Subdomain-Richtlinie, pct für den Prozentsatz der "schlechten" E-Mails, auf die die Richtlinie angewandt werden soll, und rua für die URI, an die aggregierte Berichte gesendet werden sollen. In diesem Beispiel möchte die Entität, die die DNS-Domäne example.com kontrolliert, die SPF- und/oder DKIM-Fehlerraten überwachen und erwartet nicht, dass E-Mails von Subdomänen von example.com gesendet werden. Beachten Sie, dass eine Subdomain ihren eigenen DMARC-Eintrag veröffentlichen kann; die Empfänger müssen diesen überprüfen, bevor sie auf den Eintrag der Organisationsdomain zurückgreifen. ⓘ

Schrittweise Übernahme

Das Protokoll sieht verschiedene Stufen oder Übergangszustände vor, die es E-Mail-Administratoren ermöglichen, schrittweise von der Nichtimplementierung von DMARC bis hin zu einer unnachgiebigen Einrichtung überzugehen. Das Konzept der schrittweisen Einführung geht davon aus, dass das Ziel von DMARC die stärkste Einstellung ist, was nicht bei allen Domänen der Fall ist. Unabhängig von der Absicht ermöglichen diese Mechanismen eine größere Flexibilität. ⓘ

Richtlinie

In erster Linie gibt es drei Richtlinien:

• Keine ist die Einstiegsrichtlinie. Sie verlangt von den Empfängern keine besondere Behandlung, sondern ermöglicht es einer Domäne, Rückmeldungen zu erhalten.
• Quarantäne fordert die Empfänger auf, Nachrichten, die die DMARC-Prüfung nicht bestehen, mit Misstrauen zu behandeln. Verschiedene Empfänger haben unterschiedliche Möglichkeiten, dies umzusetzen, z. B. Nachrichten zu markieren oder sie in den Spam-Ordner zu stellen.
• reject fordert die Empfänger auf, Nachrichten, die die DMARC-Prüfung nicht bestehen, rundheraus abzulehnen. ⓘ

Die veröffentlichte Richtlinie kann abgeschwächt werden, indem sie nur auf einen bestimmten Prozentsatz der Nachrichten angewendet wird, die die DMARC-Prüfung nicht bestehen. Die Empfänger werden gebeten, den angegebenen Prozentsatz von Nachrichten durch einen einfachen Bernoulli-Stichprobenalgorithmus auszuwählen. Für den Rest der Nachrichten gilt die niedrigere Richtlinie, d. h. keine, wenn p=Quarantäne, Quarantäne, wenn p=Ablehnung. Wenn nichts angegeben wird, ist pct standardmäßig auf 100 % der Nachrichten eingestellt. Der Fall p=quarantine; pct=0; wird verwendet, um Mailinglisten-Manager zu zwingen, das From: Feld umzuschreiben, da einige dies nicht tun, wenn p=none. ⓘ

Schließlich erlauben die Subdomain-Richtlinie, sp= und die neu hinzugefügte No-Domain-Richtlinie, die Richtlinie für bestimmte Subdomains zu optimieren. ⓘ

Berichte

DMARC ist in der Lage, zwei verschiedene Arten von Berichten zu erstellen. Aggregierte Berichte werden an die nach der rua angegebene Adresse gesendet. Forensische Berichte werden per E-Mail an die Adresse nach dem ruf-Tag gesendet. Diese E-Mail-Adressen müssen im URI-Mailto-Format angegeben werden (z. B. mailto:worker@example.net</nowiki> ). Mehrere Berichtsadressen sind zulässig und müssen jeweils im vollständigen URI-Format angegeben werden, getrennt durch ein Komma. ⓘ

Ziel-E-Mail-Adressen können zu externen Domänen gehören. In diesem Fall muss die Zieldomäne einen DMARC-Eintrag einrichten, um mitzuteilen, dass sie mit dem Empfang einverstanden ist, andernfalls wäre es möglich, die Berichterstattung zur Spam-Verstärkung auszunutzen. Nehmen wir an, receiver.example erhält eine E-Mail von someone@sender.example und möchte sie melden. Findet er ruf=mailto:some-id@thirdparty.example</nowiki>findet, sucht er nach einem bestätigenden DNS-Eintrag in dem vom Ziel verwalteten Namensraum, etwa so:

absender.beispiel._report._dmarc.thirdparty.example IN TXT "v=DMARC1;" ⓘ

Aggregierte Berichte

Aggregierte Berichte werden als XML-Dateien versandt, in der Regel einmal pro Tag. In der Betreffzeile werden die "Report Domain", die den DNS-Domainnamen angibt, über den der Bericht erstellt wurde, und der "Submitter", die den Bericht erstellende Einheit, genannt. Die Nutzdaten befinden sich in einem Anhang mit einem langen Dateinamen, der aus durch Bangs getrennten Elementen besteht, wie z. B. dem berichterstattenden Empfänger, den Anfangs- und Endepochen des Berichtszeitraums als Zeitstempel im Unix-Stil, einem optionalen eindeutigen Bezeichner und einer Erweiterung, die von der möglichen Komprimierung abhängt (früher war es .zip). ⓘ

Zum Beispiel: example.com!example.org!1475712000!1475798400.xml.gz. ⓘ

Der XML-Inhalt besteht aus einem Header, der die Richtlinie, auf der der Bericht basiert, und die Metadaten des Berichts enthält, gefolgt von einer Reihe von Datensätzen. Die Datensätze können in einer Datenbank als Relation abgelegt und in Tabellenform angezeigt werden. Das XML-Schema ist in Anhang C der Spezifikationen definiert und ein Rohdatensatz ist in dmarc.org beispielhaft dargestellt. Wir bleiben hier bei einem relationalen Beispiel, das die Natur der Daten besser wiedergibt. DMARC-Datensätze können auch direkt in HTML umgewandelt werden, indem ein XSL-Stylesheet angewendet wird. ⓘ

DMARC-Zeilen eines aggregierten Datensatzes in Tabellenform

Quelle IP	Anzahl	Ablehnung	SPF	DKIM	Header von	SPF-Domäne (Ergebnis)	DKIM-Domäne (Ergebnis)	ⓘ
192.0.2.1	12	keine	✓ Pass	✓ Pass	beispiel.org	example.org (✓ Pass)	example.org (✓ Pass)
192.0.2.1	1	keine	✓ Pass	✗ Fehlschlag	beispiel.org	example.org (✓ Pass)	example.org (✗ Fail)
192.0.2.28	42	keine	✗ Fehlschlag	✓ Pass	beispiel.org	example.org (✗ Fail)	example.org (✓ Pass)	forwarder.example (✓ Bestanden)
192.0.2.82	21	keine	✗ Fehlschlag	✗ Fehlschlag	beispiel.org	discusslist.example (✓ Bestanden)	example.org (✗ Fail)	discusslist.example (✓ Bestanden)
...

Die Zeilen sind nach Quell-IP und Authentifizierungsergebnissen gruppiert, wobei nur die Anzahl der einzelnen Gruppen angegeben wird. Die Spalten ganz links mit den Bezeichnungen SPF und DKIM zeigen die DMARC-Ergebnisse an, entweder bestanden oder nicht bestanden, wobei die Ausrichtung berücksichtigt wird. Die Spalten ganz rechts, mit ähnlichen Bezeichnungen, zeigen den Namen der Domäne, die behauptet, am Versand der Nachricht beteiligt zu sein, und (in Klammern) den Authentifizierungsstatus dieser Behauptung gemäß dem ursprünglichen Protokoll, SPF oder DKIM, unabhängig von der Identifier-Ausrichtung. Auf der rechten Seite kann SPF höchstens zweimal erscheinen, einmal für den Return-Path: Test und einmal für den HELO Test; DKIM kann einmal für jede in der Nachricht vorhandene Signatur erscheinen. Im Beispiel stellt die erste Zeile den Hauptpostfluss von example.org dar, und die zweite Zeile ist eine DKIM-Störung, z. B. ein Bruch der Signatur aufgrund einer geringfügigen Änderung während der Übertragung. Die dritte und vierte Zeile zeigen typische Fehlermodi eines Forwarders bzw. einer Mailingliste. Die DMARC-Authentifizierung ist nur in der letzten Zeile fehlgeschlagen; sie hätte sich auf die Verteilung der Nachricht auswirken können, wenn example.org eine strenge Richtlinie festgelegt hätte. ⓘ

Die Disposition spiegelt die veröffentlichte Richtlinie wider, die tatsächlich auf die Nachrichten angewandt wurde: keine, Quarantäne oder Ablehnung. Darüber hinaus sieht DMARC, was in der Tabelle nicht gezeigt wird, die Möglichkeit vor, die Richtlinie zu überschreiben. Einige Gründe, warum ein Empfänger eine andere als die angeforderte Richtlinie anwenden kann, sind bereits in der Spezifikation vorgesehen:

Weiterleitung

unter Beibehaltung der gleichen Bounce-Adresse, verstößt normalerweise nicht gegen DKIM,

abgetastet

weil ein Absender die Richtlinie nur auf einen bestimmten Prozentsatz der Nachrichten anwenden kann,

vertrauenswürdiger Absender

die Nachricht kam von einer lokal bekannten Quelle

Mailingliste

der Empfänger hat heuristisch festgestellt, dass die Nachricht von einer Mailingliste stammt,

lokale Richtlinie

den Empfängern steht es natürlich frei, die Richtlinie anzuwenden, die sie mögen, es ist nur gut, die Absender darüber zu informieren,

andere

wenn keine der obigen Angaben zutrifft, kann man in einem Kommentarfeld weitere Angaben machen. ⓘ

Forensische Berichte

Forensische Berichte, auch bekannt als Failure Reports, werden in Echtzeit erstellt und bestehen aus geschwärzten Kopien einzelner Nachrichten, die SPF, DKIM oder beides nicht bestanden haben, je nachdem, welcher Wert im fo-Tag angegeben ist. Ihr Format, eine Erweiterung des Abuse Reporting Format, ähnelt dem von regulären Bounces, da sie entweder ein "message/rfc822" oder ein "text/rfc822-headers" enthalten. ⓘ

Forensische Berichte enthalten außerdem Folgendes:

• Quelle der sendenden IP-Adresse
• Absender-E-Mail-Adresse
• E-Mail-Adresse des Empfängers
• Betreffzeile der E-Mail
• SPF- und DKIM-Authentifizierungsergebnisse
• Empfangene Zeit
• E-Mail-Kopfzeilen, die den sendenden Host, die ID der E-Mail-Nachricht, die DKIM-Signatur und andere benutzerdefinierte Kopfzeileninformationen enthalten. ⓘ

Kompatibilität

Weiterleitungen

Es gibt verschiedene Arten von E-Mail-Weiterleitungen, von denen einige SPF nicht erfüllen können. ⓘ

Mailing-Listen

Mailinglisten sind eine häufige Ursache für eine legitime Verletzung der DKIM-Signatur der Domäne des ursprünglichen Verfassers, z. B. durch Hinzufügen eines Präfixes zum Betreff-Header. Es gibt eine Reihe von Umgehungsmöglichkeiten, und Softwarepakete für Mailinglisten arbeiten an Lösungen. ⓘ

Alle Nachrichtenänderungen abschalten

Diese Umgehung behält den Standardarbeitsablauf von Mailinglisten bei und wird von mehreren großen Mailinglistenbetreibern übernommen, schließt aber aus, dass die Liste Fußzeilen und Betreff-Präfixe hinzufügt. Dies erfordert eine sorgfältige Konfiguration der Mailing-Software, um sicherzustellen, dass signierte Kopfzeilen nicht neu geordnet oder verändert werden. Ein falsch konfigurierter E-Mail-Server kann List-id in sein DKIM der an eine Mailingliste gesendeten Nachrichten einfügen, und dann ist der Betreiber der Liste gezwungen, sie zurückzuweisen oder From: umzuschreiben. ⓘ

Von: Umschreiben

Eine der populärsten und am wenigsten störenden Abhilfemaßnahmen besteht darin, das From: Header-Feld umzuschreiben. Die Adresse des ursprünglichen Verfassers kann dann in das Reply-To: Feld eingefügt werden. Das Umschreiben kann vom einfachen Anhängen von .INVALID an den Domänennamen bis hin zur Zuweisung einer temporären Benutzer-ID reichen, wobei eine undurchsichtige ID verwendet wird, die die "echte" E-Mail-Adresse des Benutzers vor der Liste geheim hält. Darüber hinaus kann der Anzeigename so geändert werden, dass sowohl der Autor als auch die Liste (oder der Listenbetreiber) angezeigt werden. Diese Beispiele würden jeweils zu einem der folgenden Ergebnisse führen:

From: John Doe <user@example.com.INVALID>
From: John Doe <243576@mailinglist.example.org>
From: John Doe via MailingList <list@mailinglist.example.org>
Antwort-To: John Doe <user@example.com>

Die letzte Zeile, Reply-To:, muss so gestaltet werden, dass die Reply-to-Author-Funktionalität untergebracht werden kann, wobei die Reply-to-List-Funktionalität durch die vorangehende Änderung des From: Header-Feldes abgedeckt wird. Auf diese Weise wird die ursprüngliche Bedeutung dieser Felder umgedreht. ⓘ

Die Änderung des Verfassers ist im Allgemeinen nicht fair und kann die erwartete Beziehung zwischen Bedeutung und Aussehen des Datums zerstören. Es unterbricht auch die automatisierte Nutzung des Datums. Es gibt Gemeinschaften, die Mailinglisten verwenden, um ihre Arbeit zu koordinieren, und die Werkzeuge einsetzen, die das Feld "From:" verwenden, um Anhängen die Urheberschaft zuzuweisen. ⓘ

Andere Umgehungen

Das Einwickeln der Nachricht funktioniert gut, wenn man einen E-Mail-Client verwendet, der eingewickelte Nachrichten versteht. Keine Änderungen vorzunehmen ist vielleicht die naheliegendste Lösung, abgesehen davon, dass sie in einigen Ländern gesetzlich vorgeschrieben zu sein scheinen und dass der routinemäßige Verlust der SPF-Authentifizierung die Gesamtauthentifizierung anfälliger machen kann. ⓘ

Absender-Feld

Änderungen am From: Header-Feld, um den DKIM-Abgleich zu bestehen, können dazu führen, dass die Nachricht nicht mehr mit RFC 5322 Abschnitt 3.6.2 übereinstimmt: "Das 'From:'-Feld gibt den/die Autor(en) der Nachricht an, d. h. die Mailbox(en) der Person(en) oder des Systems/der Systeme, die für das Schreiben der Nachricht verantwortlich sind." Mailbox bezieht sich auf die E-Mail-Adresse des Verfassers. Die Kopfzeile Absender: ist verfügbar, um anzuzeigen, dass eine E-Mail im Namen einer anderen Partei gesendet wurde, aber DMARC prüft die Richtlinie nur für die Domäne Absender und ignoriert die Domäne Absender. ⓘ

Sowohl ADSP als auch DMARC lehnen die Verwendung des Absenderfeldes mit der nicht-technischen Begründung ab, dass viele User-Agents dies dem Empfänger nicht anzeigen. ⓘ

Geschichte

Ein Entwurf der DMARC-Spezifikation wird seit dem 30. Januar 2012 gepflegt. ⓘ

Im Oktober 2013 wurde GNU Mailman 2.1.16 mit Optionen zur Behandlung von Postern von einer Domain mit der DMARC-Richtlinie p=reject veröffentlicht. Mit dieser Änderung wurde versucht, die Interoperabilitätsprobleme zu antizipieren, die erwartet werden, wenn restriktive Richtlinien auf Domänen mit menschlichen Nutzern (im Gegensatz zu reinen Transaktionsmail-Domänen) angewendet werden. ⓘ

Im April 2014 änderte Yahoo seine DMARC-Richtlinie auf p=reject und verursachte damit Fehlverhalten in mehreren Mailinglisten. Ein paar Tage später änderte auch AOL seine DMARC-Richtlinie auf p=reject. Diese Maßnahmen führten zu erheblichen Störungen, und diese Mailbox-Anbieter wurden beschuldigt, die Kosten für ihre eigenen Sicherheitsmängel auf Dritte abzuwälzen. Ab 2020 enthält die FAQ im offiziellen DMARC-Wiki mehrere Vorschläge für Mailinglisten, um Nachrichten von einer Domäne mit einer strengen DMARC-Richtlinie zu behandeln, von denen der am weitesten verbreitete darin besteht, dass die Mailingliste den "From"-Header auf eine Adresse in ihrer eigenen Domäne ändert. ⓘ

Im August 2014 wurde eine IETF-Arbeitsgruppe gebildet, um DMARC-Probleme anzugehen, angefangen bei Interoperabilitätsproblemen bis hin zu einer überarbeiteten Standardspezifikation und Dokumentation. In der Zwischenzeit hatte die bestehende DMARC-Spezifikation einen redaktionellen Stand erreicht, der von vielen akzeptiert und umgesetzt wurde. Sie wurde im März 2015 im Independent Submission Stream in der Kategorie "Informational" (Nicht-Standard) als RFC 7489 veröffentlicht. ⓘ

Im März 2017 veröffentlichte die Federal Trade Commission eine Studie über die Nutzung von DMARC durch Unternehmen. Die Studie ergab, dass von 569 Unternehmen etwa ein Drittel eine DMARC-Konfiguration implementiert hat, weniger als 10 % DMARC verwenden, um Server anzuweisen, nicht authentifizierte Nachrichten zurückzuweisen, und die Mehrheit hat SPF implementiert. ⓘ

Mitwirkende

Zu den Mitwirkenden an der DMARC-Spezifikation gehören:

• Empfänger: AOL, Comcast, Google (Gmail), Mail.Ru, Microsoft (Outlook.com, Hotmail), Netease (163.com, 126.com, 188.com, yeah.net), XS4ALL, Yahoo, Yandex
• Absender: American Greetings, Bank of America, Facebook, Fidelity Investments, JPMorganChase, LinkedIn, PayPal, Twitter
• Vermittler und Anbieter: Agari (Gründer/CEO Patrick R. Peterson), Cloudmark, DMARC Advisor, Red Sift, ReturnPath, Trusted Domain Project ⓘ

Aufbau einer DMARC-Richtlinie

DMARC verwendet, so wie auch SPF und DKIM, TXT-Records im DNS. Für eine Absender-Domain wird auf der Subdomain _dmarc ein Resource Record angelegt, der die DMARC-Richtlinie für diese Absender-Domain enthält. Folgend ist ein Beispiel dargestellt, wie DMARC im TXT-Record von _dmarc.example.org konfiguriert sein könnte:

v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@example.org;ruf=mailto:forensik@example.org;adkim=s;aspf=r <span title="Aus: Deutsche Wikipedia, Abschnitt "Aufbau einer DMARC-Richtlinie"" class="plainlinks">[https://de.wikipedia.org/wiki/DMARC#Aufbau_einer_DMARC-Richtlinie <span style="color:#dddddd">ⓘ</span>]</span>

Abkürzung	Bedeutung	Angabe	Erlaubte Werte	Standardwert, wenn Angabe fehlt ⓘ
v	Protokollversion	notwendig	"DMARC1"	–
pct	Prozentualer Anteil der zu filternden Mails	optional	ganze Zahl zwischen 0 und 100	100
fo	Fehlerberichtsoptionen	optional	"0", "1", "d", "s"	0
ruf	Forensischer Report wird versandt an:	optional	URIs	–
rua	Aggregierter Report wird versandt an:	optional	URIs	–
rf	Format der Fehlerberichte	optional	"afrf"	"afrf"
ri	Intervall zwischen den aggregierten Berichten (in Sekunden)	optional	ganze Zahl	86400
p	Anweisung, wie mit Mails der Hauptdomäne zu verfahren ist.	notwendig	"none", "quarantine", "reject"	–
sp	Anweisung, wie mit Mails der Subdomäne zu verfahren ist.	optional	"none", "quarantine", "reject"	Anweisung der Hauptdomäne
adkim	Abgleichmodus für DKIM	optional	"r", "s"	"r"
aspf	Abgleichmodus für SPF	optional	"r", "s"	"r"

Besondere Bedeutung haben die Abgleichmodi: Für SPF fordert die DMARC-Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt. Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der From Kopfzeile der Mail. Als Abgleichmodi sind s für 'strict' bzw. r für 'relaxed' vorgesehen. Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die From Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse. ⓘ

Die Policy (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie das Empfänger-Mailsystem mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger-Mailsystem keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen. ⓘ

Normen und Standards

• RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015 ⓘ