E-Mail, E-mail Best Practices, Entwickler, Produkt
Ein DMARC Fail bedeutet, dass eine empfangende Mailplattform Ihre E-Mail als nicht DMARC-konform bewertet hat. Praktisch heißt das: Die E-Mail hat die DMARC-Prüfung nicht bestanden und kann je nach Einstellung des Empfängers oder Ihrer eigenen DMARC-Policy im Spam landen, in Quarantäne verschoben oder abgewiesen werden. Das wirkt oft plötzlich, ist aber fast immer technisch erklärbar und lösbar, wenn Sie systematisch vorgehen.
DMARC steht für Domain-Based Message Authentication, Reporting & Conformance. Auf Deutsch lesen Sie oft Domänenbasierte Nachrichtenauthentifizierung. Das Verfahren kombiniert zwei etablierte Authentifizierungsmethoden, Sender Policy Framework (SPF) und Domainkeys Identified Mail (DKIM), mit einer Richtlinie, die festlegt, wie Empfänger mit nicht authentifizierten E-Mails umgehen sollen. Zusätzlich liefert DMARC Ihnen Reports, damit Sie sehen, wer in Ihrem Namen versendet und ob die Authentifizierung funktioniert.
„DMARC fail“ heißt: DMARC konnte keine gültige Übereinstimmung zwischen der sichtbaren Absenderdomain und der Authentifizierung nach SPF oder DKIM feststellen. DMARC ist keine dritte, unabhängige Prüfung neben SPF und DKIM, sondern eine Regel, die bewertet, ob SPF oder DKIM nicht nur „bestanden“ haben, sondern auch zur sichtbaren Absenderdomain passen.
Bei „fail“ hat entweder SPF oder DKIM nicht bestanden oder die sogenannte Ausrichtung zur Absenderdomain fehlt. Diese Ausrichtung nennen Fachtexte „Alignment“. Sie ist der Kern von DMARC. DMARC gilt als bestanden, wenn mindestens eine dieser Bedingungen erfüllt ist:
Der entscheidende Zusatz lautet „ausgerichtet“. Eine E-Mail kann technisch ein SPF „pass“ haben und trotzdem DMARC failen, wenn SPF auf eine andere Domain prüft als die Domain, die der Empfänger im Absender sieht.
DMARC fail ist ein Ergebnis der Gesamtbewertung, während SPF fail und DKIM fail Ergebnisse einzelner Prüfungen sind.
Das ist wichtig, weil Sie sonst an der falschen Stelle suchen. SPF fail bedeutet: Die sendende IP-Adresse ist für die Domain, die SPF prüft, nicht autorisiert oder die Prüfung scheitert aus technischen Gründen. DKIM fail bedeutet: Die Signatur fehlt, ist kaputt oder kann nicht verifiziert werden. DMARC fail bedeutet: SPF und DKIM liefern in Summe keine gültige, zur sichtbaren Absenderdomain passende Grundlage für DMARC.
„Softfail“ ist streng genommen ein SPF-Begriff und nicht das eigentliche DMARC-Urteil. Viele Nutzer lesen „softfail“ in Reports oder Headern und denken, DMARC sei halb bestanden. Das ist nicht der Fall. Ein SPF-Softfail bedeutet: Die SPF-Regel sagt „eigentlich nicht erlaubt, aber nicht hart ablehnen“. DMARC bewertet dann zusätzlich, ob eine alternative DKIM-Authentifizierung aligned ist. Wenn DKIM aligned besteht, kann DMARC trotz SPF-Softfail bestehen. Wenn nicht, kann DMARC failen.
DMARC legt fest, wie Empfänger mit E-Mails umgehen sollen, die sich nicht als legitime Absender Ihrer Domain ausweisen können. Außerdem sorgt DMARC dafür, dass Sie Berichte bekommen und sehen, wer in Ihrem Namen versendet. DMARC ist damit Schutzschild und Diagnosewerkzeug zugleich.
Die Grundlage ist immer ein DMARC Record. Technisch ist das ein DNS TXT Record in Ihrem DNS, typischerweise unter _dmarc.ihre-domain.tld. Dieser Eintrag sagt Empfängern, wie sie DMARC prüfen und welche Policy sie anwenden sollen. Ein minimaler, gültiger DMARC-Einstieg sieht typischerweise so aus:
txt
Copyv=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de
Dieses Beispiel zeigt das Prinzip, nicht Ihre konkrete Ideal-Konfiguration. Wichtig ist, dass der Record technisch valide ist und dass die Report-Adresse funktioniert.
SPF prüft, ob ein Server berechtigt ist, für eine Domain E-Mails zu versenden. SPF wird über einen DNS-Eintrag gepflegt und bezieht sich auf den technischen Absender, also meist den envelope sender beziehungsweise die Mail From-Adresse. Dieser technische Absender taucht oft als Return-Path auf und ist nicht identisch mit dem sichtbaren Absender, den der Empfänger im „Von“-Feld sieht.
Merken Sie sich für die Praxis: SPF ist stark, wenn die Mail direkt zugestellt wird. Sobald Weiterleitungen ins Spiel kommen, wird SPF anfälliger, weil dann ein anderer Server die E-Mail weiterleitet und die ursprüngliche Sende-IP nicht mehr die „liefernde“ IP ist.
DKIM signiert E-Mails kryptografisch, damit Empfänger die Echtheit und Unverändertheit prüfen können. DKIM nutzt dazu Schlüssel, die Sie in Ihrem DNS hinterlegen, und der sendende Server signiert jede E-Mail mit dem passenden privaten Schlüssel. Viele Einsteiger stolpern über die Begriffswelt. Entscheidend ist: DKIM funktioniert wie ein Siegel. Der Empfänger prüft dieses Siegel über DNS. Technisch liegen dort öffentliche Schlüssel, oft auf Basis von RSA keys. Wenn ein Gateway oder ein fehlerhaftes System Teile der E-Mail verändert, kann die Signatur brechen und DKIM failen.
Identifier Alignment bedeutet: Die Domain, die der Empfänger im Absender sieht, muss zur Domain passen, die SPF oder DKIM absichert. Genau hier entsteht der Großteil aller DMARC-fail-Fälle.
Damit Sie das Bild klar vor Augen haben, müssen Sie zwei Stellen unterscheiden:
DMARC verlangt, dass mindestens eine Authentifizierung zu der Domain aus dem header from passt. Wenn SPF nur zur Domain des envelope sender passt, aber diese Domain nicht mit dem header from übereinstimmt, kann DMARC scheitern. Bei DKIM muss die Signaturdomain zum header from passen.
Wenn Sie zum Beispiel im Absender „@ihre-domain.de“ zeigen, aber Ihr Versandtool technisch über eine andere Domain signiert oder eine andere Mail From-Adresse nutzt, kann DMARC failen, obwohl einzelne Prüfungen „pass“ wirken. Ein häufiger Auslöser ist ein Drittanbieter, der zwar korrekt versendet, aber ohne korrekt eingerichtete Custom Domain. Das gilt für Newsletter, Ticketsysteme, CRM-Mails und ähnliche Versandquellen.
DMARC ist nicht gesetzlich verpflichtend, aber in der Praxis für professionelle Zustellung und Schutz vor Spoofing sehr wichtig. Ohne DMARC können Angreifer Ihre Domain leichter missbrauchen, und Sie verlieren Transparenz darüber, wer in Ihrem Namen E-Mails verschickt.
Dazu kommt ein praktischer Punkt: Große Empfänger bewerten Absender zunehmend streng. Wenn Ihre Authentifizierung und Ihre Policy nicht sauber sind, leidet die Zustellung. Am Ende betrifft das nicht nur Sicherheit, sondern auch Geschäft: Rechnungen kommen nicht an, Angebotsmails landen im Spam, Support-Tickets gehen verloren. Damit sinkt indirekt auch die Reputation des Absenders, weil Empfänger Ihre Domain als unzuverlässig einstufen können.
DMARC fail entsteht fast immer durch fehlende Authentifizierung, fehlende Ausrichtung oder durch unbekannte Versandquellen. Die gute Nachricht: Sie können jeden dieser Punkte messbar prüfen und gezielt korrigieren.
Wenn SPF oder DKIM nicht eingerichtet ist, fehlt DMARC die Grundlage, um Ihre Absenderdomain zu bestätigen. In der Praxis sehen Sie dann häufig entweder gar keine DKIM-Signatur oder ein SPF, das nicht zu Ihrer Domain passt.
Der Fix ist klar: Aktivieren Sie SPF und DKIM für alle Quellen, die in Ihrem Namen versenden. Bei vielen Umgebungen erledigen Sie das im Admin-Portal Ihres Anbieters und ergänzen dann DNS-Einträge in Ihrer Domainverwaltung. Wenn Sie mit Microsoft 365 arbeiten, setzen Sie SPF und aktivieren DKIM für die betroffenen Domänen und Versandwege. Wenn Sie zusätzlich Schutzfunktionen nutzen, kann auch Microsoft Defender for Office 365 eine Rolle spielen, weil dort Richtlinien und Prüfpfade dokumentiert sind und häufig als Referenz dienen.
Wenn header from und envelope sender oder DKIM-Signaturdomain nicht zusammenpassen, scheitert DMARC trotz „pass“ in Einzeldisziplinen. Dieser Fall fühlt sich besonders unfair an, weil „irgendwas“ ja scheinbar funktioniert.
Typisches Szenario: Sie versenden über ein Tool, das im sichtbaren Absender Ihre Domain zeigt, aber technisch eine andere Mail From-Domain nutzt. Dann prüft SPF nicht „ihre-domain.de“, sondern die technische Domain des Tools. Ergebnis: SPF kann passen, aber nicht aligned sein. Wenn DKIM dann ebenfalls nicht aligned ist oder fehlt, meldet DMARC fail.
Der Fix besteht nicht aus einem Trick, sondern aus sauberem Setup: Richten Sie im Versandtool eine Custom Domain ein. Stellen Sie sicher, dass das Tool Ihre Domain per DKIM signiert oder eine aligned DKIM-Signatur nutzt. Prüfen Sie, ob die Mail From beziehungsweise Mail From-Adresse auf Ihre Domain oder eine passende Subdomain zeigt.
Wenn ein System E-Mails in Ihrem Namen verschickt, das nicht in Ihrem SPF steht und nicht korrekt DKIM-signiert, wird DMARC fail wahrscheinlicher. Das passiert oft nach einem neuen Tool-Rollout oder nach einem Wechsel des Dienstleisters.
Der Fix beginnt mit Inventur: Sammeln Sie alle Quellen, die E-Mails senden. Dazu gehören Newsletter, Shop-System, Kontaktformulare, Helpdesk, Monitoring, ERP und auch externe Dienstleister. Danach prüfen Sie pro Quelle: Nutzt sie SPF über Ihre Domain, DKIM über Ihre Domain oder beides? Wenn Sie Lücken finden, ergänzen Sie entweder SPF oder aktivieren DKIM. Achten Sie dabei auf technische Limits von SPF, denn zu viele Weiterleitungen und Includes können SPF instabil machen. In solchen Fällen gewinnt DKIM an Bedeutung.
Wenn E-Mails weitergeleitet werden, kann SPF scheitern, obwohl die Originalmail legitim war. Weiterleitungen ändern den „liefernden“ Server. SPF sieht dann einen anderen Absenderpfad und kann failen.
Der Fix ist, DKIM robust einzusetzen, weil DKIM bei Weiterleitung oft stabiler bleibt, solange die Nachricht nicht verändert wird. Zusätzlich existieren Mechanismen wie vertrauenswürdige ARC-Versiegelungen, die Weiterleitung besser abbilden. In der Praxis lösen Sie das Problem jedoch meist durch konsequentes DKIM und eine realistische DMARC-Policy-Einführung. Wenn Ihre Mails regelmäßig über Mailinglisten oder Gateways laufen, prüfen Sie besonders sorgfältig, ob DKIM unterwegs beschädigt wird.
Wenn Ihr DMARC Record falsch formatiert ist, kann der Empfänger ihn nicht korrekt auswerten und Ihre Policy greift unerwartet. Das ist ein klassischer Grund für harte Ablehnungen, gerade wenn Sie eine strenge Policy setzen.
Ein DMARC Record ist ein DNS TXT Record. Er muss sauber syntaktisch sein, sonst interpretiert der Empfänger ihn nicht wie gedacht. In der Praxis entstehen Fehler durch Tippfehler, zusätzliche Zeichen oder falsch gesetzte Semikolons. Prüfen Sie Ihren Record mit einem Validator, bevor Sie ihn live schalten.
Wenn Sie zu früh auf eine strenge Policy gehen, können legitime E-Mails abgewiesen werden und Sie sehen DMARC fail als Zustellproblem. Das betrifft vor allem Organisationen, die mehrere Versandquellen haben und nicht alle sauber erfasst haben.
Eine reject Policy bedeutet: Empfänger sollen E-Mails, die DMARC nicht bestehen, ablehnen. Das ist ein gutes Ziel, aber erst dann, wenn Ihre Authentifizierung und Ausrichtung vollständig stimmen. Der Fix: Führen Sie DMARC stufenweise ein. Starten Sie mit Monitoring, sammeln Sie Reports, schließen Sie Lücken, erhöhen Sie dann schrittweise die Strenge.
Sie finden die Ursache am schnellsten, wenn Sie erst den Header prüfen und dann DNS und Reports gegenprüfen. So vermeiden Sie Rätselraten.
Im Header sehen Sie, ob SPF, DKIM und DMARC jeweils bestehen und welche Domains geprüft wurden. Öffnen Sie eine betroffene E-Mail und suchen Sie nach einer Zeile wie „Authentication-Results“. Dort finden Sie typischerweise Werte für SPF, DKIM und DMARC.
Achten Sie besonders auf zwei Dinge: Welche Domain steht bei SPF als geprüft, und welche Domain steht im sichtbaren Absender. Genau hier erkennen Sie Alignment-Probleme zwischen envelope sender und header from.
DMARC-Reports zeigen Ihnen, welche IPs und Systeme in Ihrem Namen senden und ob diese DMARC bestehen. Diese Reports kommen meist als aggregierte Zusammenfassungen, oft täglich. Ein Report hilft Ihnen vor allem bei zwei Fragen: Welche Quelle verursacht DMARC fail, und wie häufig passiert es? Das ist entscheidend, bevor Sie DNS-Änderungen machen. Ein einzelner Fail kann auch ein Randfall sein. Viele Fails aus einer Quelle zeigen ein Setup-Problem.
Im DNS prüfen Sie, ob SPF, DKIM und der DMARC Record korrekt existieren und zum Versand passen. Technisch prüfen Sie den SPF-Record der Domain, DKIM-Selector-Einträge des Versanddienstes und den DMARC Record unter _dmarc.
Wenn Sie Ihre DNS-Zone bei einem Provider oder über ein Tool verwalten, finden Sie die Einträge dort meist als TXT. Manche Anleitungen nennen explizit Umgebungen wie Kinsta DNS, weil viele Nutzer dort DNS verwalten. Das Prinzip ist jedoch überall gleich: Der relevante Punkt ist, dass der TXT-Record exakt passt.
Mit einer gezielten Testmail prüfen Sie, ob Ihre Anpassungen wirklich DMARC-konform ankommen. Senden Sie nach Änderungen eine E-Mail an mehrere Empfänger, idealerweise an einen großen Provider und an ein eigenes Testpostfach.
Wenn Sie Probleme speziell bei Google Mail sehen, lohnt sich ein Test dorthin, weil Google sehr transparent in den Headern zeigt, was geprüft wurde. Entscheidend bleibt aber: Prüfen Sie immer header from, envelope sender und DKIM-Domain gemeinsam, sonst sehen Sie nur einen Teil der Wahrheit.
Sie bekommen DMARC-Reports, weil Ihr DMARC Record eine Report-Adresse enthält und Empfänger Ihnen dann Rückmeldungen zur Authentifizierung senden. Das ist ein bewusstes Feature von DMARC, kein Fehler und kein Spam. DMARC ist im Kern Domain-based Message Authentication plus Reporting. Das Reporting ist der Teil, der Ihnen Sichtbarkeit verschafft.
Aggregierte Reports zeigen Ihnen in Zusammenfassung, welche Quellen E-Mails senden und wie SPF, DKIM und DMARC dabei abschneiden. Diese Reports kommen oft als XML-Anhang oder Link. Sie sind technisch, aber sie liefern genau die Informationen, die Sie für ein sauberes Rollout brauchen. Sie nutzen DMARC-Reports, um unbekannte Versandquellen zu finden, Alignment-Probleme aufzudecken und Ihre Policy sicher zu verschärfen.
Das klingt abstrakt, wird aber sehr konkret, wenn Sie es als Prozess sehen: Erstens identifizieren Sie alle legitimen Quellen. Zweitens richten Sie sie DMARC-konform aus. Drittens erkennen Sie Missbrauch, also Spoofing-Versuche, weil plötzlich Quellen auftauchen, die nicht zu Ihnen gehören.
Forensic Reports sind detaillierte Einzelmeldungen zu konkreten Nachrichten, werden aber aus Datenschutz- und Praxisgründen seltener genutzt. Manche Empfänger senden sie gar nicht oder nur eingeschränkt. Wenn Sie ruf nutzen, sollten Sie besonders sauber prüfen, welche Daten Sie dadurch erhalten und speichern.
Sie führen DMARC am sichersten ein, wenn Sie erst messen, dann korrigieren und erst danach streng werden. Dieser Ablauf schützt Sie vor unerwarteten Ablehnungen.
Starten Sie mit p=none, wenn Sie noch keine vollständige Übersicht über alle Versandquellen haben. Damit sammeln Sie Reports, ohne dass Empfänger aufgrund Ihrer Policy abweisen sollen. Sobald Ihre Quellen sauber sind und DKIM oder SPF aligned bestehen, erhöhen Sie die Policy.
Wenn Sie auf p=quarantine gehen, signalisieren Sie Empfängern, problematische Nachrichten eher als Spam zu behandeln. Das ist der Zwischenschritt, der Ihnen zeigt, ob noch unentdeckte Quellen existieren, ohne dass Sie sofort harte Bounces riskieren.
Mit p=reject erreichen Sie die stärkste Wirkung gegen Spoofing, aber nur, wenn Ihre legitimen Mails stabil bestehen. Eine reject Policy bedeutet: Empfänger sollen E-Mails, die DMARC nicht bestehen, ablehnen. Das ist ein gutes Ziel, aber erst dann, wenn Ihre Authentifizierung und Ausrichtung vollständig stimmen.
Ein typischer Fehler ist, nur SPF zu pflegen und DKIM zu vernachlässigen. SPF ist wichtig, aber in der Realität mit Weiterleitungen und komplexen Versandwegen anfälliger. Eine stabile DKIM-Signatur, korrekt zur Domain ausgerichtet, bringt meist die robustere Basis. Achten Sie außerdem auf technische Limits von SPF, denn zu viele Lookups können SPF instabil machen.
Ja, DMARC kann trotz SPF pass und DKIM pass fehlschlagen, wenn die Domains nicht zur Absenderdomain aus dem header from passen. Genau dafür existiert Alignment, und genau dort entstehen viele echte Praxisprobleme. SPF kann technisch bestehen, aber auf eine andere Domain prüfen als die sichtbare Absenderdomain. DKIM kann signieren, aber mit einer Domain, die nicht aligned ist. In beiden Fällen failt DMARC.
Ein einzelner DMARC fail ist nicht automatisch schlimm, aber er ist ein Signal, das Sie ernst nehmen sollten. Entscheidend ist, ob es sich häuft, ob es eine legitime Quelle betrifft und ob dadurch Zustellprobleme entstehen. Prüfen Sie den Report, identifizieren Sie die Quelle und klären Sie, ob es sich um einen Randfall oder ein systematisches Problem handelt.
DNS-Änderungen können je nach TTL und Provider zwischen wenigen Minuten und mehreren Stunden dauern, bis sie weltweit sichtbar sind. Planen Sie nach einer Änderung mindestens eine Stunde Wartezeit ein, bevor Sie Testmails versenden und bewerten. Wenn Sie kritische Änderungen vornehmen, senken Sie vorher die TTL, damit Änderungen schneller propagieren.
Diese Meldung bedeutet, dass der Empfänger Ihre Nachricht aufgrund seiner DMARC-Auswertung abgelehnt hat. Häufig tritt das auf, wenn eine Domain eine strenge Policy publiziert und die Nachricht DMARC nicht besteht. Prüfen Sie in diesem Fall Ihren DMARC Record, Ihre SPF- und DKIM-Konfiguration und ob Alignment gegeben ist.
Wenn Sie keinen Zugriff haben, klären Sie zuerst die Kontoverwaltung, zum Beispiel über die Funktion „Kennwort vergessen“, bevor Sie technische Änderungen planen. Ohne Admin-Zugriff können Sie SPF, DKIM und DMARC nicht sauber korrigieren. Wenn Sie in einer Organisation arbeiten, wenden Sie sich an Ihren IT-Verantwortlichen oder Hosting-Provider.
Hilfreich sind Header-Analysen, DMARC-Report-Auswertung und DNS-Prüfung, weil Sie damit Ursache und Quelle eindeutig sehen. Manche Anbieter bündeln das in Werkzeugen wie einer Power Toolbox, entscheidend bleibt aber immer der Blick auf header from, envelope sender, SPF, DKIM und den DMARC Record. Nutzen Sie außerdem Online-Validatoren für SPF, DKIM und DMARC, um Syntaxfehler auszuschließen.
Ein DMARC fail ist kein unlösbares Hindernis, sondern ein klares Signal für eine fehlerhafte Abstimmung Ihrer E-Mail-Authentifizierung. Sorgen Sie für ein sauberes Alignment von SPF und DKIM zur sichtbaren Absenderdomain, um Ihre Zustellbarkeit dauerhaft zu sichern. Gehen Sie schrittweise vor, wenn Sie Ihre DMARC-Policy einführen, und nutzen Sie die Berichte zur kontinuierlichen Überwachung Ihrer Versandquellen. So schützen Sie Ihre Domain effektiv vor Missbrauch und stärken gleichzeitig das Vertrauen der Empfänger in Ihre Nachrichten.
