Ihre Domain wird für geschäftliche E-Mails genutzt, SPF und DKIM sind eingerichtet – trotzdem melden Empfänger Authentifizierungsfehler, Spamplatzierungen oder abgelehnte Nachrichten. Häufig liegt das nicht daran, dass SPF und DKIM grundsätzlich nicht funktionieren. Die Prüfungen können technisch bestehen, aber Domains betreffen, die nicht zur sichtbaren Absenderadresse passen.
DMARC steht für Domain-based Message Authentication, Reporting and Conformance und ist ein Verfahren, mit dem Domaininhaber festlegen können, wie empfangende Mailserver Nachrichten mit fehlgeschlagener DMARC-Prüfung einordnen sollen. Entscheidend ist das Alignment: Für einen DMARC-Pass muss mindestens eine erfolgreiche SPF- oder DKIM-Prüfung zugleich zu der Domain in der sichtbaren From-Adresse ausgerichtet sein.
DMARC ist daher nicht einfach noch ein DNS-Eintrag. Der unter _dmarc veröffentlichte Eintrag verbindet drei Funktionen: Er bezieht die sichtbare Absenderdomain in die Bewertung ein, veröffentlicht eine Behandlungspräferenz für fehlgeschlagene Nachrichten und kann Berichte über die Nutzung der Domain anfordern. DMARC signiert selbst keine E-Mail und garantiert weder eine bestimmte Empfängerreaktion noch die Zustellung in den Posteingang.
DMARC verbindet SPF, DKIM und die sichtbare Absenderdomain
Eine E-Mail enthält mehrere technische Identitäten. Für DMARC sind vor allem drei Domains relevant: die Domain der sichtbaren From-Adresse, die SPF-geprüfte Domain des SMTP-Umschlagabsenders und die Domain einer gültigen DKIM-Signatur. Diese Domains können identisch sein, müssen es technisch aber nicht sein. Genau diese Lücke zwischen erfolgreicher Einzelprüfung und sichtbarem Absender schließt DMARC.
SPF prüft den sendenden Server für die MAIL-FROM-Domain
SPF, das Sender Policy Framework, beantwortet vereinfacht die Frage: Darf dieser Server E-Mails für die beim SMTP-Transport verwendete Domain versenden? Diese technische Absenderidentität wird als MAIL FROM, Envelope From, Return-Path oder Umschlagabsender bezeichnet. Sie ist unter anderem für Unzustellbarkeitsmeldungen relevant und wird im E-Mail-Programm normalerweise nicht als Hauptabsender angezeigt.
Ein SPF-Pass bestätigt deshalb nicht automatisch die sichtbare Adresse. Ein Dienst könnte mit dem sichtbaren Absender rechnung@beispiel.de auftreten, technisch aber eine eigene MAIL-FROM-Domain verwenden, für die sein Versandserver ordnungsgemäß autorisiert ist. SPF besteht dann für die Dienstleisterdomain, ohne die Verwendung von beispiel.de in der sichtbaren From-Zeile zu bestätigen.
DKIM prüft Signatur und Signing-Domain
DKIM, DomainKeys Identified Mail, bezieht die im Parameter h= aufgeführten Kopfzeilen in eine kryptografische Signatur ein. Das Pflichtfeld bh= enthält zusätzlich einen Hash des kanonisierten Nachrichtenkörpers. Ohne das optionale und selten verwendete l=-Tag fließt der gesamte kanonisierte Nachrichtenkörper in diese Prüfung ein; l= kann die berücksichtigte Länge begrenzen. Der empfangende Server ruft den öffentlichen Schlüssel aus dem DNS ab und prüft damit Signatur und Body-Hash.
Eine erfolgreiche Prüfung zeigt, dass die von DKIM erfassten Bestandteile seit der Signatur nicht in einer für die Signatur relevanten Weise verändert wurden und dass die Signatur zur im Parameter d= genannten Domain gehört. Ein DKIM-Pass bestätigt jedoch weder eine konkrete Person noch die Vertrauenswürdigkeit des Inhalts. Vor allem muss die Signing-Domain nicht mit der sichtbaren From-Domain übereinstimmen. Ein Newsletteranbieter kann erfolgreich mit d=versanddienst.example signieren, während Leser newsletter@beispiel.de als Absender sehen. Die Signatur ist dann gültig, aber noch nicht für die sichtbare Domain ausgerichtet.
Alignment entscheidet über den DMARC-Pass
DMARC betrachtet die Domain im sichtbaren From-Feld und vergleicht sie mit den erfolgreich authentifizierten Domains. Ein DMARC-Pass entsteht, wenn mindestens einer der folgenden Wege funktioniert: SPF besteht und die MAIL-FROM-Domain ist ausgerichtet, oder DKIM besteht und die Signing-Domain ist ausgerichtet. SPF und DKIM müssen für einen einzelnen DMARC-Pass also nicht beide bestehen. Für Domains mit p=reject gilt zusätzlich: Nach RFC 9989 dürfen sie sich für den DMARC-Pass nicht allein auf SPF verlassen und müssen legitime Nachrichten gültig per DKIM signieren. In der Praxis sollte deshalb auch der DKIM-Weg Alignment liefern. Das erhöht zugleich die Robustheit, weil SPF beispielsweise bei Weiterleitungen scheitern kann.
Beim standardmäßig verwendeten relaxed Alignment dürfen unterschiedliche Subdomains zusammenpassen, wenn sie nach dem DMARC-Verfahren derselben organisatorischen Domain zugeordnet werden. So können beispiel.de und bounce.beispiel.de ausgerichtet sein. Strict Alignment verlangt dagegen die exakte Domainübereinstimmung. Eine vollständig fremde Domain wie versanddienst.example ist in beiden Fällen nicht zu beispiel.de ausgerichtet.
Ein typischer Fehler entsteht bei Newsletterdiensten: Sichtbar ist newsletter@beispiel.de, als MAIL FROM verwendet der Anbieter jedoch bounce@versanddienst.example, und seine DKIM-Signatur nennt ebenfalls d=versanddienst.example. SPF und DKIM können für den Anbieter jeweils „pass“ melden. DMARC scheitert trotzdem, weil kein bestandener Weg zu beispiel.de ausgerichtet ist.
Die Lösung ist eine korrekte Domainanbindung des Dienstes. Je nach Anbieter geschieht das über Custom DKIM mit einer eigenen ausgerichteten Signing-Domain oder über eine eigene, ausgerichtete Return-Path- beziehungsweise MAIL-FROM-Subdomain. Prüfen Sie das Ergebnis anschließend in den Nachrichtenkopfzeilen und DMARC-Berichten. Das bloße Eintragen weiterer Anbieterangaben in SPF ist weder immer notwendig noch automatisch die sauberste Lösung.
DMARC-Richtlinien und Berichte richtig einordnen
Der Domaininhaber veröffentlicht die DMARC-Angaben als TXT-Eintrag unter _dmarc.beispiel.de. Ein einfacher Monitoring-Eintrag kann beispielsweise v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de lauten. v=DMARC1 kennzeichnet die Version, p enthält die Richtlinie und rua nennt ein Ziel für zusammengefasste Berichte.
Was p=none, p=quarantine und p=reject aussagen
p=none: Der Domaininhaber äußert keine DMARC-spezifische Behandlungspräferenz für fehlgeschlagene Nachrichten. Die Einstellung dient zusammen mit Aggregatberichten der Beobachtung. Andere Spam-, Reputations- und Sicherheitsfilter des Empfängers bleiben uneingeschränkt aktiv.p=quarantine: Der Domaininhaber kennzeichnet nicht bestandene Nachrichten als verdächtig. Der Empfänger kann sie beispielsweise in den Spamordner verschieben, in eine Quarantäne stellen oder durch zusätzliche Prüfungen bewerten. Ein bestimmter Ablageort ist nicht garantiert.p=reject: Der Domaininhaber erklärt eine fehlgeschlagene Verwendung seiner Domain für nicht gültig. RFC 9989 untersagt Empfängern jedoch, allein wegen dieser veröffentlichten Richtlinie abzulehnen. Sie müssen weitere Erkenntnisse und Analysen in die Entscheidung einbeziehen; fehlen solche zusätzlichen Informationen, ist der DMARC-Fail so zu behandeln, als geltep=quarantine.
Die Richtlinie ist somit eine qualifizierte Präferenz des Domaininhabers, kein Fernsteuerungsbefehl für fremde Mailserver. In der Praxis reagieren Anbieter unterschiedlich. Gerade Weiterleitungen und Mailinglisten können legitime Nachrichten aus dem DMARC-Pass bringen, obwohl der ursprüngliche Versand korrekt war. Eine zu frühe Verschärfung kann deshalb echte Geschäftskommunikation beeinträchtigen.
Achten Sie bei Einrichtungsanleitungen auf deren Stand. RFC 9989 hat im Mai 2026 die früheren DMARC-Spezifikationen RFC 7489 und RFC 9091 abgelöst; die Aggregate- und Failure-Report-Formate sind nun in RFC 9990 beziehungsweise RFC 9991 beschrieben. Das ältere Tag pct ist historisch. Für Tests kennt RFC 9989 stattdessen t=y: Bei p=quarantine wird für fehlgeschlagene Nachrichten none, bei p=reject entsprechend quarantine angewendet; das Reporting bleibt aktiv. Verlassen Sie sich bei einer risikoreichen Umstellung trotzdem nicht allein auf t=y, denn ältere Implementierungen können das ihnen unbekannte Tag ignorieren.
Aggregate Reports zeigen Versandquellen und Alignment
Über rua angeforderte Aggregate Reports sind zusammengefasste Berichte im DMARC-Reporting-Format. Sie enthalten unter anderem beobachtete sendende IP-Adressen, Nachrichtenmengen, SPF- und DKIM-Ergebnisse, Alignment-Bewertungen, die veröffentlichte Richtlinie und die vom berichtenden System dokumentierte Behandlung. Damit erkennen Sie beispielsweise, ob neben Microsoft 365 auch eine Newsletterplattform, ein Ticketsystem oder ein unbekannter Server im Namen Ihrer Domain sendet.
Die Berichte sind eine wichtige, aber keine vollständige Verkehrserfassung. Nicht jeder Empfänger erstellt oder versendet sie. Fehlende Berichte beweisen daher weder eine fehlerfreie Konfiguration noch fehlenden Mailverkehr. Planen Sie außerdem eine automatisierte Aufbereitung ein: Ungefilterte Berichtsdaten sind für eine laufende Bewertung großer Versandmengen unhandlich.
Liegt das rua-Ziel außerhalb der organisatorischen Domain des veröffentlichenden DMARC-Eintrags, muss ein konformer Report-Generator prüfen, ob die externe Zieldomain den Empfang per DNS autorisiert hat. Fehlt diese Cross-Domain-Autorisierung, muss das externe Berichtsziel ignoriert werden. Prüfen Sie zusätzlich, ob das Ziel erreichbar ist und das erwartete Berichtsvolumen verarbeiten kann.
Failure Reports sind detaillierter und datenschutzsensibler
Nachrichtenbezogene Failure Reports werden über ruf angefordert und häufig noch als Forensic Reports bezeichnet. Sie können bei einzelnen Fehlern zusätzliche Header oder Nachrichtendaten enthalten. Aufgrund der möglichen personenbezogenen, vertraulichen oder missbrauchbaren Inhalte schränken viele Betreiber diese Berichte ein oder senden sie gar nicht. Für den regulären Einstieg sind Aggregatberichte über rua die geeignetere Grundlage. Vor dem Einsatz von ruf sollten Sie Datenschutz, Berechtigungen, Aufbewahrung und die Einbindung externer Dienstleister intern prüfen. Externe ruf-Ziele benötigen ebenfalls die vorgesehene DNS-Autorisierung.
Ein Berichtspostfach allein verbessert die Sicherheit nicht. Ordnen Sie jede relevante Quelle einem bekannten Geschäftsvorgang und einem Verantwortlichen zu. Erst wenn legitime, unbekannte und missbräuchliche Quellen zuverlässig unterschieden werden, liefern die Daten eine belastbare Grundlage für eine strengere Richtlinie.
DMARC ohne Zustellverluste einführen und Fehler systematisch finden
Eine sichere Einführung beginnt nicht mit p=reject, sondern mit der Frage, welche Systeme tatsächlich E-Mails unter Ihrer Domain versenden. Erfassen Sie nicht nur das zentrale Mailsystem. Newsletter, CRM, Ticketsysteme, Websiteformulare, Scanner, Rechnungssoftware, Bewerberportale und selten genutzte SaaS-Dienste werden besonders häufig übersehen.
Die folgende Matrix verbindet Einführung und Diagnose. Gehen Sie erst zum nächsten Schritt über, wenn die genannte Bedingung erfüllt ist. Eine starre Wartezeit allein genügt nicht: Seltene Monatsabrechnungen, saisonale Kampagnen oder nur im Störungsfall aktive Systeme müssen im Beobachtungszeitraum tatsächlich vorkommen. Betreiben Sie allgemeine Benutzerpostfächer, deren Nutzer Internet-Mailinglisten verwenden könnten, empfiehlt RFC 9989 vor p=reject mindestens einen Monat mit p=none und anschließend einen ebenso langen Zeitraum mit p=quarantine. Diese Mindestbeobachtung ersetzt keine vollständige Bestandsaufnahme.
| Phase oder Prüfschritt | Zu prüfende Beobachtung | Typischer Fehler | Praktische Folge | Bedingung für den nächsten Schritt |
|---|---|---|---|---|
| 1. Versandquellen inventarisieren | Erfassen Sie Microsoft 365 oder das andere Hauptmailsystem sowie Newsletter, CRM, Support, Website, Scanner, Rechnungs- und Personalsoftware. Dokumentieren Sie Zweck, Betreiber und verantwortliche Stelle. | Ein selten genutzter Dienst oder ein dezentral beschafftes SaaS-System fehlt. | Eine legitime Quelle taucht später als DMARC-Fehler auf und kann bei strenger Richtlinie schlechter zugestellt oder abgelehnt werden. | Jede bekannte Mailart ist einem konkreten sendenden System zugeordnet. |
| 2. Drei Domains je Quelle erfassen | Notieren Sie sichtbare From-Domain, MAIL-FROM-Domain und DKIM-Domain aus d=. Leiten Sie daraus ab, welcher erfolgreiche Weg Alignment liefern soll. | Es werden nur die Ergebnisse spf=pass und dkim=pass betrachtet, nicht die geprüften Domains. | SPF und DKIM erscheinen fehlerfrei, während DMARC wegen fehlenden Alignments scheitert. | Für jede Quelle ist mindestens ein geplanter, ausgerichteter Authentifizierungsweg benannt. |
| 3. SPF gezielt prüfen | Kontrollieren Sie, ob der tatsächliche Versandserver für die MAIL-FROM-Domain autorisiert ist und ob diese Domain zur sichtbaren From-Domain ausgerichtet sein soll. Berücksichtigen Sie außerdem das SPF-Limit: Während einer Auswertung dürfen höchstens zehn DNS-auslösende Mechanismen und Modifier wie include, a, mx, exists und redirect verarbeitet werden. | IP-Adressen und include-Mechanismen werden wahllos ergänzt, obwohl der Dienst SPF über eine fremde Domain abwickelt oder DKIM als Alignment-Weg vorsieht. | Der SPF-Eintrag wird komplexer. Wird das DNS-Limit überschritten, muss die SPF-Auswertung mit permerror enden; das Alignment-Problem ist damit weiterhin nicht gelöst. | SPF funktioniert für die vorgesehenen Quellen; unnötige Autorisierungen wurden vermieden und die Auswertung bleibt innerhalb der technischen Grenzen. |
| 4. DKIM je Versanddienst kontrollieren | Prüfen Sie gültige Signaturen und die Domain im d=-Parameter. Aktivieren Sie bei Fremdversendern nach Möglichkeit Custom DKIM mit einer eigenen ausgerichteten Domain. Für einen einzelnen DMARC-Pass kann ausgerichtetes SPF genügen; eine Domain mit p=reject darf sich für den DMARC-Pass jedoch nicht allein darauf verlassen. | DKIM fehlt, ist ungültig oder signiert ausschließlich mit einer unabhängigen Anbieterdomain. | Ausgerichtetes SPF kann DMARC zunächst bestehen lassen, doch Weiterleitungen machen diesen Weg weniger robust. Bei einer fremden Signing-Domain entsteht kein DKIM-Alignment. | Mindestens ein Weg besteht ausgerichtet. Vor p=reject sind legitime Nachrichten gültig per DKIM signiert, und der reguläre Versand verfügt über einen ausgerichteten DKIM-Weg, sodass der DMARC-Pass nicht allein von SPF abhängt. |
| 5. Monitoring mit p=none starten | Veröffentlichen Sie ein funktionsfähiges rua-Ziel und prüfen Sie, ob Berichte eintreffen, verarbeitet und bekannten Quellen zugeordnet werden. | Die rua-Adresse ist falsch, nicht erreichbar oder bei einem externen Ziel nicht per DNS autorisiert. Alternativ werden Berichte nur gesammelt. | Fehlerhafte und unbekannte Quellen bleiben unsichtbar; eine spätere Richtlinienentscheidung beruht auf Annahmen. | Berichte werden regelmäßig ausgewertet und relevante Absender lassen sich fachlich einordnen. |
| 6. Subdomains und ungenutzte Namen prüfen | Erfassen Sie aktive Versand- und Return-Path-Subdomains sowie geparkte und nicht existente Namen. Prüfen Sie eigene DMARC-Records sowie sp für bestehende und np für nicht existente Subdomains. Fehlt eine anwendbare Subdomain-Regel, greift die entsprechende übergeordnete Policy. SPF und DKIM müssen unabhängig davon für die tatsächlich verwendeten Domains eingerichtet werden. | Es wird angenommen, SPF werde von der Hauptdomain vererbt, jede Subdomain benötige zwingend denselben eigenen DMARC-Eintrag oder p, sp und np seien austauschbar. | Aktive Subdomains authentifizieren nicht wie erwartet; ungenutzte Namensräume erhalten möglicherweise eine andere Richtlinie als beabsichtigt. | Eigene Records, Policy-Vererbung sowie p, sp, np und die separaten SPF-/DKIM-Konfigurationen sind dokumentiert. |
| 7. Weiterleitungen und Mailinglisten testen | Prüfen Sie repräsentative Weiterleitungswege, Mailinglisten und Gateways. Beobachten Sie, ob SPF nach der Weiterleitung scheitert und ob DKIM die Verarbeitung unverändert übersteht. | SPF-Fehler werden durch immer weitere Absenderfreigaben behandelt oder ARC wird als automatischer DMARC-Pass verstanden. | Legitime indirekte Mailflüsse bleiben störanfällig. ARC kann dem Empfänger zusätzlichen Authentifizierungskontext liefern, setzt aber Vertrauen in den Vermittler voraus und repariert keine fehlerhafte Ausgangskonfiguration. | Kritische indirekte Flüsse wurden real getestet und ihr Restrisiko ist für die Organisation vertretbar. |
| 8. Quarantine erwägen | Vergleichen Sie Berichtszeiträume und suchen Sie nach legitimen Quellen mit DMARC-Fail, unerklärten Volumenspitzen oder nur sporadisch auftretenden Absendern. | Die Richtlinie wird verschärft, obwohl noch ein Newsletterdienst, eine Subdomain oder ein Altsystem ungeklärt ist. | Empfänger können legitime Nachrichten als verdächtig einstufen, in Spam oder Quarantäne verschieben oder anderweitig filtern. | Alle bekannten legitimen Quellen bestehen ausgerichtet; verbleibende Fehler sind verstanden und bewusst akzeptiert. |
| 9. Reject risikobasiert entscheiden | Bewerten Sie Geschäftskritikalität, Benutzerkommunikation, Mailinglisten, Weiterleitungen und die Fähigkeit, Zustellfehler schnell zu erkennen. Prüfen Sie zusätzlich, dass legitimer Versand nicht allein über SPF einen DMARC-Pass erreicht und DKIM gültig sowie für die regulären Versandwege ausgerichtet arbeitet. Bei allgemeinen Benutzerpostfächern sollten Sie die besonderen Mailinglistenrisiken von p=reject ausdrücklich einbeziehen. | p=reject wird als obligatorisches Endziel betrachtet, ohne belastbare Beobachtung aktiviert oder technisch nur durch ausgerichtetes SPF abgesichert. | Legitime indirekte Nachrichten können schlechter zugestellt oder abgelehnt werden. Für Domains mit Nutzern, die an Internet-Mailinglisten posten könnten, warnt RFC 9989 ausdrücklich vor Interoperabilitätsproblemen. | Alle legitimen Versandwege sind nachvollziehbar, DKIM schützt den DMARC-Pass zusätzlich zu SPF und die strengere Richtlinie passt zu den realen Mailflüssen sowie zur Risikotoleranz. Andernfalls bleibt eine weniger strenge Policy sachgerechter. |
| 10. Bei Zustellverlusten zurückfallen | Identifizieren Sie die betroffene Quelle anhand von Headern, Fehlermeldungen und Berichten. Korrigieren Sie MAIL FROM, DKIM oder die Dienstanbindung. | Breite Allow-Listen überdecken die Ursache oder die Authentifizierung wird ohne Diagnose pauschal erweitert. | Der unmittelbare Fehler verschwindet möglicherweise, während Spoofing-Risiko und technische Schulden wachsen. | Die Quelle authentifiziert wieder nachvollziehbar. Falls erforderlich, wird die DMARC-Richtlinie vorübergehend weniger streng gesetzt, bis die Korrektur verifiziert ist. |
Microsoft 365 plus Newsletterdienst: So kann ein Alignment-Fehler zum Zustellproblem werden
Angenommen, ein Unternehmen versendet normale Geschäftspost über Microsoft 365. Die sichtbare Domain lautet beispiel.de, SPF ist passend eingerichtet und Microsoft 365 signiert mit einer ausgerichteten DKIM-Domain. Diese Nachrichten können DMARC damit regulär bestehen. Zusätzlich verschickt die Marketingabteilung Kampagnen über einen Newsletterdienst, der bei der ursprünglichen DMARC-Planung vergessen wurde.
Der Newsletter zeigt ebenfalls newsletter@beispiel.de an, verwendet technisch aber eine MAIL-FROM-Domain und eine DKIM-Signing-Domain des Anbieters. Beide Einzelprüfungen können bestehen. Weil jedoch keine dieser Domains zu beispiel.de ausgerichtet ist, lautet das DMARC-Ergebnis „fail“. Unter p=none wird dieses Problem in Aggregatberichten sichtbar, ohne dass der Domaininhaber über DMARC eine strengere Behandlung anfordert.
Wird die Domain vorschnell auf p=quarantine oder p=reject gesetzt, können Empfänger die legitimen Kampagnen als verdächtig behandeln oder ablehnen. Microsoft-365-Nachrichten funktionieren weiterhin, weshalb der Fehler zunächst wie ein Problem einzelner Empfänger oder des Newsletteranbieters wirkt. Tatsächlich hat die strengere Richtlinie einen bereits vorhandenen, aber zuvor nicht ausreichend ausgewerteten Alignment-Fehler praktisch relevant gemacht.
Korrigieren Sie zuerst die Domainanbindung des Newsletterdienstes. Je nach Plattform kommt eine ausgerichtete DKIM-Signatur unter einer eigenen Domain, eine ausgerichtete Return-Path-Subdomain oder beides infrage. Prüfen Sie danach reale Testnachrichten und die folgenden Berichte. Erst wenn der Dienst regelmäßig über einen ausgerichteten Authentifizierungsweg besteht, sollten Sie eine erneute Verschärfung erwägen. Vor p=reject darf der reguläre DMARC-Pass außerdem nicht allein von SPF abhängen; sorgen Sie deshalb für gültiges, ausgerichtetes DKIM.
Setzen Sie p=reject nicht allein deshalb, weil ein Prüfwerkzeug einen syntaktisch gültigen DMARC-Eintrag meldet. Entscheidend ist das Verhalten aller realen Versandquellen. Betreiben Sie allgemeine Benutzerpostfächer, deren Nutzer an Internet-Mailinglisten posten könnten, empfiehlt RFC 9989 ausdrücklich, p=reject nicht zu veröffentlichen. Auch bei technisch sauberer Authentifizierung können die realen Mailflüsse daher für eine weniger strenge Richtlinie sprechen.
Grenzen von DMARC und Antworten auf häufige Fragen
DMARC erschwert vor allem das direkte Spoofing der geschützten sichtbaren Domain. Es verhindert nicht, dass Angreifer ähnlich geschriebene Domains registrieren, einen vertrauenswürdigen Anzeigenamen verwenden, ein echtes Benutzerkonto übernehmen oder schädliche Inhalte über eine korrekt authentifizierte Domain versenden. DMARC ist Domainauthentifizierung, kein Identitätsnachweis für Personen und kein Inhaltsfilter.
Was bedeutet DMARC?
DMARC bedeutet Domain-based Message Authentication, Reporting and Conformance. Das Verfahren prüft, ob mindestens eine erfolgreiche SPF- oder DKIM-Authentifizierung zur sichtbaren Absenderdomain ausgerichtet ist. Zusätzlich kann der Domaininhaber eine Richtlinie veröffentlichen und Berichte über die Domainnutzung anfordern.
Ist DMARC dasselbe wie SPF?
Nein. SPF autorisiert sendende Server für die technische MAIL-FROM-Domain. DMARC bezieht dagegen die sichtbare From-Domain ein und verlangt Alignment mit einer erfolgreich geprüften SPF- oder DKIM-Domain. Ein SPF-Pass allein kann deshalb zusammen mit einem DMARC-Fail auftreten.
Was ist DMARC-Alignment?
Alignment bezeichnet die passende Beziehung zwischen der sichtbaren From-Domain und der authentifizierten Domain. Beim SPF-Weg wird sie mit der MAIL-FROM-Domain verglichen, beim DKIM-Weg mit der Domain im d=-Parameter. Relaxed Alignment erlaubt unterschiedliche Domains, wenn sie nach der DMARC-Ermittlung derselben organisatorischen Domain angehören; strict Alignment verlangt exakte Gleichheit. RFC 9989 bestimmt diese organisatorische Domain über einen DNS Tree Walk und nicht mehr über das frühere Public-Suffix-List-Verfahren.
Was bedeutet p=none?
p=none bedeutet, dass der Domaininhaber keine DMARC-spezifische Behandlungspräferenz für fehlgeschlagene Nachrichten ausdrückt. Die Einstellung eignet sich zusammen mit einem funktionierenden rua-Ziel zur Beobachtung. DMARC ist damit nicht ausgeschaltet, und andere Filter des Empfängers können Nachrichten weiterhin blockieren oder als Spam einstufen.
Was bedeutet p=reject?
p=reject drückt aus, dass der Domaininhaber eine fehlgeschlagene Verwendung seiner Domain für nicht gültig hält. Eine SMTP-Ablehnung kann daraus folgen, sie ist aber keine automatisch vorgeschriebene Empfängeraktion. RFC 9989 verlangt, dass Empfänger zusätzliche Erkenntnisse und Analysen berücksichtigen; ohne solche Informationen ist der DMARC-Fail wie bei p=quarantine zu behandeln. Die veröffentlichende Domain darf sich für den DMARC-Pass außerdem nicht allein auf SPF verlassen und muss legitime Nachrichten gültig per DKIM signieren. Nutzen Ihre Benutzer Internet-Mailinglisten, sollten Sie die ausdrücklich beschriebenen Interoperabilitätsrisiken vor einer solchen Richtlinie besonders sorgfältig prüfen.
Warum braucht man DMARC-Berichte?
Berichte zeigen, welche Server im Namen Ihrer Domain senden und ob SPF, DKIM sowie Alignment funktionieren. Sie helfen, vergessene legitime Dienste, Fehlkonfigurationen und mögliche Spoofing-Quellen zu erkennen. Ohne Auswertung lässt sich nicht zuverlässig beurteilen, ob eine strengere Richtlinie echte Nachrichten gefährdet.
Kann DMARC Phishing verhindern?
DMARC kann direktes Spoofing der geschützten From-Domain deutlich erschweren und dadurch einen wichtigen Phishingweg eindämmen. Es verhindert jedoch keine Lookalike-Domains, Display-Name-Täuschungen, kompromittierten Konten oder betrügerische Inhalte von anderen Domains. Wirksamer Schutz erfordert zusätzlich Kontosicherheit, Inhaltsfilter, Reputationsbewertung und geschulte Empfänger.
Warum landen E-Mails trotz DMARC im Spam?
Ein DMARC-Pass bestätigt nur die autorisierte Verwendung der sichtbaren Domain. Empfänger bewerten zusätzlich Absender- und IP-Reputation, Inhalte, Links, Versandmengen, plötzliche Musteränderungen, Beschwerden, Empfängerinteraktionen und lokale Sicherheitsrichtlinien. DMARC ist daher keine Zustellbarkeitsgarantie und kein Qualitätsurteil über die Nachricht.
Verschärfen Sie eine DMARC-Richtlinie erst, wenn alle legitimen Versandquellen über einen nachvollziehbaren ausgerichteten Authentifizierungsweg verfügen und in den Berichten eingeordnet sind. Vor p=reject darf der DMARC-Pass regulärer legitimer Nachrichten nicht allein von SPF abhängen; sorgen Sie für gültiges und ausgerichtetes DKIM. Die passende Richtlinie richtet sich nach Ihren tatsächlichen Mailflüssen, indirekten Versandwegen und Ihrer Risikotoleranz – nicht danach, möglichst schnell p=reject in einem DNS-Prüfwerkzeug anzuzeigen.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten