Ein großes Problem im Mailverkehr ist das Fälschen der dem Empfänger angezeigten Absenderadresse im From:-Header. Der Inhalt ist nicht relevant für den Transportvorgang und daher vom Absender beliebig setzbar. Für den Transport wird die Envelope-From-Adresse benutzt. Hier die Namen der verschiedenen Absenderadressen einer Email, die in der Literatur verwendet werden:

Das Hauptziel von DMARC  ist es nun, die dem Empfänger sichtbare Absenderadresse im Header-From verifizierbar zu machen. Damit kann dem Empfänger signalisiert werden, ob diese Mail tatsächlich von der Organisation/Einrichtung/Firma des vermeintlichen Absenders kommt oder gefälscht wurde. Um dieses Ziel zu erreichen werden die Checkergebnisse von SPF und DKIM hinzugezogen. SPF kann den Envelope-From mit IP-Adressen der sendenden Mailserver verknüpfen, DKIM kann bestätigen, dass der Inhalt der Mail und damit auch des Header-From während des Transports unverändert blieb und verknüpft dies mit einer der Domains (DKIM-Domain) der absendenden Einrichtung.

Zusätzlich muss der Absender für seine Domain einen DMARC-DNS-Record aufsetzen, damit der DMARC-Check beim Empfänger auch aktiv wird. In ihm kann der Absender eine Policy festlegen, was der Empfänger mit einer Mail machen soll, deren DMARC-Check fehlschlägt:

• Checkergebnis ignorieren
• Mail in Spamfolder verschieben
• Mail ablehnen

• Die Vorteile liegen im Bereich von Transaktions-Emails, also z.B. Bankenkommunikation, 2FA-Mails, Accounterstellung usw.
• Wenn der Mailclient des Empfängers das Ergebnis des Checks anzeigen würde, könnte der Empfänger erkennen, ob es sich wirklich um seine Bank/Online-Shop/etc handelt oder die Mail gefälscht wurde.
• Wenn der Mailserver des Empfängers passende Reputationsdatenbanken (Black-/Whitelisten) besitzt, kann er anhand des DMARC-Checks auch Mails ablehnen. Dies sollte aber nur für Domains geschehen, die vor allem Transaktions-Emails versenden.

• Wie bei SPF und DKIM auch werden Weiterleitungen und Mailinglisten nicht berücksichtigt, was die konsequente Verwendung des DMARC-Checks erschwert.
• Jeder Spammer/Phisher kann SPF/DKIM/DMARC/ARC-DNS-Records aufsetzen und die Mails signieren. Das Ergebnis des Checks ist alleine für sich also kein Grund, eine Mail abzulehnen oder durchzulassen.

Mailinglisten bekommen durch DMARC ein weiteres Problem der Zustellbarkeit. Sie können zur Mitigation drei Strategien fahren:

1. Die Mails unverändert durchreichen (nur der Envelope-From wird modifiziert).
   Aber: Dies scheitert, wenn die Mails beim Empfang entweder keine DKIM-Signatur aufweisen oder diese bereits ungültig ist.
2. Die Mails unverändert durchreichen (nur der Envelope-From wird modifiziert) und eine ARC-Signatur hinzufügen.
   Aber: Dies scheitert, wenn beim Empfänger ARC nicht unterstützt wird.
3. Den Header-From auf sich umschreiben.
   Aber: Der Empfänger kann dann nicht mehr feststellen, wer der ursprüngliche Absender war und ob er gefälscht wurde.

• Der Absender kann getrennte oder gemeinsame Policies für die Hauptdomain und deren Subdomains definieren.
• Der Absender kann für SPF und DKIM getrennt den Alignment-Modus bestimmen, d.h. ob beim Vergleich mit dem Header-From auch beliebige Subdomains der Hauptdomain akzeptiert werden oder nicht.
• Der Absender kann eine Report-Mailadresse definieren, an die der Empfänger (z.B. täglich) eine Zusammenfassung aller ihn betreffenden DMARC-Checks als Report zugesendet bekommt. Reports versenden einiger der großen Mailprovider.
• Der Absender kann für Debugzwecke eine Forensik-Mailadresse definieren, an die der Empfänger pro einzelner Email mit fehlgeschlagenem DMARC-Check einen detaillierten Report versendet.
• Man kann definieren, auf wieviel Prozent der Mails die Policy angewendet werden soll. Damit kann z.B. beim Aktivieren der Policy für einen Testzeitraum die Anzahl der False Positives im Falle von Fehlkonfigurationen reduziert werden.

Man setzt vor die Domain ein _dmarc und fragt den TXT-Record ab. Beispiel:

Hierfür gibt es eine Reihe von Online-Diensten:

• https://mxtoolbox.com/dmarc.aspx
• https://dmarcly.com/tools/dmarc-checker

Der DMARC-Algorithmus sieht vor, nach der Domain des Header-From zu suchen und bei Nichtexistenz nach der Organizational Domain. Diese Orgdomain bestimmt DMARC mit Hilfe der Mozilla Public Suffix List. Die Einträge sind freiwillig und enthalten alle Top-Level-Domains sowie Domain-Registrare, Web-Service-Provider und ähnliches, welche Subdomains an ihre Kunden delegieren.

Von der Domain werden rückwärts solange die Subdomains entfernt, bis der Rest in der Suffix-Liste auftaucht. Danach wird die letzte entfernte Subdomain wieder angefügt.

Beispiel: mx.srv.dfn.de. Nur de taucht in der Suffixliste auf, nicht aber dfn.de. DMARC sucht dann nur unter:

• _dmarc.mx.srv.dfn.de
• _dmarc.dfn.de

Folgende drei Policies kann man in seinem DMARC-DNS-Record setzen:

Derzeit gibt es einige Strategien der Mailprovider, wie mit den Problemfeldern Weiterleitungen, Mailinglisten und Fehlkonfigurationen umgegangen wird:

• Als Absender: Verwendung der Policy none. Nur wenige der größeren Mailprovider (z.B. Yahoo) trauen sich, eine reject-Policy zu fahren.
• Als Empfänger: Man behandelt die Policy reject identisch zur Policy quarantine. Die Mails werden also nicht abgelehnt sondern nur in den Spamfolder verschoben.

Der Vergleich des Header-From mit der DKIM-Domain oder der SPF-Domain (Envelope-From) kann in zwei Varianten stattfinden:

 Das Alignment lässt sich für DKIM und SPF getrennt definieren.

Sendet man ausgehende Mails für verschiedene Subdomains, z.B. Institute, so sollte man entweder unterschiedliche Envelope-From (=> SPF) oder unterschiedliche DKIM-Domains verwenden sowie das Alignment auf strict setzen, damit DMARC eindeutig zwischen den Instituten unterscheiden und ein Institut nicht Mails im Namen eines anderen Instituts versenden kann.

Im DFN-MailSupport führt der Spamassassin die DMARC-Checks durch. Als Ergebnis setzt er folgende Checks in den X-Spam-Report-Header der Mail bzw. in die Amavis-Syslog-Zeilen:

Nutzen Sie das ausgehende Filtern des DFN-MailSupports, so können Sie DMARC-DNS-Records für Ihre Domains aufsetzen, wenn Sie bereits SPF-DNS-Records veröffentlicht haben und Ihre Mails DKIM-signieren oder von uns DKIM-signieren lassen.

1. Score-Anpassungen für beliebige Absender-Domains.
   Die Scores obiger Checks lassen sich beliebig anpassen.
2. Score-Anpassungen für eigene Absender-Domains.
   Der DMARC-Check wird für die eigenen Domains mit erhöhten Scores versehen, um zB Phishing mit gefälschten Absendern abzulehnen. Die Liste der Domains muss über die Hotline konfiguriert werden. Hierfür muss ihr DMARC-Record zwar existieren, aber die Policy muss nicht auf reject gesetzt werden, es genügt auch die ansonsten gefahrlos verwendbare Policy none.
3. DMARC-analoger Check ohne DMARC-DNS-Record.
   Hierbei wird die Mail abgelehnt, wenn eine der eigenen Domains im From:-Header verwendet wird. Wie unter Punkt 2 muss allerdings die Liste der Domains, für die dieser Check durchgeführt werden soll, über unsere Hotline konfiguriert werden

 Ein Whitelisting kann über die amavis_whitelist_spam_*-Listen erfolgen.