Ein DMARC-Fehler heißt fast nie, dass DMARC selbst kaputt ist. Meist besteht zwar SPF oder DKIM, aber die geprüfte Domain passt nicht zur sichtbaren Absenderdomain im From-Feld. Diese Prüfung heißt Alignment. Um den Fehler zu beheben, finden Sie zuerst heraus, welcher Absender scheitert: Ihr eigenes Postfach, ein Newsletter-Dienst, ein CRM, ein Ticketsystem oder eine Weiterleitung. Dann sorgen Sie dafür, dass dieser Absender mit Ihrer Domain per DKIM signiert. Hier steht, wie Sie die Ursache in wenigen Schritten eingrenzen, welche Lösung zu welchem Symptom passt und wann die Policy p=quarantine die richtige Wahl ist.

TL;DR

• DMARC besteht nur, wenn SPF oder DKIM besteht und die geprüfte Domain zur From-Domain passt. „SPF pass, DMARC fail“ ist deshalb fast immer ein Alignment-Problem.
• Die zuverlässigste Lösung: DKIM-Signatur mit Ihrer eigenen Domain bei jedem Dienst aktivieren, der in Ihrem Namen sendet. Eine weitere Zeile im SPF-Eintrag hilft hier selten.
• Lesen Sie den Header Authentication-Results der fehlgeschlagenen Nachricht und Ihre Aggregate Reports (rua). Dort steht, welche Quelle durchfällt.
• Weiterleitungen und Mailinglisten brechen DMARC häufig. SRS rettet nur SPF, nicht das Alignment.
• p=quarantine schiebt nicht bestehende Mails in den Spam-Ordner. Für Domains mit echten Postfächern ist das oft der sinnvolle Dauerzustand.

Inhaltsverzeichnis

• Was ein DMARC-Fail technisch bedeutet
• Die Ursache in fünf Schritten eingrenzen
• Häufige Ursachen und ihre Lösung
• p=quarantine: was die Policy bewirkt und wann sie passt
• Von p=none sicher zur Durchsetzung
• Was wir bei Cold-Email-Domains beobachten
• Sendedomains, die von Anfang an sauber authentifiziert sind
• Häufige Fragen zu DMARC-Fehlern
• Quellen

Was ein DMARC-Fail technisch bedeutet

DMARC prüft nicht selbst, ob eine Mail echt ist. Es wertet die Ergebnisse von SPF und DKIM aus und verlangt dabei eine zusätzliche Bedingung. Laut der aktuellen DMARC-Spezifikation der IETF (DMARCbis) muss mindestens eines der beiden Verfahren bestehen, und die dabei geprüfte Domain muss zur Domain im From-Header passen. Für dieses „Passen“ gibt es zwei Modi:

• Relaxed (Standard, adkim=r bzw. aspf=r): Es reicht dieselbe Organisationsdomain. news.beispiel.de passt zu beispiel.de.
• Strict (adkim=s bzw. aspf=s): Die Domains müssen exakt identisch sein. news.beispiel.de passt dann nicht zu beispiel.de.

Daraus folgt der Klassiker, über den die meisten stolpern: Ein Newsletter-Dienst verschickt Ihre Mail mit einer eigenen Envelope-Absenderadresse, etwa bounce.versanddienst.com. SPF prüft genau diese Domain und besteht. DMARC vergleicht aber mit beispiel.de im From-Feld, findet keine Übereinstimmung und meldet dmarc=fail. Technisch ist alles „grün“, und trotzdem fällt die Mail durch.

Was der Empfänger mit einer durchgefallenen Mail macht, legen Sie mit der Policy fest. Google beschreibt die drei Optionen so: zustellen (none), in Quarantäne verschieben (quarantine) oder ablehnen (reject). Ein DMARC-Fehler mit p=none kostet Sie also erst einmal nur Sichtbarkeit in den Reports. Mit quarantine oder reject kostet er Zustellung.

Die Ursache in fünf Schritten eingrenzen

Bevor Sie DNS-Einträge ändern, klären Sie, wo genau der Fehler entsteht. Diese Reihenfolge spart Zeit.

1. DMARC-Eintrag abfragen. Im Terminal genügt dig TXT _dmarc.beispiel.de +short, unter Windows nslookup -type=TXT _dmarc.beispiel.de. Prüfen Sie: Gibt es genau einen Eintrag? Beginnt er mit v=DMARC1? Sind die Tags durch Semikolons getrennt? Zwei DMARC-Einträge auf derselben Domain sind ein häufiger und leicht übersehener Fehler. Google empfiehlt ausdrücklich, zuerst den Eintrag zu prüfen und erst dann tiefer zu suchen.
2. Den Header einer fehlgeschlagenen Mail lesen. Öffnen Sie in Gmail „Original anzeigen“ oder in Outlook die Nachrichtenoptionen. Suchen Sie die Zeile Authentication-Results. Die Spezifikation sieht vor, dass Empfänger dieses Feld mindestens setzen sollen. Dort steht etwa: spf=pass smtp.mailfrom=bounce.versanddienst.com; dkim=pass header.d=versanddienst.com; dmarc=fail header.from=beispiel.de. Jetzt sehen Sie auf einen Blick: Beide Prüfungen bestehen, aber für die falsche Domain.
3. Aggregate Reports auswerten. Mit rua=mailto:dmarc@beispiel.de schicken Ihnen große Postfachanbieter täglich XML-Berichte. Sie zeigen pro sendender IP, wie viele Mails SPF, DKIM und DMARC bestanden haben. Die Reports sagen Ihnen, was passiert. Warum es passiert, sehen Sie erst im Header einer konkreten Nachricht aus dieser Quelle.
4. Alle legitimen Absender auflisten. Gehen Sie jede IP aus den Reports durch und ordnen Sie sie einem Dienst zu: Google Workspace oder Microsoft 365, CRM, Newsletter-Tool, Buchhaltungssoftware, Bewerbermanagement, Cold-Email-Plattform, Webserver mit Kontaktformular. Unbekannte Quellen mit hohem Volumen sind entweder ein vergessener Dienst oder tatsächlich Spoofing.
5. Pro Quelle die passende Lösung umsetzen (siehe Tabelle unten) und 48 Stunden später erneut testen. DNS-Änderungen brauchen Zeit, und Reports kommen mit einem Tag Verzögerung.

Häufige Ursachen und ihre Lösung

Die Tabelle fasst zusammen, was wir und andere in der Praxis am häufigsten sehen. Die Zuordnung von Symptom zu Ursache folgt der Fehlerbehebungsanleitung von Microsoft, die dieselbe Logik verwendet.

SPF besteht, DMARC trotzdem nicht

Das ist die häufigste Suchanfrage zu diesem Thema, und die Antwort ist fast immer dieselbe: fehlendes SPF-Alignment. Der Reflex, den Dienst noch einmal in den SPF-Eintrag aufzunehmen, hilft nicht, denn SPF besteht ja bereits. Es besteht nur für die falsche Domain. Microsoft empfiehlt in diesem Fall, DKIM-Signierung für die Domain im From-Header zu aktivieren. DKIM ist auch deshalb die bessere Wahl, weil eine Signatur eine Weiterleitung überstehen kann, solange der Inhalt nicht verändert wird. SPF bricht dagegen, sobald ein anderer Server die Mail weiterreicht.

Wie Sie DKIM-Einträge richtig veröffentlichen und welche Schlüssellänge sinnvoll ist, erklärt unser Leitfaden zu DKIM-Einträgen. Warum fehlendes DKIM-Alignment Ihre Zustellung leise ruinieren kann, auch ohne sichtbare Fehlermeldung, lesen Sie im Beitrag DKIM-Alignment als unterschätzter Zustellbarkeitskiller.

DKIM signiert mit der Domain des Anbieters

Viele Tools signieren standardmäßig mit ihrer eigenen Domain. Im Header steht dann dkim=pass header.d=anbieter.com. Für DMARC zählt diese Signatur nicht. Die Lösung liegt fast immer im Admin-Bereich des Dienstes unter Punkten wie „Domain authentifizieren“ oder „Eigene Absenderdomain“. Dort erhalten Sie zwei oder drei CNAME-Einträge, die Sie beim DNS-Hoster anlegen. Erst danach signiert der Dienst mit d=beispiel.de.

Weiterleitungen und Mailinglisten

Wenn ein Empfänger Ihre Mail automatisch an ein anderes Postfach weiterleitet, sendet sein Server die Nachricht neu. SPF scheitert dann, weil der weiterleitende Server nicht in Ihrem SPF steht. Microsoft 365 nutzt dafür das Sender Rewriting Scheme (SRS), das die Envelope-Absenderadresse umschreibt. Das rettet SPF, aber nicht DMARC: Die umgeschriebene Adresse gehört zur Domain des Weiterleiters, nicht zu Ihrer. Retten kann die Mail nur eine intakte, ausgerichtete DKIM-Signatur oder ARC (Authenticated Received Chain), mit dem der weiterleitende Server das ursprüngliche Prüfergebnis mitgibt.

Mailinglisten sind noch heikler, weil sie oft den Betreff ergänzen oder eine Fußzeile anhängen. Dann bricht auch DKIM. Gegen diese Fälle auf Empfängerseite können Sie als Absender wenig tun. Umso wichtiger ist, dass Ihre Policy nicht strenger ist, als Ihr Mailverkehr verträgt.

Fehler im DMARC-Eintrag selbst

Seltener, aber schnell behoben: Tippfehler wie p=quarantaine, fehlende Semikolons, ein rua ohne mailto:, zwei Einträge auf _dmarc oder ein Eintrag auf der falschen Ebene. Ein korrekter Eintrag für den Start sieht so aus:

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de; adkim=r; aspf=r

Wenn Ihre Reports an eine Adresse auf einer anderen Domain gehen sollen, muss diese Domain den Empfang erlauben. Sonst kommen keine Berichte an, und Sie suchen im Dunkeln.

p=quarantine: was die Policy bewirkt und wann sie passt

Mit p=quarantine bitten Sie empfangende Server, Mails, die DMARC nicht bestehen, als verdächtig zu behandeln. In der Praxis landen sie im Spam- oder Junk-Ordner, statt zugestellt oder abgelehnt zu werden. Das ist der Mittelweg: Gefälschte Mails erreichen den Posteingang nicht mehr, und eine legitime Mail, die an einer Weiterleitung scheitert, ist nicht verloren, sondern im Spam-Ordner auffindbar.

Das britische National Cyber Security Centre rät, auf quarantine zu wechseln, sobald SPF und DKIM korrekt eingerichtet und alle bekannten legitimen Absender erfasst sind. Erst dann wird gefälschte Post tatsächlich als Spam markiert. In Deutschland nennt das BSI im IT-Grundschutz-Baustein APP.5.3 zu E-Mail-Client und -Server den Einsatz von DMARC als Anforderung, die Institutionen erfüllen sollten.

Lange galt p=reject als Ziel für jede Domain. Das hat sich geändert. Nach der neuen Spezifikation RFC 9989 sollen Organisationen ihre Policy danach wählen, wie eine Domain genutzt wird, und p=reject ist nicht mehr die pauschale Empfehlung für alle Domains. Für Domains, über die Menschen schreiben und deren Mails weitergeleitet oder über Verteiler verschickt werden, ist quarantine oft der vernünftige Dauerzustand. Für Domains, die ausschließlich maschinell senden, etwa Rechnungen oder Systembenachrichtigungen, passt reject besser.

Ein praktischer Weg ist deshalb die Trennung: Transaktionsmails über eine eigene Subdomain wie rechnung.beispiel.de mit strenger Policy, die Hauptdomain mit quarantine. Über den Tag sp= legen Sie fest, welche Policy für Subdomains gilt, wenn diese keinen eigenen Eintrag haben.

Wichtig, falls Sie gerade akut Mails verlieren: Wenn Ihre Domain auf p=reject steht und Kunden plötzlich keine Mails mehr bekommen, stellen Sie zuerst auf p=quarantine zurück. Dann landen die betroffenen Mails wenigstens im Spam-Ordner statt im Nichts, und Sie gewinnen Zeit für die Ursachensuche. Zurück auf p=none sollten Sie nur, wenn Sie sich bewusst entscheiden, den Spoofing-Schutz vorübergehend aufzugeben.

Von p=none sicher zur Durchsetzung

Die meisten DMARC-Fehler, die Zustellung kosten, entstehen durch einen zu schnellen Wechsel der Policy. Google empfiehlt ausdrücklich, SPF und DKIM mindestens 48 Stunden vor DMARC einzurichten und DMARC schrittweise einzuführen. Ein bewährter Ablauf:

1. Woche 1 bis 2: p=none mit Reports. Sammeln Sie Daten, identifizieren Sie jede Quelle, korrigieren Sie DKIM und SPF pro Dienst.
2. Ab etwa Woche 3: p=quarantine. Erst wenn die Reports für alle legitimen Quellen bestandenes, ausgerichtetes DKIM oder SPF zeigen.
3. Weiter beobachten. Neue Tools kommen dazu, Kolleginnen buchen ein Webinar-Tool, das in Ihrem Namen einlädt. Jede neue Quelle muss in die Inventarliste.
4. Optional p=reject für rein maschinell sendende Domains und Subdomains, wenn die Reports über Wochen sauber sind.

Nach Googles Erfahrung schaffen viele Organisationen diesen Übergang in sechs bis acht Wochen. Früher hat man mit pct=25 nur einen Teil der Mails der strengeren Policy unterworfen. Die neue DMARC-Spezifikation ersetzt pct durch den Test-Tag t=y, weil Empfänger Zwischenwerte sehr unterschiedlich umgesetzt haben. Wer heute einen Testmodus will, setzt also t=y statt Prozentwerte.

Was Sie konkret vor dem Hochfahren von Outbound-Kampagnen einstellen sollten, haben wir im Beitrag DMARC-Policy vor dem Skalieren von Outbound zusammengefasst.

Was wir bei Cold-Email-Domains beobachten

Im Outbound-Vertrieb ist ein DMARC-Fehler selten ein Sicherheitsthema und fast immer ein Umsatzthema. Ein Team richtet zehn neue Sendedomains ein, kopiert den SPF-Eintrag von der Hauptdomain, vergisst DKIM auf zwei Domains und startet die Kampagne. Die Mails gehen raus, die Öffnungsraten sehen anfangs normal aus, und erst nach Tagen fällt auf, dass ein Teil im Spam-Ordner landet. Niemand bekommt eine Fehlermeldung. Genau das macht fehlendes Alignment so teuer.

Unsere Haltung ist deshalb einfach: Jede Sendedomain braucht ausgerichtetes DKIM mit der eigenen Domain, einen sauberen SPF-Eintrag ohne Lookup-Überlauf und eine DMARC-Policy mit Reports, bevor die erste Kampagnenmail rausgeht. Danach kommt das Warm-up, nicht davor. Ein Warm-up auf einer Domain mit kaputtem Alignment baut Reputation auf einem Fundament auf, das jederzeit wegbrechen kann.

Zweitens trennen wir Kaltakquise konsequent von der Hauptdomain. Ihre Rechnungen, Ihr Support und die Mails Ihrer Geschäftsführung sollen nicht unter einem Reputationsproblem leiden, das eine aggressive Kampagne verursacht hat. Separate Sendedomains mit eigener Authentifizierung sind dafür die Grundlage. Und drittens prüfen wir die Zustellbarkeit laufend, nicht einmalig: DNS-Einträge werden geändert, Dienste wechseln ihre Server, und ein Eintrag, der im Januar stimmte, kann im Oktober fehlerhaft sein.

— Yaro

Sendedomains, die von Anfang an sauber authentifiziert sind

Wenn Sie Cold-Email-Outreach betreiben und DMARC-Fehler nicht mehr pro Domain von Hand jagen wollen: PlusVibe verbindet private Warm-up-Infrastruktur, isolierte Versandserver, dedizierte IPs und Deliverability-Monitoring in einer Plattform. Postfächer bei Google Workspace bekommen Sie bei uns für 4 USD pro Monat und Postfach, bei Microsoft 365 für 4,50 USD pro Monat und Postfach. Wer die Einrichtung von Domains, SPF, DKIM und DMARC komplett abgeben möchte, nutzt unser Done-for-you-E-Mail-Setup für 1.500 USD pro Monat. Alle Tarife, vom Starter-Plan für 19 USD pro Monat bis zum Agency-Plan ab 497 USD pro Monat, finden Sie auf unserer Preisübersicht. Eine kostenlose Testphase gibt es ebenfalls.

Für die Prüfung Ihres bestehenden Setups hilft unsere Checkliste für das Deliverability-Audit, und die Grundlagen zu allen drei Einträgen stehen in unserem Tech-Setup für Cold Email mit SPF, DKIM und DMARC.

Häufige Fragen zu DMARC-Fehlern

Wie kann ich meinen DMARC-Eintrag abfragen?

Mit dig TXT _dmarc.ihredomain.de +short unter macOS oder Linux, unter Windows mit nslookup -type=TXT _dmarc.ihredomain.de. Das Ergebnis muss genau ein Eintrag sein, der mit v=DMARC1 beginnt. Viele kostenlose Online-Prüftools zeigen zusätzlich an, ob die Syntax stimmt.

Warum besteht SPF, aber DMARC trotzdem nicht?

Weil SPF für eine andere Domain bestanden hat als die im From-Feld. Das passiert typischerweise bei Newsletter-Tools, CRMs und Ticketsystemen, die mit eigener Bounce-Domain senden. Die Lösung ist, beim jeweiligen Dienst DKIM für Ihre eigene Domain einzurichten, statt den SPF-Eintrag weiter aufzublähen.

Wie behebe ich SPF-Fehler?

Prüfen Sie zuerst, ob es genau einen SPF-Eintrag gibt und ob er mehr als zehn DNS-Lookups auslöst. Dann ergänzen Sie fehlende Dienste per include: und entfernen Dienste, die Sie nicht mehr nutzen. Wie das in wenigen Minuten geht, zeigt unser Beitrag zum SPF-Eintrag in der Praxis.

Ist p=quarantine sicherer als p=none?

Ja, denn erst ab quarantine hat DMARC eine Wirkung auf gefälschte Mails. Mit p=none erhalten Sie nur Berichte, Empfänger behandeln Fälschungen aber wie normale Post. Wechseln Sie trotzdem erst, wenn Ihre Reports zeigen, dass alle legitimen Absender ausgerichtet bestehen.

Wie lange dauert es, bis eine DMARC-Korrektur wirkt?

DNS-Änderungen sind oft nach Minuten sichtbar, können aber je nach TTL bis zu 48 Stunden brauchen. Aggregate Reports kommen meist einmal täglich. Planen Sie also zwei bis drei Tage ein, bevor Sie beurteilen, ob eine Änderung den Fehler behoben hat.

Quellen

• IETF: DMARCbis, draft-ietf-dmarc-dmarcbis-37
• Google Workspace: Set up DMARC
• Google Workspace: Troubleshoot DMARC issues
• Google Workspace: Recommended DMARC rollout
• Microsoft Learn: Problembehandlung bei der E-Mail-Authentifizierung in Microsoft 365
• Microsoft Learn: Troubleshoot email authentication in Microsoft 365
• Microsoft Learn: Sender Rewriting Scheme (SRS) in Microsoft 365
• NCSC: Email security and anti-spoofing
• BSI IT-Grundschutz: APP.5.3 Allgemeiner E-Mail-Client und -Server

Empfehlungen

• SPF Flattening: Permerror in unter 15 Minuten beheben
• Postmaster-Tools-Einrichtung: 6 DNS-Schritte, bevor Gmail Daten anzeigt
• Technische Einrichtung für Kaltakquise-E-Mails – SPF, DKIM, DMARC
• SPF, DKIM & DMARC: Der ultimative Leitfaden zur E-Mail-Sicherheit