DMARC Reject: Sender prüfen und die Richtlinie einführen

Eine DMARC-Reject-Richtlinie fordert eine strengere Behandlung an als die Beobachtung mit p=none. Berichte sind dabei möglich, aber nicht garantiert. Bereits Quarantine ist eine Form der Durchsetzung. Ein zu früher Wechsel zu p=reject kann Rechnungen, Passwortzurücksetzungen und Supportantworten treffen. Für die Grundlagen beginnen Sie mit geschäftlicher E-Mail.

Während der Beobachtung besteht weiterhin das Risiko gefälschter Nachrichten. Eine strikte DMARC-Reject-Richtlinie erfordert deshalb gründliche Vorbereitung, damit gewünschte Nachrichten nicht beeinträchtigt werden. Hier finden Sie Prüfkriterien, einen möglichen Ablauf und wichtige Fehlerbilder für 2025 und 2026.

Voraussetzung	Planungsziel	Bedeutung vor DMARC Reject
Verkehr beobachten	30 Tage als Orientierung	Monatliche Abläufe erfassen; seltene Versandzyklen zusätzlich prüfen
Ausrichtung prüfen	100% der legitimen Sender erfolgreich ausgerichtet	SPF- oder DKIM-Erfolg ohne Ausrichtung genügt nicht
Reputation kontrollieren	Spamrate unter 0.1%	Beschwerden bleiben auch bei korrekter Authentifizierung wichtig
Weiterleitung testen	Gültiges ausgerichtetes DKIM bleibt erhalten	SPF kann bei Weiterleitungen scheitern
Subdomains prüfen	Tag `sp` berücksichtigen	Vererbte Richtlinien können Entwicklungs- oder Altsysteme betreffen

Was eine DMARC-Reject-Richtlinie bewirkt

Eine DMARC-Reject-Richtlinie fordert Empfänger auf, Nachrichten abzulehnen, wenn weder SPF noch DKIM erfolgreich und zur Absenderdomain ausgerichtet ist. Das kann direktes Domain-Spoofing begrenzen. Die endgültige Behandlung richtet sich jedoch auch nach lokalen Empfängerregeln.

Entscheidend ist die Ausrichtung zur sichtbaren From-Domain. Bei gelockerter Ausrichtung kann dieselbe Organisationsdomain genügen; bei strikter Ausrichtung müssen die Domains identisch sein. Erfolgreiche Authentifizierung allein bestätigt weder DMARC-Ausrichtung noch unbedenklichen Inhalt.

RFC 7489 beschreibt die angeforderte Stichprobe mit pct sowie lokale Entscheidungen zur Behandlung. Eine DMARC-Reject-Richtlinie ersetzt deshalb weder gute Reputation noch korrekte Versandkonfiguration; die Umsetzung der Stichprobe kann zwischen Empfängern abweichen.

Voraussetzung 1: eine 30-tägige Beobachtung planen

Eine DMARC-Reject-Richtlinie sollte nicht allein auf einer unauffälligen Berichtswoche beruhen. Dreißig Tage sind eine Planungsorientierung, kein universeller Nachweis. Quartalsberichte, seltene Begrüßungsnachrichten und Supportautomatisierungen benötigen gegebenenfalls längere Beobachtung oder eigene Tests.

Nach sieben Tagen scheinbar sauberer Berichte kann ein Wechsel zu p=reject noch immer den nächsten Rechnungslauf treffen. Teilnehmende Empfänger berichten zudem nicht zwingend über sämtliche Nachrichten.

Beispiel: Ein Abrechnungsdienst versendet nur zu Monatsbeginn. SPF und DKIM bestehen für seine eigenen, nicht ausgerichteten Domains. Mit p=none fordert Ihre Domain keine Durchsetzung an. Nach p=reject können diese Rechnungen abgelehnt werden.

Achten Sie auch auf seltene wertvolle Nachrichten von Abrechnung, Personalsoftware, Scannern, Formularen und Helpdesks. Eine DMARC-Reject-Richtlinie folgt auf die Bestandsaufnahme und Prüfung, nicht umgekehrt.

Offene DNS-Probleme sollten Sie zuerst untersuchen. TrekMails Anleitung zu erforderlichen DNS-Einträgen erläutert die vorgesehene Einrichtung mit SPF, DKIM, MX und DMARC.

Voraussetzung 2: Ausrichtung statt nur Authentifizierung prüfen

Vor einer DMARC-Reject-Richtlinie sollte jeder legitime Sender über erfolgreiches ausgerichtetes SPF oder DKIM verfügen. Ein Dienst kann seine eigene Domain authentifizieren, ohne die From-Domain Ihrer Nachricht auszurichten.

Ein typischer Fall bei externen Diensten:

Header From: support@yourcompany.com
Return-Path: bounce.vendor-mail.com, SPF besteht dafür
DKIM: d=vendor-mail.com, DKIM besteht dafür
Ergebnis: DMARC scheitert für yourcompany.com

Eine positive Anbieteranzeige belegt in diesem Fall keine Ausrichtung für Ihre Domain. Mit einer DMARC-Reject-Richtlinie können diese Nachrichten abgelehnt werden.

Prüfen Sie die Domainauthentifizierung beim Anbieter:

Dessen DKIM-Einträge veröffentlichen und die Signierung mit Ihrer Domain aktivieren.
Einen passenden eigenen Bounce- oder Return-Path-Domainnamen für SPF-Ausrichtung einrichten.
Echte Nachrichtenheader prüfen, nicht nur eine positive Statusanzeige.

Berücksichtigen Sie die SPF-Grenze von zehn ausgewerteten DNS-auslösenden Mechanismen und Modifikatoren; es geht nicht um sämtliche DNS-Abfragen. Mehrere SPF-Einträge ergeben einen dauerhaften Fehler statt einer zusammengeführten Richtlinie. TrekMails Domain-Einrichtungsanleitung behandelt diese häufige Fehlkonfiguration.

Voraussetzung 3: Reputation vor Reject prüfen

Eine DMARC-Reject-Richtlinie kann direkte Fälschungen begrenzen, behebt aber keine schlechte Reputation. Beschwerden und problematische Inhalte müssen unabhängig von DMARC untersucht werden.

Googles Absenderhinweise empfehlen Massenversendern eine Spamrate unter 0.1% und das Vermeiden von 0.3% oder mehr; höhere Werte können die Möglichkeiten zur Problemminderung beeinflussen. Yahoo nennt ebenfalls 0.3% als zu unterschreitende Grenze. Prüfen Sie die jeweils aktuellen Vorgaben und Messgrundlagen.

Zeigt Postmaster etwa 0.18%, sollten Sie Listenqualität und Nachrichtenrelevanz untersuchen. Gleichzeitig können DMARC-Probleme bestehen; eine Beschwerderate schließt Authentifizierungsfehler nicht aus.

Vor einer DMARC-Reject-Richtlinie prüfen:

Die Spamrate der primären Versanddomain in Google Postmaster Tools.
Beschwerdespitzen einzelner Kampagnen, Listen oder Dienste.
Rückmeldungen, die auf veraltete Adressen oder ungeeignete Empfänger hinweisen.
Gemeinsame Reputation von Transaktions- und Marketingnachrichten.

Maßgebliche Anbieterhinweise: Google-Absenderrichtlinien FAQ und Yahoo-Empfehlungen für Absender.

Voraussetzung 4: Weiterleitungen vor Reject testen

Für eine DMARC-Reject-Richtlinie sind echte Weiterleitungstests wichtig. SPF kann am neuen Server scheitern. Gültiges ausgerichtetes DKIM kann DMARC bestehen lassen, sofern die signierten Daten unter den Kanonisierungsregeln erhalten bleiben.

Ein SPF-Fehler in Berichten ist nicht automatisch eine Fälschung. Untersuchen Sie den Weiterleiter, die Mailingliste oder das Sicherheitsgateway. Besteht DKIM erfolgreich mit Ausrichtung, kann DMARC weiterhin bestehen.

Bereiten Sie daher wichtige DKIM-Versandströme und tatsächliche Weiterleitungswege vor, bevor Sie eine DMARC-Reject-Richtlinie aktivieren. Auch ARC stellt keine einheitliche Empfängerentscheidung sicher.

TrekMails Spam-Fehlersuche erläutert SPF-Fehler bei erhaltenem DKIM. Bei korrekt eingerichtetem verwaltetem Versand in entsprechenden kostenpflichtigen Tarifen kann mit Ihrer Domain signiert werden. Für den konkreten Weiterleitungsweg hilft E-Mail-Weiterleitung.

Prüfen Sie außerdem Meine E-Mails landen im Spam und IMAP- und SMTP-Einstellungen. Die Dokumentation erklärt Authentifizierungsfälle und Versandkonfiguration. SRS kann die Envelope-SPF-Prüfung verbessern, garantiert aber keine Ausrichtung zur ursprünglichen From-Domain oder Zustellung.

Voraussetzung 5: die Subdomain-Richtlinie prüfen

Eine DMARC-Reject-Richtlinie der Organisationsdomain kann auch Subdomains betreffen. Prüfen Sie Sender unter dev.example.com, alerts.example.com und anderen Namen sowie das Tag sp.

Produktivsysteme können korrekt eingerichtet sein, während Testumgebungen, Drucker, Scanner oder alte Dienste fehlen. Subdomains ohne eigenen passenden DMARC-Eintrag können eine Richtlinie der Organisationsdomain erben.

Das Tag sp kann diese geerbte Behandlung ändern:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com

Die Hauptdomain fordert Reject an, erbende Subdomains erhalten None. Eigene Subdomain-Einträge können abweichen. Prüfen Sie diese Quellen, bevor auch ihre Richtlinie verschärft wird.

Berichte im Zusammenhang mit einer DMARC-Reject-Richtlinie können unbekannte CRMs, Marketingwerkzeuge, alte Anwendungen oder Entwickler-Relays sichtbar machen. Sie ergänzen die Bestandsaufnahme, beweisen aber keine vollständige Erfassung sämtlicher Sender.

Reject schrittweise statt ungeprüft einführen

Eine DMARC-Reject-Richtlinie kann am Ende einer gestaffelten Einführung stehen. Quarantine ist bereits Durchsetzung. Die angeforderte Stichprobe über pct wird nicht von allen Empfängern gleich umgesetzt; ergänzen Sie Berichte durch gezielte Tests.

Ein möglicher, anzupassender Plan:

Mit 10% Quarantine für eine Woche beginnen, soweit Empfänger die Stichprobe berücksichtigen.
Nach Prüfung 100% Quarantine für weitere ein bis zwei Wochen erwägen.
Reject erst nach Tests von Support, Abrechnung, Authentifizierung und Weiterleitung aktivieren.

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Diese Einträge sind aufeinanderfolgende Alternativen, nicht gemeinsam zu veröffentlichen. Quarantine garantiert keine wiederherstellbare Ablage, und Reject bedeutet nicht immer endgültigen Verlust: Rückmeldungen und Wiederholungsversuche hängen vom Versandweg ab. Eine DMARC-Reject-Richtlinie kann dennoch gewünschte Nachrichten schon beim Empfang verhindern.

DMARC Reject für mehrere Domains verwalten

Eine DMARC-Reject-Richtlinie wird bei zehn, fünfzig oder fünfhundert Domains aufwendiger. Anbieter unterscheiden sich bei DKIM, DNS verändert sich und neue Dienste kommen hinzu. Ein gepflegter Senderbestand wird dadurch besonders wichtig.

Verteilter Ablauf: XML manuell lesen, Anbieter zuordnen und DNS für jede Domain einzeln korrigieren.

Gemeinsamer Ablauf: Domains zentralisieren, DNS-Verfahren vereinheitlichen und tatsächliche Nachrichten systematisch prüfen.

TrekMail nennt kostenpflichtige Tarife als Preisorientierung ab $3.50 monatlich mit verwaltetem SMTP. Eine gemeinsame Oberfläche kann Domains, IMAP-Postfächer, Weiterleitung und DNS-Prüfungen verbinden. Nano wird kostenlos für bis zu 10 Domains mit eigenem SMTP angeboten. Die verfügbaren Bedingungen und Funktionen sollten Sie prüfen. Das Mehrdomain-Modell erläutert E-Mail-Hosting für mehrere Domains.

Für kleine Teams kann das weniger verstreute Konfiguration bedeuten, für Agenturen und MSPs einheitlichere Abläufe. Weniger Aufwand oder Supportfälle sind jedoch kein garantiertes Ergebnis einer DMARC-Reject-Richtlinie oder der Plattformwahl.

Einzelheiten bieten TrekMails erforderliche DNS-Einträge und der Tarifvergleich auf trekmail.net/pricing. Kostenpflichtige Tarife können eine 14-tägige Testphase mit erforderlicher Kreditkarte bieten; Nano wird ohne Karte angeboten. Prüfen Sie aktuelle Bedingungen.

Fazit: wann Reject veröffentlichen?

Vor einer DMARC-Reject-Richtlinie sollten Sie Beobachtung, legitime Sender, Beschwerden, Weiterleitungen und Subdomains geprüft haben. Mindestens 30 Tage können eine Orientierung sein, reichen aber für seltene Versandzyklen nicht automatisch. Berichte allein beweisen keine vollständige Ausrichtung.

Identifizieren Sie Sender, lesen Sie echte Header und korrigieren Sie DNS. Veröffentlichen Sie die DMARC-Reject-Richtlinie nach geeigneten Tests und mit einem Reaktionsplan, um eine strengere Behandlung direkter Domain-Fälschungen anzufordern.

Für gemeinsame Domainverwaltung beginnen Sie bei TrekMail oder vergleichen die aktuellen Tarife auf trekmail.net/pricing.