ExchangeServer

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Overview

DMARC baut auf SPF und DKIM auf und verknüpft deren Ergebnis mit der sichtbaren Absenderadresse (Header From). Der Domaininhaber veröffentlicht eine Richtlinie und Adressen für Berichte, Empfänger handeln danach und melden zurück, wer im Namen der Domain sendet.

Lange beschrieb RFC 7489 (2015) das Verfahren, als informatives Dokument. Im Mai 2026 hat die IETF mit RFC 9989 eine Neufassung als Proposed Standard veröffentlicht, die RFC 7489 und das experimentelle RFC 9091 ablöst; Aggregat- und Fehlerberichte sind in eigene Dokumente ausgelagert. Bestehende Einträge mit v=DMARC1 bleiben gültig.

Die wichtigsten Änderungen: Die Organisationsdomain wird per DNS Tree Walk statt über die Public Suffix List ermittelt. Die Tags pct, rf und ri entfallen, neu sind t (Testmodus), np (Richtlinie für nicht existierende Subdomains) und psd. Große Anbieter verlangen DMARC mindestens mit p=none von Massenversendern: Google und Yahoo seit Februar 2024, Microsoft für Outlook.com seit 5. Mai 2025 bei mehr als 5.000 Mails pro Tag.

How it works

Der DMARC-Eintrag liegt als TXT-Record unter _dmarc.domain, etwa v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com. Die Prüfung beim Empfänger:

  1. SPF und DKIM werden wie gewohnt ausgewertet.
  2. Alignment: Mindestens eine der bestandenen Prüfungen muss zur Domain im Header From passen, standardmäßig relaxed (gleiche Organisationsdomain) oder strict (exakt gleiche Domain).
  3. Fehlt eine ausgerichtete Prüfung, greift die Richtlinie: p=none (nur beobachten), p=quarantine (Junk oder Quarantäne) oder p=reject (Ablehnung).
  4. Empfänger senden täglich Aggregatberichte an die rua-Adresse, die Quellen, Ergebnisse und Volumen zeigen.

Exchange Online wertet eingehend die DMARC-Richtlinie des Absenders aus (Einstellung „Honor DMARC record policy“, Standard an): reject führt zur Ablehnung mit 550 5.7.1, quarantine zu Junk oder Quarantäne. Fehlerberichte (ruf) verschickt Microsoft 365 nicht.

Benefits

  • Wirksamer Schutz davor, dass Dritte die eigene Domain für Betrugsmails fälschen
  • Berichte machen unbekannte und vergessene Absender sichtbar
  • Bessere Zustellbarkeit bei Google, Yahoo und Outlook.com, die DMARC voraussetzen
  • Schutz von Marke und Vertrauen bei Kunden und Partnern

Practical example

Ein Händler mit mehreren Mailquellen startet mit p=none und einer Berichtsadresse, die ein Analysewerkzeug auswertet. Nach vier Wochen zeigen die Berichte zwei vergessene Systeme, die ohne DKIM und außerhalb von SPF senden. Nach deren Anbindung stellt die IT auf quarantine und nach weiteren Wochen auf reject um. Gefälschte Mails im Namen des Händlers werden seitdem abgewiesen, auch bei den großen Freemail-Anbietern.

Things to keep in mind

  • Schrittweise von none über quarantine zu reject gehen und jeweils Berichte auswerten
  • Vor dem Verschärfen alle legitimen Absender mit SPF oder DKIM passend zur Absenderdomain ausrichten
  • Berichtsadresse nicht an ein persönliches Postfach koppeln, sondern ein Analysewerkzeug nutzen
  • Nicht sendende Domains mit p=reject absichern
  • Microsoft-Doku zeigt noch das Tag pct, das RFC 9989 streicht, für schrittweises Vorgehen künftig t=y einplanen und Empfängerunterstützung prüfen

Conclusion

DMARC schließt die Lücke, die SPF und DKIM allein lassen. Der Weg zu reject braucht Geduld und Berichtsauswertung, lohnt sich aber für jede Domain, die für Betrug missbraucht werden kann.

Further reading

Related articles