DMARC-Policy: p=none vs. p=reject

Wer sich einen DMARC-Eintrag ansieht, findet fast immer einen von drei Werten hinterp=: none, quarantine oder reject. Die kurze Antwort auf die Frage „was ist üblich?“: Ein großer Teil der Domains, die überhaupt einen DMARC-Eintrag veröffentlichen, bleibt dauerhaft bei p=none – also der reinen Monitoring-Stufe ohne jede Durchsetzung. Das ist keine bewusste Sicherheitsentscheidung, sondern meistens ein liegen gebliebener erster Schritt. Aktuelle Verteilungen über deutsche Domains findest du im Live-Datensatz unter /email-stats/; in diesem Artikel geht es darum, was hinter den drei Stufen steckt und warum der Sprung zu p=reject so oft ausbleibt.

Die drei Policy-Stufen: none, quarantine, reject

DMARC baut auf SPF und DKIM auf und legt fest, was ein empfangender Server mit einer Mail tun soll, die den Alignment-Check nicht besteht – also weder per SPF noch per DKIM glaubwürdig auf die Absenderdomain zurückgeführt werden kann.

• p=none – nichts passiert an der Zustellung. Der Empfänger meldet den Vorfall nur in seinen Aggregatberichten (rua) zurück. Reines Monitoring.
• p=quarantine – Mails, die durchfallen, werden typischerweise in den Spam-Ordner verschoben statt zugestellt.
• p=reject – Mails, die durchfallen, werden vom empfangenden Server komplett abgewiesen. Erst hier verhindert DMARC aktiv, dass jemand deine Domain für Phishing missbraucht.

Warum so viele Domains bei p=none stehen bleiben

Ein DMARC-Eintrag mit p=none ist in wenigen Minuten gesetzt und macht auf den ersten Blick nichts kaputt – genau deshalb ist er der beliebteste Einstieg. Das Problem: Viele Verantwortliche setzen den Eintrag einmal, lesen nie wieder die Aggregatberichte aus und lassen die Domain dauerhaft in der Monitoring-Stufe stehen. Damit ist DMARC formal vorhanden, schützt aber nicht vor Domain-Spoofing – und erfüllt auch die Anforderungen großer Mailboxanbieter an Massenversender nur zur Hälfte, denn Google und Yahoo verlangen für Bulk-Sender inzwischen mindestens einen gültigen DMARC-Eintrag, empfehlen aber ausdrücklich den Weg in Richtung Durchsetzung.

Der eigentliche Grund für das Zögern ist selten Bequemlichkeit allein, sondern berechtigte Vorsicht: Wer viele Versandwege hat – eigener SMTP-Server, ein ESP wie CleverReach, rapidmail oder Mailjet, dazu Transaktionsmails aus Shopware oder WooCommerce – muss erst sicherstellen, dass jeder dieser Wege SPF und DKIM sauber durchreicht. Sonst sortiert eine strengere Policy plötzlich legitime Rechnungsmails oder Newsletter aus.

Was für den Sprung zu p=reject nötig ist

Bevor du die Policy verschärfst, solltest du wissen, welche Systeme überhaupt in deinem Namen versenden. Die Aggregatberichte (rua) sind dafür die einzig verlässliche Quelle – sie listen jede sendende IP samt SPF- und DKIM-Ergebnis. Typische blinde Flecken in deutschen Setups:

• Shop-Plattformen wie Shopware oder JTL-Shop, die Transaktionsmails ohne externen SMTP-Connector direkt vom Hosting-Server verschicken.
• WooCommerce-Installationen, die über wp_mail() laufen statt über einen SMTP-Plugin mit eigenem Absenderdomain-DKIM.
• Externe Tools (CRM, Support-Desk, HubSpot-Formulare), die im Namen der Domain, aber über eigene Server senden.
• Mailinglisten und Weiterleitungen, die SPF systembedingt brechen und nur über korrektes DKIM-Alignment überleben.

Risiken eines verfrühten p=reject

Der größte Fehler ist, direkt von p=none auf p=reject zu springen, ohne die Berichte gelesen zu haben. Folgen in der Praxis: Rechnungsmails aus dem Shopsystem kommen nicht an, ein vergessener Newsletter-Versand über einen zweiten ESP wird komplett verworfen, interne Weiterleitungen an Kolleg:innen mit privaten GMX- oder Web.de-Adressen brechen. Solche Ausfälle bemerkt man oft erst, wenn Kund:innen sich beschweren – zu spät für einen entspannten Rollback.

Der sichere Weg: schrittweise Eskalation

1. p=none setzen, rua-Adresse eintragen, mindestens einige Wochen Berichte sammeln und alle sendenden Systeme identifizieren.
2. Für jedes System SPF-Include und DKIM-Selector korrekt konfigurieren, bis die Berichte durchgehend „pass“ zeigen.
3. Auf p=quarantine mit niedrigem pct (z. B. einem kleinen Prozentsatz) umstellen und beobachten.
4. pct schrittweise erhöhen, bis 100 % erreicht sind und keine legitimen Fehlschläge mehr auftauchen.
5. Erst dann auf p=reject wechseln – im Zweifel wieder mit niedrigem pct beginnend.

Diese Reihenfolge kostet Wochen, nicht Stunden – dafür bleibt die Zustellung deiner eigenen Mails während des ganzen Prozesses stabil. Für DACH-Absender kommt ein rechtlicher Aspekt hinzu: Nach UWG §7 braucht kommerzieller E-Mail-Versand ohnehin eine nachweisbare Einwilligung (in der Praxis meist Double-Opt-in) – ein sauberer DMARC-Rollout ist die technische Ergänzung dazu, kein Ersatz für die rechtliche Einwilligungsbasis.

Was das für deine eigene Domain bedeutet

Wenn du aktuell nur einen SPF-Eintrag und vielleicht DKIM hast, aber (noch) kein DMARC: Fang mit p=none an, das ist der risikofreie erste Schritt. Wenn du schon länger bei p=none stehst: Das ist der häufigste Zustand überhaupt – nutze ihn aktiv, indem du die Aggregatberichte tatsächlich auswertest, statt sie ungelesen zu lassen. Und wenn du schon bei p=reject bist: Prüfe nach jeder neuen Versandintegration (neuer ESP, neues CRM, neues Shop-Plugin) erneut, ob deren SPF/DKIM korrekt eingebunden ist – sonst bricht die strikte Policy genau diesen neuen Kanal.