MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

DMARC p=none und neue RFC9990

Google, Microsoft und Yahoo fordern schon länger eine DMARC-Richtlinie und viele Firmen lösen die Anforderung kurzfristig durch ein "p=none". Das ist nicht genug und wir betrachten und mal Gründe, Ergebnisse und was die im Mai 2026 neue RFC 9990 zu DMARC schreibt.

Korrektur zu Alignment
Ich habe früher gedacht, dass ein DMARC-Record automatisch auch ein Alignment der beiden Absender-Domains (Envelope/Header) erzwingt. Das ist nicht der Fall, wenn die Policy "p=none" ist. Wenn sie auf anderen Seite noch diesen Fehler finden, dann bitte ich um einen kurzen Hinweis.

Keiner mag Phishing

Mail, die eine seriöse Domain missbrauchen um Verbraucher zu überlisten sind fast überall als Betrug strafbar aber kaum zu ahnden, das es viele Domains den Angreifern immer noch zu einfach machen. SPF war ein Anfang und veröffentlich legitime Mailserver und eine Richtlinie zum Umgang, aber ist heute eigentlich alleine wirkungslos. Das neuere DKIM signiert Mails und erlaubt eine Verifizierung über viele Zwischenstationen hinweg, solange die Mail nicht geändert wird, aber enthält keine Richtlinie. Erst mit DMARC können Administrator z.B. vorgeben, wie SPF/DKIM-Ergebnisse zu berücksichtigen und wie unterschiedliche Absenderdomain im Umschlag und Anschreiben zu behandeln sind. Zudem weisen Sie den Empfänger an, eine Rückmeldung der Einlieferung zu liefern.

In einer perfekten Welt veröffentlichen alle Absender eine Liste der IP-Adressen ihrer Mailserver und beenden diese mit einem "-all", damit alle Empfänger nicht legitimierte Server ablehnen können. Das ist gut aber sollte nicht sofort erfolgen, denn ein SPF-Check auf den Umschlag (Envelope, RFC5321.Mailfrom) ist nicht hinreichend. Es könnte ja noch ein SPF(DKIM-Check auf den Absender im Header (RFC5322.From) folgen, der dann die Mail als legitim bewertet. Weiterhin signieren alles Absender ihre Mails per DKIM und eine DMARC-Richtlinie verwirft alle Mails, bei denen nicht eine Prüfung mit einem "PASS" bestanden wird.

Als Ergebnis kann der Absender sichersein, dass seine Domain nicht einfach missbraucht werden kann. Das gilt natürlich nur, wenn die folgenden drei Dinge gegeben sind:

  • Die Malware ist nicht in ihrem Haus
    Wäre schön dumm, wenn Sie eine Malware in ihrem eigenen Netzwerk haben, die Mails über ihre Kette versendet und sie damit alle Anforderungen korrekt umsetzen. Denken Sie einfach an ein gekapertes Benutzerkonto oder eine mal eben schnell installierte Software eines Anwenders
  • DMARC-Richtlinie und Empfänger muss SPF/DKIM/DMARC prüfen
    Das machen die meisten großen Provider aber nicht alle Empfänger sind hier auf der höhe der Zeit. Ich bekomme nur von wenigen Systemen einen DMARC-Record und bin nicht sicher, ob jeder auch meine DMARC-Richtlinie prüft.
    Dazu gehört natürlich auch, dass ich meine DMARC-Richtlinie auf p=Quarantine oder p=reject stellt und nicht auf p=none lasse
  • Ähnlicher Domainname
    Das ganze Schutzsystem taugt nicht um ähnlich aussehende oder lautende Domains zu verhindern. ein "I" statt "l" oder "8" statt "B" oder fremde Zeichensätze fangen Sie so nicht auf.

Was hat es aber nun mit DMARC und insbesondere p=none auf sich?

Schuld sind Google, Microsoft, Yahoo

Im Jahr 2024 hat Google damit angefangen, die Daumenschrauben etwas anzulegen. Zu viele Phishing-Mails an private Anwender dürfte ein Grund gewesen sein, von Firmen ein paar Dinge zu erwarten, die eine Bewertung verbessern. Wer mehr als 5000 Mails/Tag an GMail-Konten senden will, muss einen DMARC-Eintrag machen. Dabei hat das jeder Betreiber etwas anders umschrieben.

Hoster Anforderung
Google GMAIL
1. Feb 2024

Google hat im Jahr 2024 angefangen, dass alle Absender-Domains mit mehr als 500 Mails/Tag eine DMARC-Richtlinie veröffentlichen müssen.


Quelle: https://support.google.com/a/answer/81126

Wer weniger als 5000 Mails sendet, kann sich auf SPF oder DKIM beschränken. Google erlaubt bei DMARC sogar ein "p=none.
Microsoft outlook.com
Mai 2025

Microsoft hat eine ähnliche Änderung zum Mai 2025 umgesetzt

Ein p=none ist erlaubt, aber die Aussage zum Alingment ist mehrdeutig. Wenn Microsoft nichts geschrieben hätte, dann könnte man einfach die RFC zitieren und SPF bezieht sich auf den RFC5321.MailFrom während DKIM sich auf den RC5322.From bezieht. Aber die explizite Erwähnung könnte man auch so lesen, dass die beiden Domain zueinander passen müssen und quasi ein DMARC-Alignment genutzt wird, obwohl DMARC mit p=none eigentlich dies nicht fordert.

Yahoo

Auch Yahoo hat hier nachgezogen und fordert SPF und DKIM-Eínträge als auch DMARC.


Quelle https://senders.yahooinc.com/best-practices/& 

Auch hier ist ein "DMARC p=none" erlaubt aber im Text steht weiterhin, dass die Domain aus dem der FROM-Header, den der Anwender sieht, auch für SPF herangezogen wird. Das ist kein klassisches DMARC-Alignment aber auch nicht mehr der alte SPF-Check auf die Absenderdomain im Envelope

Das waren sicherlich Auslöser, warum viele Firmen mittlerweile einen DMARC-Record gesetzt haben. Das bedeutet aber nicht, dass sich die Administratoren auch damit auseinandergesetzt haben. Die Veröffentlichung einer neuen RFC zu DMARC ist vielleicht ein

RFC9989 und P=none

Ehe Sie nun panisch schnell einen DMARC-Eintrag anlegen, um mit outlook.com, gmail.com und Yahoo.com kompatibel zu sein, sollten Sie erst einmal sicherstellen, dass Sie den richtigen Eintrag vornehmen. Alle drei großen Mailboxbetreiber akzeptieren auch ein "DMARC:p=none", was klassische als Monitoring-Mode angesehen wird. Die RFC schreibt dazu an mehreren Stellen:

 


Quelle: https://datatracker.ietf.org/doc/html/rfc9989#section-3.2.9

Jeder Wert, der nicht p=none ist, führt zu einem Enforcement. Also kann ich um Umkehrschluss auch sagen, dass ein "p=none" kein Enforcement durchsetzen soll.

Im Abschnitt 3.2.12 Monitoing mode finden sich weitere Anweisungen zu DMARC mit p=none:


Quelle: https://datatracker.ietf.org/doc/html/rfc9989#section-3.2.12

Ich fände besser, wenn hier klar stehen würde,  wie das Handling aussehen soll. Ein "expresses no handling preference" kann unterschiedlich interpretiert werden.

Im Abschnitt "4.7. DMARC Policy Record Format" (https://datatracker.ietf.org/doc/html/rfc9989#section-4.7) steht unter "p" dann:

 
Quelle: https://datatracker.ietf.org/doc/html/rfc9989#name-dmarc-policy-record-format

Auch hier gilt: Wenn es keinen gültigen "p="-Eintrag gibt, dann soll ein "p=none" angenommen werden.

In 4.10.1 DMARC Policy Discovery wird der Fall behandelt, dass es eine DMARC-Richtlinie mit einem RUA-Eintrag aber keine passende "Policy p=" gibt.


https://datatracker.ietf.org/doc/html/rfc9989#section-4.10.1 DMARC Policy Discovery 

Dann muss DMARC eine Policy mit p="none" ansetzen. Es ist die Einstellung, die den geringsten direkten Schaden für den Absender bedeutet.

Auch in  5.4 Policy Enforcement Considerations (https://datatracker.ietf.org/doc/html/rfc9989#section-5.4) findet sich eine klare Aussage:


Quelle: https://datatracker.ietf.org/doc/html/rfc9989#section-5.4 

Der Absatz fordert explizit dazu auf, dass eine p=none-Richtline es dem Empfänger eigentlich untersagt, die DMARC-Bewertung in die gesamte Filter-Bewertung mit einzubeziehen.

Besonders wichtig finde ich der RFC auch den Hinweis auf die Pflicht seine Mails per DKIM zu signieren, wenn man eine MARC-Policy mit "p=reject" einsetzt:


Quelle: https://datatracker.ietf.org/doc/html/rfc9989#section-7.4

Das ist auch notwendig, denn es viel zu viele Fälle, bei denen ein klassischer SPF-Check regulär auf einen FAIL läuft und dann solche Mails  nicht zugestellt würden. Denken Sie einfach an Mailinglisten, Weiterleitungen, Migrationen etc., bei denen eine Mail von A an B durch das System B dann weiter an C gesendet wird. Wenn der Absender "A" bleibt und nicht mittels Sender Rewriting Scheme (SRS) umgeschrieben wird und der Mail-Admin A eine Liste der gültigen Server für die Domain veröffentlicht hat, dann wird B dort in der Regel nicht auftauchen und C die Mail dann ablehnen. Hier ist es dann wichtig, dass DKIM und vielleicht sogar ARC - Authenticated Received Chain die Zustellung absichern.

Im Appendix B.2.1 steht noch:


Quelle: https://datatracker.ietf.org/doc/html/rfc9989#appendix-B.2.1 

P=none und Spamfilter

Selbst die  RFC9989 gesteht jedem Administrator zu, seine eigenen Regeln zu machen. Im Grunde ist DMARC ja gut gemacht und könnte sehr gut funktionieren, wenn möglichst viele Empfänger eine entsprechende Prüfung umsetzen und alle Absender auch per DKIM signieren. Große aktuelle Marktteilnehmer machen schon länger DKIM und fordern ihre Kunden auch auf, DKIM zu aktivieren. Aber es gibt nicht nur Provider, die hier etwas nachhängen sondern auch Produkte, die voll in der Wartung stehen aber diese Funktion nicht addiert ist. Hier ist Exchange SE (OnPremises) aus meiner Sicht ein Negativbeispiel, da es immer noch keine DKIM-Signatur mitbringt. Sie können es mit 3rd Party Tools als Transport Agent nachrüsten oder ihr Exchange Server nutzt ausgehend ein Relay wie NoSpamProxy, Exchange Online o.ä., die die fehlende DLKIM-Signatur ergänzen.

Auch beim Empfang kann ich die DMARC-Policy respektieren aber auch pberstimen.


Quelle: https://security.microsoft.com/antiphishing

Auch hier gilt wieder, dass die DMARC-Richtlinie eher ein Wunsch des Absenders ist, dem sich der Empfänger aber entziehen kann. Allerdings kann ich nicht nicht eine "p=none"-Richtlinie überstimmen, Ich kann nur eine "p=quarantine" und "p=reject" etwas abmildern. Andere Spamfilter wie z.B. NoSpamProxy gehen hier weiter. Es klingt doch sinnvoll, sich pro Domain den SPF/DKIM/DMARC-Status zu merken und wenn eine Domain kontinuierlich und fehlerfrei Mails mit DKIM-Signatur sendet aber der Admin immer noch ein "p=none" hat, dann kann ich durchaus überlegen, dennoch eine DKIM-Signatur zu fordern und Mails ohne entsprechende Signatur einfach schlechter zu bewerten.

p=none ist kein Phishing-Schutz

Aus Sicht einer Spamfilterung und Verweigerung einer Annahme ist ein "p=none" identisch zu einem fehlenden oder unvollständigen DMARC Eintrag. Der Empfänger kann durchaus die durch DMARC vorgegeben Prüfungen durchführen aber sollte die Ergebnisse nicht in die Entscheidung zur Annahme oder Ablehnung der Mail einbeziehen. Damit ist DKIM aber wirklungslos.

Achtung:
Ohne DMARC-Policy wird eine gefälschte oder veränderte Mail, die den DKIM-Test nicht besteht, dennoch zugestellt. Sie schwächen damit also ihre eigene SMTP-Domain.

Insofern finde ich es auch seltsam, dass Microsoft, Google, Yahoo nur einen DMARC-Eintrag als solches fordern aber die Einstellung einer strickten Policy nicht naheliegen.
Ich kann mir hier nur vorstellen, dass GMail und Co darauf hoffen, dass jeder mit DMARC dann auch DKIM signiert und der Empfänger ja seine eigene Logik bauen kann. DMARC und RFCs sind keine Gesetze, sondern Empfehlungen, von denen man individuell abweichen kann. Letztlich entscheidet der empfangende Mail-Admin, was er umsetzt. Aufgrund der Schwäche von SPF gib es viele Firmen, denen SPF=PASS schon lange nicht mehr reicht und ein SPF=FAIL nicht gleich zum Abbruch der Verbindung führt.

DMARC p=none nur Zwischenschritt

Daher sollten Sie den Mode "p=none" nicht als Dauerlösung sehen, nur um die Anforderungen von Microsoft, Google, Yahoo zu erfüllen. Wenn man sich streng an der RFC orientiert, dann ist eine DMARC-Policy mit "p=none" genauso gut oder schlecht, wie keine Policy. Dennoch fordern Microsoft, Google, Yahoo diesen DNS-Eintrag und empfehlen sogar eine Policy mit "p=none". Schließlich möchte man ja nicht für gestörte Zustellungen an andere Systeme verantwortlich gemacht werden.

Ich kann mir nur vorstellen, dass die drei die "p=none"-Policy nicht 1:1 umsetzen, sondern je nach Mail und Domain dann ihre Regeln etwas anpassen.

Interessant wird es dann, wenn Administratoren für DMARC sensibilisiert werden, entsprechend DKIM-Signaturen einrichten, die RUF-Meldungen einsammeln und dann vielleicht ein p=quarantäne oder sogar ein p=reject setzen.

Die RFC 9989 schreibt dazu, das eine Domain mit "p=none" startet und zusätzlich einen RUA-Eintrag


Quelle :https://datatracker.ietf.org/doc/html/rfc9989#section-5.1.4

Danach wertet man die einkommenden DMARC-Berichte aus und passt die eigene Konfiguration an, ehe man einige Wochen später mit ausreichend Sicherheit alle eigenen Versendet korrekt konfiguriert zu haben.

Zur Einführung von DMARC habe ich eine eigene Seite auf DMARC einführen geschrieben.

p=reject meint Quarantäne?

Sie wissen nun, das p=none ohne RUA eine schlechte Option ist und mit einem RUA-Eintrag sollten Sie die Rückmeldungen prüfen und dann auf "p=quarantine" oder besser noch "p=reject" stellen. Aber dann kommt eine Aussage der RFC9989 hier ins Spiel:


RFC9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)  - 7.4. Interoperability Considerations
https://datatracker.ietf.org/doc/html/rfc9989#section-7.4

Die RFC9989 lockert damit ihre eigene Vorgaben hinsichtlich "p=reject" auf. Als Besitzer einer Domain kann ich sicherstellen, dass all meine ausgehenden Server in einem SPF-Record aufgeführt sind und jede Mail korrekt DKIM-signiert sind. Wenn ich dann aber mit "p=reject" alle möglichen Empfänger aber anweisen möchte, die mögen alle nicht konformen Mails ablehnen, dann besagt die RFC, dass die Empfänger meiner Vorgaben nicht folgen sollen.

Die Aussage steht unter "Interoperability Considerations" und der Absatz verweist auf die verschiedenen Probleme, die insbesondere bei indirekten Mails über Mailinglisten etc. ohne DKIM-Signatur auftreten können. Es ist nun mal nicht einfach, jedem Domaininhaber diese Fälle zu beschreiben aber Nutzer könnten sich beschweren. Vielleicht wurde daher der "besser Quarantäne statt Reject"-Ansatz gewählt. Dann hätte man aber "p=reject" aber auch gleich sein lassen können.

Letztlich gilt aber bei jedem Spam/Phishing-Schutz die Aussage: "Mein Haus, meine Hausordnung" und jeder kann die Annahme einer Mail anhand eigener Vorgaben steuern. Ich sollte nur sicherstellen, dass ich wirklich die Mails dann ablehne und nicht unterdrücke oder in eine Qurantäne lege, die niemand sieht und letztlich nach Ablaug einiger Tage geleert wird.

Weitere Links