So richten Sie DMARC ein: Vollständige Schritt-für-Schritt-Anleitung zur Konfiguration (2026)

E-Mail-Anbieter betrachten die Einrichtung von DMARC nicht mehr als bloßes „Nice-to-have“ in Sachen Sicherheit. Da Gmail, Yahoo und Microsoft strengere Authentifizierungsanforderungen durchsetzen, riskieren Unternehmen, die DMARC noch nicht implementiert haben, eine dauerhafte Zurückweisung ihrer E-Mails, vermehrte Spoofing-Angriffe und Probleme bei der Einhaltung gesetzlicher Vorschriften.

In diesem Leitfaden erfahren Sie, wie Sie DMARC von Grund auf einrichten, Ihre SPF- und DKIM-Konfiguration überprüfen, einen konformen DMARC-Eintrag veröffentlichen und schrittweise vom Überwachungsmodus zur vollständigen Durchsetzung übergehen. Außerdem behandeln wir die neuesten Aktualisierungen des RFC 9989, häufige Konfigurationsfehler und praktische Tipps zur Fehlerbehebung, damit Sie DMARC sicher einsetzen können.

Am Ende dieser Anleitung zur DMARC-Einrichtung verfügen Sie über einen klaren Fahrplan, wie Sie Ihre Domain vor Spoofing-Angriffen schützen und gleichzeitig sicherstellen können, dass legitime E-Mails weiterhin im Posteingang ankommen.

Einhaltung der Vorschriften für 2026: Die Durchsetzung hat begonnen

Gmail & Yahoo (Nov. 2025): Die dauerhafte Durchsetzung der 5xx-Ablehnung ist für Massenversender (5.000+ E-Mails/Tag) in Kraft getreten. Nicht konforme Nachrichten werden dauerhaft abgelehnt und nicht nur gefiltert.

Microsoft Outlook (Mai 2025): SPF-, DKIM- und DMARC-Überprüfung aktiv. Nicht konforme E-Mails werden zurückgestellt oder abgelehnt.

PCI DSS v4.0 (März 2025): Für alle Unternehmen, die Zahlungskartendaten verarbeiten, sind Maßnahmen zum Schutz vor Phishing vorgeschrieben.

• CISA BOD 18-01: Alle US-Bundesbehörden müssen DMARC mit der Richtlinie „p=reject“ einsetzen.
• Vollständige Anforderungen anzeigen: Globale und regionale DMARC-Anforderungen

Was ist DMARC und wie funktioniert es?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist ein E-Mail-Authentifizierungsprotokoll, mit dem Domain-Inhaber den empfangenden Mail-Servern mitteilen können, wie mit Nachrichten umgegangen werden soll, die die SPF- und DKIM-Authentifizierungsprüfungen nicht bestehen. Einfach ausgedrückt: Es verhindert, dass andere Ihre Domain fälschen, und gibt den Empfängern Anweisungen, wie sie mit Betrügern umgehen sollen.

DMARC baut auf zwei bestehenden Protokollen auf: SPF und DKIM. Zusammen bilden diese drei Protokolle die Grundlage für moderne E-Mail-Sicherheit.

DMARC, SPF und DKIM: Wie sie zusammenwirken

SPF (Sender Policy Framework) legt fest, welche Mailserver E-Mails von Ihrer Domain versenden dürfen. Es handelt sich um einen DNS-Eintrag, der besagt: „Nur diese IP-Adressen dürfen E-Mails versenden, die angeblich von example.com stammen.“

DKIM (DomainKeys Identified Mail) versieht Ihre E-Mails mit einer kryptografischen Signatur. Diese belegt, dass die Nachricht von Ihnen stammt und während der Übertragung nicht verändert wurde. Die Signatur wird anhand eines in Ihrem DNS veröffentlichten öffentlichen Schlüssels überprüft.

DMARC verbindet diese Elemente miteinander. Es besagt: „Hier ist meine Richtlinie. Wenn eine E-Mail vorgibt, von meiner Domain zu stammen, muss sie die SPF- oder DKIM-Überprüfung bestehen. Falls dies nicht der Fall ist, soll Folgendes geschehen: keine Maßnahme (nur überwachen), Quarantäne (in den Spam-Ordner verschieben) oder Ablehnung (vollständig blockieren).“

Erfahren Sie in unserem umfassenden Leitfaden mehr über DMARC, SPF und DKIM.

Was passiert, wenn eine E-Mail die DMARC-Prüfung nicht besteht?

Wenn ein Empfänger eine E-Mail erhält, die angeblich von Ihrer Domain stammt, gleicht er diese mit Ihrer DMARC-Richtlinie ab. Das Ergebnis hängt von Ihrer Richtlinie ab:

• p=none (Überwachung): Die E-Mail wird unabhängig vom Ergebnis zugestellt. Sie erhalten einen Bericht, aus dem hervorgeht, was erfolgreich war und was fehlgeschlagen ist.
• p=Quarantäne: E-Mails, die die Überprüfung nicht bestehen, werden in den Spam-/Junk-Ordner verschoben. Legitime E-Mails kommen weiterhin an.
• p=reject: Fehlerhafte E-Mails werden sofort abgelehnt. Der Absender erhält eine Rückmeldung.

Bevor Sie DMARC einrichten: Voraussetzungen und Absenderverzeichnis

Viele Unternehmen beeilen sich, DMARC einzuführen und stellen die Einstellung schnell auf „p=reject“ um, nur um dann festzustellen, dass legitime Absender (CRM, ESP, Helpdesk, Marketing-Automatisierungsplattformen) blockiert werden. Dieser Abschnitt führt Sie durch den Überprüfungsprozess, um diesen kostspieligen Fehler zu vermeiden.

Schritt 1: Überprüfen Sie, ob für Ihre Domain ein SPF-Eintrag veröffentlicht wurde

Ihre Domain muss über einen gültigen SPF-Eintrag im DNS verfügen, damit DMARC funktionieren kann.

1. Nutzen Sie unseren SPF-Checker, um zu überprüfen, ob Ihr SPF-Eintrag vorhanden ist.

2. Vergewissern Sie sich, dass für Ihre Domain genau ein SPF-TXT-Eintrag vorhanden ist. Bei zwei SPF-Einträgen funktioniert SPF nicht, da die Empfänger beide ignorieren.

3. Der Eintrag sollte in etwa so aussehen: v=spf1 include:sendgrid.net include:mailchimp.com ~all

Falls kein SPF-Eintrag veröffentlicht wurde oder zwei widersprüchliche Einträge vorliegen, beheben Sie diesen Fehler bitte zuerst, bevor Sie fortfahren. Nutzen Sie unser kostenloses Tool, um jetzt Ihren SPF-Eintrag zu erstellen.

Schritt 2: Überprüfen Sie das Abfrage-Limit für SPF 10

SPF erlaubt maximal 10 DNS-Abfragen pro Nachrichtenauswertung. Jeder von Ihnen autorisierte Drittabsender (über „include:“) verbraucht 1 bis 3 dieser Abfragen. Wird das Limit überschritten, schlägt die SPF-Prüfung für einige Absender fehl.

1. Nutzen Sie unseren SPF-Checker, um die Anzahl der Abfragen Ihres SPF-Eintrags zu überprüfen

2. Zählen Sie die erforderlichen DNS-Abfragen. Wenn Sie sich der Zahl 10 nähern oder diese überschreiten, wird eine Fehlermeldung angezeigt.

3. Wenn Sie das Limit überschreiten, optimieren Sie Ihren Datensatz, um Abfragen zu bündeln, indem Sie „include:“-Anweisungen durch explizite IP-Adressen ersetzen. Dies ist ein häufiges Hindernis für große Unternehmen mit vielen externen Absendern.

Schritt 3: Überprüfen Sie, ob DKIM für alle Absender konfiguriert ist

DKIM wird von Google, Yahoo und Microsoft für Massenversender vorgeschrieben und ist nicht optional.

1. Für Ihre primäre Domain: Nutzen Sie unseren kostenlosen DKIM-Checker, um zu überprüfen, ob Ihr DKIM-Eintrag veröffentlicht ist.

2. Überprüfen Sie für jeden externen Absender (Salesforce, HubSpot, Klaviyo usw.), ob dieser die DKIM-Signatur aktiviert und seinen öffentlichen Schlüssel als DNS-Eintrag veröffentlicht hat. Dazu müssen Sie den Anbieter in der Regel bitten, „benutzerdefiniertes DKIM für Ihre Domain zu aktivieren“.

3. Jeder Absender sollte über einen eindeutigen DKIM-Selektor verfügen (z. B. k1._domainkey.example.com, sendgrid._domainkey.example.com).

Falls DKIM noch nicht eingerichtet ist, konfigurieren Sie es jetzt, bevor Sie zur DMARC-Durchsetzung übergehen. Nutzen Sie unser kostenloses Tool, um einen DKIM-Eintrag für Ihre Domain zu generieren.

Schritt 4: Erfassung aller externen E-Mail-Absender

Erstellen Sie eine Liste aller Dienste, die E-Mails über Ihre Domain versenden:

• E-Mail-Dienstleister (SendGrid, Mailchimp, Klaviyo usw.)
• CRM (Salesforce, HubSpot, Pipedrive usw.)
• Helpdesk-/Support-Systeme (Zendesk, Freshdesk usw.)
• Marketing-Automatisierung (Marketo, Pardot, ActiveCampaign usw.)
• Plattformen für Transaktions-E-Mails (Auth0, Stripe, AWS SES usw.)
• Interne Server oder Anwendungen, die Benachrichtigungen versenden
• Weiterleitungsdienste oder Mailinglisten-Betreiber

Überprüfen Sie für jeden Absender Folgendes:

1. Sie erfüllen die SPF-Übereinstimmungsanforderungen (die in Ihrem SPF-Eintrag enthalten sind)
2. Sie erfüllen die DKIM-Anforderungen (DKIM-Signatur für Ihre Domain aktiviert)
3. Sie sind so konfiguriert, dass sie Ihre Domain im „From:“-Header verwenden.

Nutzen Sie unseren DMARC-Berichtsanalysator, um nach unbefugten Absendern zu suchen.

Schritt 5: Überprüfen Sie, ob bereits ein DMARC-Eintrag vorhanden ist

Nutzen Sie unseren DMARC-Checker, um zu überprüfen, ob für Ihre Domain bereits ein DMARC-Eintrag vorhanden ist.

• Wenn „p=none“ angezeigt wird: Ihre Domain befindet sich im Überwachungsmodus. Diese Anleitung hilft Ihnen dabei, sicher in den Durchsetzungsmodus überzugehen.
• Falls Sie veraltete Tags (pct=, rf=, ri=) sehen: Diese sind nicht mehr Bestandteil des RFC 9989-Standards und sollten bei der nächsten Bearbeitung des Eintrags entfernt werden.
• Falls kein Eintrag gefunden wurde: Sie fangen von vorne an. Fahren Sie mit dem nächsten Abschnitt fort.

So richten Sie DMARC ein: Schritt für Schritt

Schritt 1: Einen DMARC-Eintrag erstellen

Nutzen Sie unseren DMARC-Generator, um Ihren ersten Eintrag zu erstellen.

Pflichtfelder:

• Domain: Ihre Domain (z. B. example.com)
• Richtlinie: Beginne mit p=none (Überwachungsmodus, keine Durchsetzung)
• Berichtsadresse: E-Mail-Adresse, an die Sie die zusammenfassenden Berichte erhalten möchten (z. B. [email protected])

Empfohlene Ergänzungen:

• np=reject: Schützt nicht existierende Subdomains vor Spoofing (neu in RFC 9989, ohne Mehraufwand)
• rua-Adresse: Ziel für den Sammelbericht (entscheidend für die Überwachung)

Beispiel für einen Startdatensatz:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Dieser Eintrag weist die Empfänger an: „Überwacht E-Mails aus meiner Domain und sendet mir tägliche Berichte, blockiert aber vorerst noch nichts.“

Schritt 2: Machen Sie sich vor der Veröffentlichung mit Ihrem DMARC-Eintrag vertraut

Ein DMARC-Eintrag besteht aus einer Reihe von Tag-Wert-Paaren, die durch Semikolons voneinander getrennt sind. Nur „v=“ und „p=“ sind obligatorisch – alle anderen Angaben sind optional, werden jedoch empfohlen. Machen Sie sich vor der Veröffentlichung mit der Funktion der einzelnen Tags vertraut:

Erforderliche Tags

Tag	Beschreibung & Regeln
v= (Version)	• Wert: Immer v=DMARC1 • Muss das erste Tag im Datensatz sein • Es gibt nur einen gültigen Wert
p = (Richtlinie)	• Werte: none, quarantine, oder reject • Erläutert den Empfängern, wie sie mit E-Mails umgehen sollen, die die DMARC-Prüfung nicht bestehen • Die Unterschiede entnehmen Sie bitte der nachstehenden Tabelle mit den Versicherungsbedingungen

Optionale Tags

np= (keine Richtlinie für Subdomains)

• Werte: „none“, „quarantäne“ oder „ablehnen“
• Wendet eine Richtlinie auf Subdomains an, die keinen DMARC-Eintrag haben
• Schützt vor Spoofing von zufällig generierten Subdomains (z. B. random123.example.com)
• Empfehlung: Setzen Sie „np=reject“ für alle Domänen. Das kostet nichts und schließt eine Sicherheitslücke im Zusammenhang mit Spoofing.

rua= (Meldungsadresse für Sammelberichte)

• Format: rua=mailto:[email protected]
• Es können mehrere Adressen durch Kommas getrennt angegeben werden: rua=mailto:[email protected],mailto:[email protected]
• Aggregatberichte sind XML-Zusammenfassungen, die täglich von den Empfängern versendet werden
• Dies ist für die Überwachung von entscheidender Bedeutung. Ohne diese Funktion haben Sie keinen Einblick in Ihren E-Mail-Verkehr.

sp= (Richtlinie für Subdomänen)

• Werte: „none“, „quarantäne“ oder „ablehnen“
• Wendet eine Richtlinie auf Subdomains an, die über einen DMARC-Eintrag verfügen
• Sofern nicht anders angegeben, wird auf die Hauptrichtlinie zurückgegriffen (p=)
• Verwenden Sie diese Option, wenn Sie eine strengere Durchsetzung für Subdomains wünschen (z. B. mail.example.com)

fo= (Optionen zur Fehlermeldung)

• Werte: 0 (Standard), 1, d, s oder Kombinationen (0:1:d:s)
• Steuert, wann forensische (Fehler-)Berichte versendet werden
• fo=0: Berichte nur erstellen, wenn alle Authentifizierungsmechanismen fehlschlagen
• fo=1: Berichte erstellen, wenn ein Authentifizierungsmechanismus fehlschlägt (ausführlichere Ausgabe, nützlich für die Einrichtungsphase)
• Wird in der Regel zusammen mit dem Tag „ruf=“ verwendet (siehe unten)
• Empfehlung: Verwenden Sie bei der Ersteinrichtung „fo=1“, um alle Fehler zu erkennen; wechseln Sie zu „fo=0“, sobald Sie von Ihrer Ausrichtung überzeugt sind.

adkim= (DKIM-Abgleichmodus)

• Werte: r (locker, Standard) oder s (streng)
• Gelockert: Die Domain und die DKIM-Signatur-Domain gehören zur selben Organisationsdomain (z. B. stimmen „mail.example.com“ und „example.com“ überein)
• Streng: Die Domänen müssen exakt übereinstimmen
• Empfehlung: Beginnen Sie mit „adkim=r“ (gelockert). Wechseln Sie erst dann zu „strict“, wenn Sie alle Signaturquellen unter Kontrolle haben.

aspf= (SPF-Ausrichtungsmodus)

• Werte: r (locker, Standard) oder s (streng)
• Entspannt: Die Domain und die SPF-Return-Path-Domain stimmen mit der Organisationsdomain überein
• Streng: Die Domänen müssen exakt übereinstimmen
• Empfehlung: Beginnen Sie mit „aspf=r“. Wechseln Sie erst dann zu „strict“, wenn Sie alle Absenderquellen unter Kontrolle haben.

t= (Testmodus)

• Werte: y (Testmodus ein) oder keine Angabe (Testmodus aus)
• Bei der Einstellung t=y wird den Empfängern signalisiert, Ihre Richtlinie eine Ebene tiefer anzuwenden
• p = Quarantäne; t = y verhält sich für Empfänger wie p = keine
• p = „Ablehnen“; t = „y“ verhält sich für die Empfänger wie p = „Quarantäne“
• Dies ist der Ersatz für das veraltete pct=-Tag.
• Verwendung beim Übergang zu einer strengeren Richtlinie: Veröffentlichung mit t=y, Überwachung der Berichte, anschließend Entfernung von t=y zur Durchsetzung

ruf= (Adresse des forensischen Gutachtens)

• Format: ruf=mailto:[email protected]
• Versendet Echtzeit-Kopien von Nachrichten, bei denen die Authentifizierung fehlgeschlagen ist
• Wichtiger Hinweis: Google, Microsoft und Yahoo versenden keine forensischen Berichte mehr (gemäß RFC 9989). Die Einbindung dieses Tags ist unbedenklich, führt jedoch nicht zur Erstellung von Berichten durch die großen Empfänger.
• Bitte nur einfügen, wenn Sie über ein automatisiertes System zur Bearbeitung forensischer Berichte verfügen

Veraltete und entfernte Tags (RFC 9989)

Diese Tags waren Teil von RFC 7489, sind aber nicht mehr Bestandteil des Standards. Fügen Sie sie nicht zu neuen Einträgen hinzu. Sollten sie in bestehenden Einträgen vorkommen, entfernen Sie sie bei Ihrer nächsten DNS-Bearbeitung.

pct=

• Wurde verwendet, um eine Richtlinie auf einen bestimmten Prozentsatz der fehlgeschlagenen Nachrichten anzuwenden
• Lieferte bei den verschiedenen Empfängern uneinheitliche Ergebnisse
• Ersatz: Verwenden Sie stattdessen „t=y“ für eine schrittweise Einführung
• Sofern es sich noch um alte Datensätze handelt, wird es von RFC 9989-konformen Empfängern ignoriert.

rf=

• War das Format-Tag für den Fehlerbericht (es wurde immer nur ein Wert verwendet: afrf)
• Entfernt, da die moderne Berichterstellung einen anderen Mechanismus verwendet

ri=

• War das Tag für das Berichtsintervall
• Entfernt, da die Berichtsintervalle nun standardisiert sind

Schritt 2: Melden Sie sich bei Ihrem DNS-Anbieter an

Melden Sie sich bei Ihrer DNS-Verwaltungskonsole an (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53 usw.).

Schritt 3: Fügen Sie den DMARC-Eintrag über Ihren DNS-Anbieter hinzu

Suchen Sie die Option zum Hinzufügen eines neuen TXT-Eintrags, kopieren Sie den Wert aus dem Tool und fügen Sie ihn ein und klicken Sie dann auf das Symbol „Speichern“.

Der Vorgang ist bei allen Anbietern identisch: Fügen Sie einen neuen TXT-Eintrag hinzu, geben Sie als Namen „_dmarc“ ein, fügen Sie Ihren Eintrag als Wert ein und speichern Sie die Änderung. Die anbieterspezifischen Navigationspfade und die häufigsten Fallstricke für jeden Anbieter sind in der folgenden Tabelle aufgeführt.

Schritt 5: Warten Sie, bis die DNS-Änderungen übernommen wurden

Es kann bis zu 48 Stunden dauern, bis sich DNS-Änderungen weltweit durchgesetzt haben, doch bei den meisten DNS-Anbietern erfolgt die Durchsetzung innerhalb von 1–2 Stunden. Um die Durchsetzung in Echtzeit zu überwachen, können Sie unseren DNS-Propagation-Checker nutzen. Geben Sie einfach Ihre Domain ein und suchen Sie nach dem _dmarc-TXT-Eintrag.

Schritt 6: Überprüfen Sie, ob Ihre DMARC-Konfiguration aktiv ist

Sobald die DNS-Propagierung abgeschlossen ist, überprüfen Sie Ihren Eintrag mit unserem DMARC-Checker-Tool.

1. Geben Sie Ihren Domainnamen ein
2. Auf „Lookup“ klicken
3. Ihr Datensatz sollte nun mit allen analysierten Tags angezeigt werden
4. Wenn der Checker bei Ihrer Richtlinie die Meldung „DMARC-Eintrag gefunden“ anzeigt, ist die Richtlinie aktiv.

Sollten Fehler auftreten oder der Eintrag nach 48 Stunden noch nicht gefunden worden sein, überprüfen Sie Ihren DNS-Eintrag auf Syntax- und Konfigurationsfehler.

Einrichtung von DMARC gemäß RFC 9989 – Was sich im Jahr 2026 geändert hat

Im Mai 2026 veröffentlichte die IETF den RFC 9989, der den RFC 7489 als offiziellen DMARC-Standard ablöst. Ihre bestehenden v=DMARC1-Einträge behalten ihre volle Gültigkeit, sodass keine dringende Migration erforderlich ist. Allerdings gibt es drei Änderungen, die alle betreffen, die DMARC heute konfigurieren.

Was RFC 9989 für Ihre DMARC-Konfiguration bedeutet

1. „pct=“ ist nun veraltet.

Das `pct=`-Tag wurde verwendet, um eine Richtlinie auf einen bestimmten Prozentsatz fehlgeschlagener Nachrichten anzuwenden. Es führte zu uneinheitlichen Ergebnissen bei den verschiedenen Empfängern und ist nicht mehr Teil des Standards.

Maßnahme: Entfernen Sie „pct=“ aus allen neuen Einträgen. Falls ältere Einträge diesen Eintrag enthalten, entfernen Sie ihn bei Ihrer nächsten DNS-Bearbeitung. Die Empfänger ignorieren ihn zwar, aber er sorgt für Verwirrung.

2. np= ist neu

Mit dem Tag „np=“ (Richtlinie für nicht existierende Subdomains) können Sie Subdomains schützen, die gar nicht existieren. Angreifer können beliebige Subdomains vortäuschen (z. B. random123.example.com), um DMARC-Prüfungen zu umgehen. Durch die Einstellung „np=reject“ wird diese Sicherheitslücke ohne zusätzlichen Aufwand geschlossen.

Aktion: Dies ist optional, Sie können jedoch festlegen, dass sie allen neuen Datensätzen hinzugefügt wird.

3. „t=y“ ist der neue Ansatz zur Umsetzung politischer Veränderungen

Das Tag „t=y“ weist die Empfänger an, Ihre Richtlinie eine Ebene tiefer als angegeben anzuwenden. Auf diese Weise können Sie eine strengere Richtlinie testen, bevor Sie diese endgültig durchsetzen.

• p = Quarantäne; t = y verhält sich wie p = keine (Empfänger führen keine Quarantäne durch; sie stellen die Nachrichten zu und melden sie)
• p = ablehnen; t = y verhält sich wie p = unter Quarantäne stellen (Empfänger stellen unter Quarantäne, anstatt abzulehnen)

Maßnahme: Beim Wechsel von p=none zu p=quarantine oder p=reject zunächst t=y verwenden. Die Berichte 1–2 Wochen lang überwachen. Sobald Sie sich sicher sind, t=y entfernen, um die Einstellung durchzusetzen.

So verwenden Sie „t=y“ für eine schrittweise Einführung

So sieht der genaue Arbeitsablauf aus:

1. Aktueller Stand:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. Wenn Sie bereit sind, die Quarantäne zu testen, veröffentlichen Sie:

v=DMARC1; p=quarantine; t=y; np=reject; sp=quarantine; rua=mailto:[email protected]

Die Empfänger behandeln dies als „p=none“, sie liefern alles aus und erstatten Bericht. Sie beobachten die Situation 1–2 Wochen lang.

3. Vergewissern Sie sich, dass keine legitimen E-Mails betroffen sind, und entfernen Sie anschließend „t=y“, um die Änderung zu übernehmen:

v=DMARC1; p=quarantine; np=reject; sp=quarantine; rua=mailto:[email protected]

4. Nun landen fehlerhafte E-Mails im Spam-Ordner, während legitime E-Mails davon unberührt bleiben.

5. Sobald Sie bereit sind, die Ablehnungsrichtlinie zu testen, veröffentlichen Sie sie:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

6. Die Empfänger betrachten dies als p = Quarantäne. Sie müssen die Situation 1–2 Wochen lang beobachten.

7. Abschließende Ausführung: t=y entfernen:

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

8. Die vollständige Ablehnung ist nun aktiv.

Sollte in einem der Schritte ein Fehler auftreten: Entfernen Sie t=y, gehen Sie eine Richtlinienebene zurück, beheben Sie den Fehler beim Absender und fahren Sie dann fort.

So setzen Sie Ihre DMARC-Richtlinie sicher um

Die meisten DMARC-Fehler treten auf, weil Unternehmen direkt auf „p=reject“ umstellen, ohne zuvor ihren E-Mail-Verkehr zu überprüfen. Legitime E-Mails werden blockiert, Nutzer beschweren sich, und der Domaininhaber macht in seiner Panik einen Rückzieher. In diesem Abschnitt wird Ihnen die richtige Vorgehensweise erläutert: eine Einführung in drei Phasen, bei der mithilfe von Gesamtberichten vor jedem Schritt Vertrauen aufgebaut wird.

Hinweis: In RFC 9989 wird ausdrücklich festgelegt, dass Empfänger bei indirekten E-Mail-Flüssen (Weiterleitung, Mailinglisten) „p=reject“ wie „p=quarantine“ behandeln müssen. Für Domänen, deren Nutzer an Mailinglisten teilnehmen, ist „p=quarantine“ die sicherere Richtlinie für die dauerhafte Durchsetzung. Für reine Transaktions- oder Marketing-Domänen ohne Benutzerpostfächer ist „p=reject“ angemessen.

Phase 1: Überwachung (p = keine)

Dauer: mindestens 2–4 Wochen. Bei komplexen Versandumgebungen (10 oder mehr Drittanbieter als Absender) kann es länger dauern.

So sieht Ihre Bilanz aus:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Was ist zu tun?

1. Den obenstehenden Eintrag veröffentlichen

2. Warten Sie, bis die Empfänger die zusammengefassten Berichte gesendet haben (dies geschieht in der Regel innerhalb von 24–48 Stunden).

3. Nutzen Sie unseren DMARC-Berichtsanalysator, um die täglichen Berichte zu überprüfen

4. Achten Sie auf:

• Alle bekannten Absender, die in den Berichten aufgeführt sind
• SPF- und DKIM-Erfüllungsquoten für jeden Absender
• Unbekannte Absender, die Sie nicht erkennen
• Status der Konformitätsprüfung (erfüllen Ihre Absender die Konformitätsanforderungen oder nicht?)

Wann man vorrücken sollte:

• Alle legitimen Absender erfüllen die SPF- oder DKIM-Anforderungen.
• Keine unbekannten Quellen in den Berichten
• Sie haben mindestens zwei Wochen lang konsistente Daten erfasst
• Sie haben alle fehlerhaften Absender behoben

Wenn Sie noch keine Erfahrung mit DMARC-Berichten haben, finden Sie in unserem Leitfaden zum Lesen von DMARC-Berichten eine leicht verständliche Anleitung.

Phase 2: Quarantäne (p = Quarantäne)

Dauer: 1–2 Wochen im Testmodus (t=y), danach fortlaufend.

Schritt A: Test mit t=y (Probelauf)

Veröffentlichen:

v=DMARC1; p=quarantine; t=y; np=reject; sp=quarantine; rua=mailto:[email protected]

Bei t=y wenden die Empfänger die Richtlinie eine Ebene tiefer an: Die Quarantäne verhält sich so, als gäbe es keine. Fehlerhafte E-Mails werden weiterhin zugestellt; Sie erhalten lediglich Berichte, aus denen hervorgeht, was unter normalen Umständen in Quarantäne gestellt worden wäre.

Beobachten Sie die Situation 1–2 Wochen lang. Sehen Sie sich die Berichte an und überprüfen Sie Ihren Posteingang. Achten Sie auf Folgendes:

• Es gehen weiterhin legitime E-Mails ein
• Fehlerberichte, aus denen hervorgeht, welche Absender betroffen wären
• Übliche Spam-Beschwerdequoten

Schritt B: Durchsetzen (t=y entfernen)

Sobald Sie sich sicher sind, entfernen Sie t=y:

v=DMARC1; p=quarantine; np=reject; sp=quarantine; rua=mailto:[email protected]

Fehlerhafte E-Mails landen nun im Spam-Ordner. Legitime E-Mails kommen weiterhin wie gewohnt an.

Laufende Überwachung:

• Die Gesamtberichte wöchentlich überprüfen
• Den Spam-Ordner auf legitime E-Mails überprüfen
• Falls legitime Absender ausfallen: sofort auf „p=none“ zurückfallen, das Ausrichtungsproblem beheben und dann den Vorgang fortsetzen

Hinweis zur BIMI-Zulassung: Wenn Sie BIMI (Brand Indicators for Message Identification) nutzen möchten, um Ihr Logo in Gmail anzuzeigen, muss bei Ihrer Domain „p=quarantine“ oder „p=reject“ eingestellt sein. „p=none“ ist nicht zulässig. Dies unterstreicht die Dringlichkeit, die entsprechenden Richtlinien voranzutreiben. So aktivieren Sie BIMI für Ihre Domain.

Phase 3: Ablehnen (p = ablehnen)

Dauer: 1–2 Wochen mit t=y, danach fortlaufend.

Schritt A: Test mit t=y (Probelauf)

Veröffentlichen:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

Bei t=y behandeln Empfänger „Reject“ als Quarantäne. Fehlerhafte E-Mails landen im Spam-Ordner und werden nicht sofort abgelehnt. Beobachten Sie die Situation 1–2 Wochen lang.

Schritt B: Durchsetzen (t=y entfernen)

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

Fehlerhafte E-Mails werden nun sofort zurückgewiesen. Der Absender erhält eine Fehlermeldung.

Politische Empfehlungen:

• Wenn Ihre Domain über E-Mail-Postfächer für Personen verfügt, deren Nutzer in Mailinglisten (NAR, MLS, Verbandslisten usw.) eingetragen sind, verwenden Sie „p=quarantine“ als Durchsetzungsrichtlinie.
• Wenn Ihre Domain ausschließlich für Transaktionen genutzt wird (SaaS, Zahlungen, Fintech, Marketing-E-Mails ohne Benutzerpostfächer): Verwenden Sie „p=reject“.

Fehlerbehebung bei der DMARC-Einrichtung: Häufige Probleme und Lösungen

Problem 1: „Kein DMARC-Eintrag gefunden“ bei der Überprüfung

Ursache: Die DNS-Propagierung ist noch nicht abgeschlossen, oder Sie haben den Hostnamen falsch eingegeben.

Wie man das beheben kann:

1. Warten Sie nach der Veröffentlichung 24 bis 72 Stunden ab
2. Vergewissern Sie sich, dass der Hostname genau _dmarc lautet (in manchen Tools nicht _dmarc.yourdomain.com – erkundigen Sie sich bei Ihrem jeweiligen Anbieter).
3. Nutzen Sie unseren DNS-Propagation-Checker, um den Propagationsstatus zu überprüfen
4. Probieren Sie unseren DMARC-Checker noch einmal aus

Problem 2: SPF und DKIM stimmen nicht überein

Ursache: Die Domain im „From:“-Header stimmt nicht mit der durch SPF oder DKIM authentifizierten Domain überein.

Beispiel für einen Fehler:

• Absender: Laut Header „[email protected]“
• Die SPF-authentifizierte Domain lautet mail.otherdomain.com
• Die DKIM-Signaturdomäne lautet newsletter.anotherdomain.com
• Ergebnis: Keine Übereinstimmung. DMARC-Fehler.

Wie man das beheben kann:

1. Beginnen Sie in Ihrem Datensatz mit einer entspannten Ausrichtung (adkim=r; aspf=r). Dadurch werden Übereinstimmungen mit Subdomains zugelassen.

2. Verwenden Sie unseren DKIM-Checker, um die Signaturdomäne jedes Absenders zu überprüfen

3. Nutzen Sie unseren SPF-Checker, um zu überprüfen, ob jeder Absender in der SPF-Liste aufgeführt ist

4. Bitten Sie den Anbieter, die Domain für jeden Sender zu konfigurieren, bei dem es zu Fehlern kommt. Beispiel:

• „Bitte aktivieren Sie die DKIM-Signatur für die Domain example.com (keine Subdomain).“
• „Bitte verwenden Sie example.com als Return-Path-/Envelope-From-Domäne.“

5. Sobald alle Absender die Prüfung mit gelockerter Ausrichtung bestanden haben, können Sie auf strenge Ausrichtung (adkim=s; aspf=s) umstellen, falls gewünscht.

Problem 3: Authentifizierung durch einen externen Absender fehlgeschlagen

Ursache: Eine ESP-, CRM- oder Marketing-Plattform versendet E-Mails über Ihre Domain, ist jedoch nicht in Ihrem SPF-Eintrag konfiguriert und/oder hat DKIM nicht aktiviert.

Wie man das beheben kann:

Bei SPF-Fehlern:

1. Entnehmen Sie der Dokumentation des Absenders dessen SPF-Eintrag (z. B. include:sendgrid.net)

2. Fügen Sie dies Ihrem SPF-Eintrag hinzu: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Testen Sie es mit unserem SPF-Checker

Bei DKIM-Fehlern:

1. Bitten Sie den Anbieter, benutzerdefiniertes DKIM für Ihre Domain zu aktivieren

2. Veröffentlichen Sie den von ihnen bereitgestellten öffentlichen DKIM-Schlüssel (in der Regel im Format: selector._domainkey.yourdomain.com)

3. Testen Sie es mit unserem DKIM-Checker

Problem 4: Mehrere SPF-Einträge oder Überschreitung der Obergrenze von 10 SPF-Abfragen

1. Mehr als ein SPF-Eintrag: Wenn zwei SPF-TXT-Einträge für dieselbe Domain vorhanden sind, wird die SPF-Validierung vollständig unterbrochen, und die Empfänger ignorieren beide Einträge.

So beheben Sie das Problem: Führen Sie Ihre SPF-Einträge zu einem einzigen zusammen, da pro Domain nur ein einziger SPF-TXT-Eintrag zulässig ist.

Beispiel:

• Alter Eintrag 1: v=spf1 include:sendgrid.net ~all
• Alter Eintrag 2: v=spf1 include:mailchimp.com ~all
• Neuer zusammengeführter Eintrag: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Mehr als 10 DNS-Abfragen: Jede „include“-Anweisung kann 1 bis 3 DNS-Abfragen erfordern. Wenn Sie die Zahl von 10 überschreiten, schlägt die SPF-Prüfung für einige Absender fehl.

So beheben Sie das Problem: Nutzen Sie unseren gehosteten SPF, um Ihren Eintrag dynamisch zu optimieren. Dadurch werden „include:“-Anweisungen durch explizite IP-Adressen ersetzt, wodurch die Anzahl der Lookups reduziert wird.

Beispiel:

• Vorher (mehr als 10 Abfragen): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Nach der Optimierung: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Problem 5: Legitime E-Mails landen nach der Quarantäne im Spam-Ordner

Warum das passiert: Sie sind zur Phase „p=Quarantäne“ übergegangen, bevor Sie überprüft haben, ob alle legitimen Absender die Authentifizierung bestehen.

Wie man das beheben kann:

1. Sofort wieder auf „p=none“ zurücksetzen
2. Sehen Sie sich Ihre Gesamtberichte an, um festzustellen, bei welchem Absender es zu Fehlern kommt
3. Die Authentifizierung korrigieren (SPF- oder DKIM-Abgleich)
4. Erneut auf p=Quarantäne zurücksetzen, aber mit t=y testen und 1–2 Wochen lang beobachten, bevor die Maßnahme durchgesetzt wird

Thema 6: Syntaxfehler in DMARC-Einträgen

Ursache: Tippfehler im Datensatz, fehlende Semikolons oder nicht unterstützte Tags

Wie man das beheben kann:

1. Überprüfen Sie die Gültigkeit mit unserem DMARC-Checker, da dieser Syntaxfehler anzeigt.
2. Nutzen Sie unseren DMARC-Generator, um den Eintrag neu zu erstellen, anstatt ihn manuell zu bearbeiten
3. Kopieren Sie den generierten Eintrag und fügen Sie ihn bei Ihrem DNS-Anbieter ein

Abschließende Worte

Die korrekte Konfiguration von DMARC ist mittlerweile unverzichtbar. Die dauerhafte Ablehnungspolitik von Gmail, die Anforderungen von Yahoo und Microsoft, die Empfehlungen des PCI DSS v4.0 sowie die CISA-Richtlinie BOD 18-01 machen DMARC zu einer unverzichtbaren Voraussetzung für die Einhaltung gesetzlicher Vorschriften.

Der sichere und zuverlässige Weg besteht darin, langsam vorzugehen, kontinuierlich zu überprüfen und verantwortungsbewusst durchzusetzen. Wenn Sie jedoch eine schnellere und einfachere DMARC-Verwaltung mit automatisierter Berichtsverarbeitung, Compliance-Überwachung und fortlaufendem Support wünschen, sollten Sie eine gehostete DMARC-Plattform wie PowerDMARC in Betracht ziehen, die sich um die Einrichtung, Skalierung und Durchsetzung kümmert, damit Sie sich ganz auf die Sicherheit konzentrieren können. Starten Sie noch heute Ihre kostenlose Testphase oder vereinbaren Sie eine Demo, um Ihre Domain jetzt zu sichern.

Häufig gestellte Fragen

Wie lange dauert die Einrichtung von DMARC?

Die Ersteinrichtung der DNS-Einträge dauert nur wenige Minuten. Die DNS-Propagierung kann bis zu 72 Stunden dauern (in der Regel 1–2 Stunden). Die vollständige Umsetzung (bis zum Erreichen von „p=reject“ mit hoher Sicherheit) dauert in der Regel 4–8 Wochen, abhängig von der Anzahl der Absenderquellen und davon, wie schnell Abgleichprobleme behoben werden.

Hat die DMARC-Konfiguration Auswirkungen auf die Zustellbarkeit von E-Mails?

Bei p=none hat dies keinerlei Auswirkungen auf die Zustellbarkeit, da im Überwachungsmodus keine Durchsetzungsmaßnahmen erfolgen. Bei p=quarantine oder p=reject sind nur nicht authentifizierte und nicht konforme E-Mails betroffen. Ordnungsgemäß authentifizierte E-Mails sind davon nicht betroffen und weisen oft sogar eine verbesserte Zustellbarkeit auf. DMARC kann langfristig die Zustellung in den Posteingang verbessern, indem es die Reputation der Domain bei den Posteingangsanbietern stärkt.

Wie richte ich DMARC für mehrere Domains ein?

Beachten Sie bei der Einrichtung von DMARC für mehrere Domains, dass jede Domain einen eigenen DMARC-TXT-Eintrag unter _dmarc.[domain] benötigt.

Beispiel:

• Domäne 1: _dmarc.example.com TXT-Eintrag
• Domäne 2: _dmarc.example.org TXT-Eintrag

Für Unternehmen, die zahlreiche Domains verwalten, ermöglicht eine gehostete DMARC-Plattform die Verwaltung aller Einträge über ein einziges Dashboard, was die Skalierung vereinfacht.

Was bedeutet DMARC-Abgleich?

Unter „Abgleich“ versteht man, dass die Domäne im „From:“-Header mit der durch SPF oder DKIM authentifizierten Domäne übereinstimmen muss. Bei einem lockeren Abgleich (Standardeinstellung: adkim=r; aspf=r) sind Übereinstimmungen auf Organisationsebene zulässig, während bei einem strengen Abgleich (adkim=s; aspf=s) exakte Übereinstimmungen erforderlich sind.

• Über
• Neueste Beiträge

Maitham Al Lawati

Cybersecurity-Experte, CEO bei PowerDMARC

Maitham ist ein Tech-Unternehmer, Cybersecurity-Experte, CEO und Gründer von PowerDMARC mit mehr als 15 Jahren Branchenerfahrung. Maitham hat einen Global MBA von der University of Manchester und verschiedene berufliche Zertifizierungen, darunter CISSP, CISM, CRISC und ISC2 CCSP.

Neueste Beiträge von Maitham Al Lawati (alle anzeigen)

• So richten Sie DMARC ein: Vollständige Schritt-für-Schritt-Anleitung zur Konfiguration (2026) – 20. Juni 2026
• So lesen Sie DMARC-Berichte: Ein umfassender Leitfaden zu RUA und RUF – 10. Juni 2026
• Was ist DMARC? Definition, Funktionsweise und Bedeutung – 28. April 2026