DMARC-Fragen,
beantwortet

DMARC (Domain-based Message Authentication, Reporting & Conformance) ist ein E-Mail-Authentifizierungsprotokoll, das empfangenden Mailservern mitteilt, was zu tun ist, wenn SPF- oder DKIM-Prüfungen fehlschlagen. Es verhindert, dass Angreifer E-Mails senden, die scheinbar von Ihrer Domain stammen, und schützt so Ihre Marke und Empfänger vor Phishing und Spoofing. DMARC ist in RFC 7489 definiert.

Ja. Wenn Ihre Domain E-Mails versendet — oder auch wenn nicht — brauchen Sie DMARC. Ohne DMARC kann jeder E-Mails versenden, die Ihre Domain imitieren. Google und Yahoo verlangen inzwischen mindestens p=none für Domains, die 5.000+ Nachrichten pro Tag versenden. PCI DSS v4.0 erfordert DMARC für kundenorientierte Domains. Nicht-sendende Domains sollten p=reject veröffentlichen, um Nachahmung zu verhindern.

Beginnen Sie damit, SPF und DKIM für Ihre Domain zu konfigurieren. Veröffentlichen Sie dann einen DNS-TXT-Eintrag unter _dmarc.ihredomain.com mit p=none und einer rua=-Berichtsadresse. Überwachen Sie aggregierte Berichte mindestens 90 Tage, beheben Sie die Authentifizierung für alle legitimen Absender und gehen Sie dann schrittweise zu p=quarantine und schließlich p=reject über. Verwenden Sie unseren DMARC-Checker zur Validierung Ihres Eintrags.

Die Veröffentlichung eines DMARC-Eintrags mit p=none dauert Minuten. Die vollständige Durchsetzung mit p=reject dauert typischerweise 9 bis 18 Monate. Jede Phase (none, quarantine, reject) erfordert mindestens 90 Tage Überwachung, um alle legitimen Sendequellen zu identifizieren und ihre Authentifizierung zu korrigieren. Organisationen mit weniger Drittanbieter-Absendern können schneller voranschreiten.

Ein DMARC-Eintrag ist ein DNS-TXT-Eintrag, veröffentlicht unter _dmarc.ihredomain.com. Ein typischer Eintrag sieht so aus: v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; ruf=mailto:forensic@beispiel.de; adkim=r; aspf=r. Die v=- und p=-Tags sind erforderlich; alle anderen sind optional, aber empfohlen. Siehe unsere Was ist DMARC-Seite für eine vollständige Aufschlüsselung jedes Tags.

SPF überprüft, ob der sendende Server durch den DNS-Eintrag der Domain autorisiert ist — es prüft den Envelope-Absender (Return-Path). DKIM fügt eine kryptografische Signatur hinzu, um zu beweisen, dass die Nachricht während der Übertragung nicht verändert wurde. DMARC verbindet beide: Es erfordert, dass entweder SPF oder DKIM besteht UND mit der sichtbaren From-Header-Domain übereinstimmt, und teilt dann Empfängern mit, was bei fehlgeschlagener Authentifizierung zu tun ist. Verwenden Sie unseren SPF-Checker und DKIM-Lookup, um Ihre Einträge zu testen.

Nein. Eine Domain darf genau einen DMARC-TXT-Eintrag unter _dmarc.domain.com haben. Mehrere DMARC-Einträge verursachen einen PermError und Empfänger ignorieren alle. Wenn Sie Berichte an mehrere Adressen senden müssen, listen Sie sie kommagetrennt im rua=-Tag auf: rua=mailto:dmarc@beispiel.de,mailto:berichte@beispiel.de.

DMARC-Ausrichtung bedeutet, dass die Domain im sichtbaren From-Header mit der Domain übereinstimmen muss, die SPF oder DKIM bestanden hat. Relaxed Alignment (Standard) erlaubt Subdomain-Übereinstimmung — mail.beispiel.de richtet sich an beispiel.de aus. Strict Alignment erfordert eine exakte Domain-Übereinstimmung. Die Ausrichtung verhindert, dass Angreifer SPF mit ihrer eigenen Domain bestehen und gleichzeitig Ihre im From-Header fälschen.

Die p=none-Richtlinie weist empfangende Server an, keine Durchsetzungsmaßnahme bei Nachrichten zu ergreifen, die DMARC nicht bestehen. Nachrichten werden unabhängig von den Authentifizierungsergebnissen normal zugestellt. Der Zweck ist Überwachung: Empfänger senden weiterhin aggregierte Berichte, die dem Domain-Inhaber Einblick in alle Sendequellen geben. Beginnen Sie immer mit p=none, bevor Sie zur Durchsetzung übergehen.

Die p=quarantine-Richtlinie weist empfangende Server an, fehlgeschlagene Nachrichten in den Spam- oder Junk-Ordner zu verschieben. Die Nachricht existiert weiterhin — Empfänger können sie finden — aber sie ist als verdächtig markiert. Dies ist der zwischenzeitliche Durchsetzungsschritt zwischen p=none (Überwachung) und p=reject (vollständige Blockierung). Siehe unseren DMARC-Richtlinien-Leitfaden für den vollständigen Übergang.

Die p=reject-Richtlinie weist empfangende Server an, fehlgeschlagene Nachrichten auf SMTP-Ebene abzulehnen. Der Empfänger sieht die Nachricht nie und der sendende Server erhält einen Bounce. Dies ist der stärkste DMARC-Schutz und das ultimative Ziel für jede Domain. Das Erreichen von p=reject erfordert gründliche Überwachung in den Phasen p=none und p=quarantine.

Das pct=-Tag steuert, welcher Prozentsatz der fehlgeschlagenen Nachrichten die Durchsetzungsmaßnahme erhält. Bei pct=25 werden nur 25% der fehlgeschlagenen Nachrichten in Quarantäne gestellt oder abgelehnt — der Rest wird wie p=none behandelt. Dies ermöglicht eine schrittweise Einführung der Durchsetzung. Beginnen Sie mit pct=10, erhöhen Sie auf 25, 50, dann 100 über mehrere Wochen. Wenn pct= fehlt, ist der Standard 100.

Ein aggregierter Bericht (RUA) ist eine XML-Datei, die täglich von empfangenden Mailservern gesendet wird und die Authentifizierungsergebnisse für alle Nachrichten zusammenfasst, die vorgeben, von Ihrer Domain zu stammen. Er zeigt, welche IP-Adressen E-Mails gesendet haben, ob SPF und DKIM bestanden haben und welche Richtlinie angewendet wurde. Aggregierte Berichte sind die Grundlage der DMARC-Überwachung — sie liefern die Daten, die für Durchsetzungsentscheidungen benötigt werden. DMARC Report wandelt diese XML-Dateien in visuelle Dashboards um.

Ein forensischer Bericht (RUF) liefert Fehlerdetails pro Nachricht — die spezifische E-Mail, die die Authentifizierung nicht bestanden hat, die Absender-IP, die From/Return-Path-Abweichung und welcher Mechanismus fehlgeschlagen ist. Forensische Berichte sind nützlich zur Untersuchung aktiver Spoofing-Versuche, werden aber von Empfängern seltener unterstützt als aggregierte Berichte. Einige Empfänger senden aus Datenschutzgründen gar keine RUF-Berichte.

Rohe aggregierte DMARC-Berichte sind XML-Dateien, die schwer manuell zu lesen sind. Verwenden Sie einen DMARC-Berichtsanalyzer wie DMARC Report, um XML in visuelle Dashboards umzuwandeln, die den Authentifizierungsstatus der Absender, Ausrichtungsergebnisse und Richtlinienaktionen zeigen. Das Tool klassifiziert Absender automatisch nach Anbieter (Google Workspace, Microsoft 365, SendGrid usw.) und hebt Fehler hervor, die Aufmerksamkeit erfordern.

Häufige Gründe: Ihr DMARC-Eintrag enthält kein rua=-Tag, die rua=-E-Mail-Adresse hat einen Tippfehler, oder es wurde nicht genug E-Mail-Volumen gesendet, um Berichte auszulösen (Empfänger bündeln Berichte typischerweise täglich). Wenn rua= auf eine andere Domain als die authentifizierte zeigt, benötigen Sie einen externen Verifizierungs-DNS-Eintrag. Warten Sie 24-72 Stunden nach Veröffentlichung Ihres DMARC-Eintrags, bis Berichte eintreffen. Verwenden Sie unseren DMARC-Checker, um Ihre Eintrags-Syntax zu validieren.

Die meisten Empfänger senden aggregierte Berichte einmal alle 24 Stunden, typischerweise um Mitternacht UTC. Einige große Empfänger wie Google und Microsoft senden möglicherweise mehrere Berichte pro Tag. Das Volumen der Berichte, die Sie erhalten, hängt davon ab, wie viele verschiedene Empfänger E-Mails von Ihrer Domain verarbeiten. Beliebte Domains erhalten möglicherweise Hunderte von Berichten täglich von Dutzenden von Empfängern.

Der Weg von p=none zu p=reject dauert typischerweise 9 bis 18 Monate. Jede Phase erfordert mindestens 90 Tage: p=none zur Überwachung und Absenderidentifikation, p=quarantine zur zwischenzeitlichen Durchsetzung und p=reject zum vollständigen Schutz. Organisationen mit weniger Drittanbieter-Absendern und einfacherer E-Mail-Infrastruktur können schneller voranschreiten, aber überstürzte Durchsetzung führt dazu, dass legitime E-Mails blockiert werden.

Wenn ein legitimer Absender DMARC bei p=quarantine nicht besteht, landet seine E-Mail im Spam. Bei p=reject wird sie vollständig blockiert. Zur Behebung: Prüfen Sie aggregierte Berichte, um den fehlgeschlagenen Absender zu identifizieren, konfigurieren Sie seinen SPF-Include oder seine DKIM-Signierung und überprüfen Sie, ob die Ausrichtung besteht. Die Verwendung des pct=-Tags zur schrittweisen Einführung der Durchsetzung hilft, diese Probleme zu erkennen, bevor sie alle E-Mails betreffen.

Quarantine bietet bedeutenden Schutz — gefälschte Nachrichten verlassen den Posteingang. Jedoch ist p=reject das empfohlene Ziel, da es die Zustellung vollständig verhindert. Einige Compliance-Rahmenwerke (PCI DSS v4.0, CISA BOD 18-01 für Bundesbehörden) erfordern ausdrücklich p=reject. Außerdem ist p=reject erforderlich, um sich für BIMI zu qualifizieren, das Ihr Markenlogo in unterstützenden E-Mail-Clients anzeigt.

Ja. Traditionelle E-Mail-Weiterleitung kann die SPF-Ausrichtung brechen, weil die IP des Weiterleitungsservers nicht im SPF-Eintrag der ursprünglichen Domain steht. DKIM überlebt typischerweise die Weiterleitung, weil die Signatur an die Nachricht selbst angehängt ist. Deshalb ist DKIM-Ausrichtung besonders wichtig für Domains, deren Empfänger E-Mails weiterleiten. ARC (Authenticated Received Chain) ist ein neueres Protokoll, das dieses Problem adressiert, aber die Verbreitung wächst noch.

DMARC wird von einer zunehmenden Anzahl von Standards und Organisationen verlangt. Google und Yahoo erfordern mindestens p=none für Massenversender (5.000+ Nachrichten/Tag). PCI DSS v4.0 erfordert DMARC für Domains in der Kundenkommunikation (wirksam seit März 2025). CISA BOD 18-01 schreibt p=reject für US-Bundesbehörden vor. Viele Cyberversicherungen und Beschaffungsprozesse erfordern inzwischen DMARC-Durchsetzung.

Seit Februar 2024 verlangen Google und Yahoo von allen Massenversendern (5.000+ Nachrichten/Tag an Gmail/Yahoo-Nutzer) eine DMARC-Richtlinie von mindestens p=none mit einer gültigen rua=-Adresse. Zusätzlich müssen Absender korrekt konfigurierte SPF- und DKIM-Einträge haben, Ein-Klick-Abmeldungs-Header in Marketing-E-Mails einfügen und eine Spam-Beschwerderate unter 0,3% halten. Nicht-konforme Absender erleben Zustellungsdrosselung und Ablehnungen.

Ja. PCI DSS v4.0 (wirksam seit März 2025) verlangt von Organisationen, die Karteninhaberdaten verarbeiten, DMARC auf Domains zu implementieren, die in der Kundenkommunikation verwendet werden. Konkret besagt Anforderung 5.4.1, dass Anti-Phishing-Mechanismen domainbasierte Authentifizierung (DMARC, SPF, DKIM) einschließen müssen. Die meisten PCI-Prüfer erwarten p=reject oder p=quarantine für die Compliance.

Binding Operational Directive 18-01, herausgegeben von der Cybersecurity and Infrastructure Security Agency (CISA), verpflichtet alle US-Bundesbehörden der Exekutive zur Implementierung von DMARC mit p=reject. Diese Richtlinie hat die DMARC-Einführung im Regierungssektor erheblich gesteigert und wird oft als Best-Practice-Benchmark von anderen Organisationen und Branchen zitiert.

DMARC unterstützt die HIPAA-Compliance, indem es E-Mail-Spoofing von Gesundheitsdomains verhindert und so das Risiko von Phishing-Angriffen reduziert, die zur Offenlegung geschützter Gesundheitsinformationen (PHI) führen könnten. Während HIPAA DMARC nicht ausdrücklich benennt, erfordert die Security Rule Schutzmaßnahmen für elektronische PHI, und E-Mail-Authentifizierung gilt als angemessene Maßnahme. Beachten Sie, dass forensische Berichte (RUF) Nachrichteninhalte enthalten können, sodass Gesundheitsorganisationen nur aggregierte Berichte (RUA) verwenden oder sicherstellen sollten, dass forensische Berichte HIPAA-konform gehandhabt werden.