DMARC einrichten: die Schritt-für-Schritt-Anleitung

Du hast SPF und DKIM längst eingerichtet, aber Kunden oder Kollegen berichten trotzdem von Phishing-Mails, die angeblich von deiner Domain kommen? Oder ein Sicherheits-Audit verlangt DMARC, und du weißt nicht, wo du anfangen sollst? DMARC ist genau dafür gedacht: Es sagt Postfächern wie GMX, Web.de, T-Online, Gmail oder Outlook, was mit E-Mails passieren soll, die SPF oder DKIM nicht bestehen — und liefert dir Berichte darüber, wer in deinem Namen mailt. Diese Anleitung zeigt dir den kompletten Weg von der ersten Testphase bis zur vollen Durchsetzung.

Was DMARC eigentlich macht

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist kein Ersatz für SPF und DKIM, sondern baut auf beiden auf. Es prüft zwei Dinge: erstens, ob SPF oder DKIM für die eingehende Mail überhaupt bestehen, und zweitens, ob die dabei verwendete Domain mit der sichtbaren Absenderdomain im From:-Header übereinstimmt — das nennt man Alignment. Erst wenn mindestens einer der beiden Checks besteht und aligned ist, gilt DMARC als bestanden. Danach entscheidet deine Policy, was mit dem Rest passiert: nichts tun, in Quarantäne (meist Spam-Ordner) schicken oder ganz ablehnen.

Voraussetzung: SPF und DKIM müssen sauber laufen

Bevor du überhaupt einen DMARC-Record anlegst, sollten SPF und DKIM für deine Domain funktionieren und im Idealfall sogar für dieselbe Domain aligned sein, die imFrom:-Header steht. Typische Stolperfallen dabei:

• Der SPF-Record verweist auf den falschen Versanddienst (etwa Shopware, JTL-Shop, ein ESP wie CleverReach, rapidmail oder Mailjet DE), weil der genutzte Include-Eintrag veraltet oder unvollständig ist.
• DKIM ist zwar beim Versanddienst aktiviert, aber der öffentliche Schlüssel wurde nie als DNS-Eintrag bei deiner Domain hinterlegt.
• Die Mail wird technisch über eine Subdomain oder einen Drittanbieter-Envelope-Sender verschickt, sodass SPF zwar besteht, aber nicht zur sichtbaren Absenderdomain aligned ist.

Am schnellsten findest du solche Lücken, indem du eine Testmail an einen kostenlosen Inbox-Placement-Test schickst — der zeigt dir SPF-, DKIM- und DMARC-Status auf einen Blick, bevor du den DMARC-Record scharf schaltest.

Den DMARC-TXT-Record Schritt für Schritt erstellen

1. Lege im DNS deiner Domain einen TXT-Record auf dem Host _dmarc.deinedomain.de an.
2. Beginne mit einer reinen Beobachtungs-Policy: p=none. Damit greift DMARC noch nicht aktiv ein, du bekommst aber bereits Berichte.
3. Trage eine Adresse für aggregierte Berichte (rua) ein — ein Postfach oder ein Dienst, der die täglichen XML-Reports auswertet.
4. Optional: forensische Berichte (ruf) für Einzelfälle, in der Praxis werden diese aber von vielen großen Providern kaum noch verschickt.
5. Optional: pct=100 setzt explizit, dass die Policy auf 100 % der Mails angewendet wird — sinnvoll, wenn du später schrittweise hochfahren willst.

Wichtig: adkim=s und aspf=s stehen für „strict alignment" — die Domain in SPF bzw. DKIM muss dann exakt mit der From-Domain übereinstimmen, nicht nur eine Subdomain davon sein. Für die meisten Setups reicht der Standardwertrelaxed (also gar nichts eintragen), strict solltest du nur nutzen, wenn du die Konsequenzen für all deine Subdomains genau kennst.

rua-Reports lesen und auswerten

Sobald der Record steht, senden dir große Provider wie Gmail, Outlook, GMX oder Web.de täglich aggregierte XML-Reports an die rua-Adresse. Diese Rohdaten sind für Menschen kaum lesbar, deshalb lohnt sich ein kleiner Report-Parser oder ein Dashboard- Dienst, der sie visualisiert. Worauf du achten solltest:

• Welche IP-Adressen und Systeme mailen überhaupt unter deiner Domain? Manchmal tauchen hier vergessene Tools, alte Marketing-Automation-Setups oder sogar Spoofing-Versuche auf.
• Bestehen SPF und DKIM für den erwarteten Versand (dein ESP, dein Shopsystem, dein Transaktionsmail-Dienst) durchgehend, oder gibt es Lücken bei bestimmten Absendern?
• Wie hoch ist der Anteil an Mails, die DMARC insgesamt nicht bestehen? Das ist dein wichtigster Indikator dafür, ob eine Eskalation auf quarantine schon sicher ist.

Policy eskalieren: von none über quarantine bis reject

Der zentrale Fehler bei DMARC ist Ungeduld. Eskaliere die Policy erst, wenn die Reports über mehrere Wochen zeigen, dass praktisch der gesamte legitime Versand DMARC besteht. Ein bewährter Ablauf:

1. p=none für mehrere Wochen, alle Versandquellen identifizieren und SPF/ DKIM für jede davon korrigieren.
2. p=quarantine; pct=10 — Fehler landen erstmal im Spam-Ordner, aber nur bei einem kleinen Prozentsatz. Reports weiter beobachten.
3. pct schrittweise erhöhen (25, 50, 100), solange keine legitimen Mails betroffen sind.
4. Erst wenn p=quarantine; pct=100 sauber läuft, auf p=reject wechseln — das ist die einzige Policy, die Spoofing wirklich zuverlässig verhindert.

Typische Fehler bei der DMARC-Einführung

• Alignment übersehen: SPF und DKIM bestehen technisch, aber die verwendete Domain weicht von der From-Domain ab — DMARC schlägt trotzdem fehl.
• Subdomains vergessen: Ohne sp=-Tag erbt jede Subdomain die Policy der Hauptdomain — das ist meist gewollt, sollte aber bewusst geprüft werden, gerade wenn Subdomains für andere Tools genutzt werden.
• Zu früh auf reject springen: Ohne vorherige Auswertung der Reports landen dann auch legitime Rechnungen, Newsletter oder Transaktionsmails im Nirwana.
• Shopsysteme und ESPs nicht eingebunden: Shopware-, JTL-Shop- oder WooCommerce-Installationen versenden oft über den Hosting-Server ohne korrektes SPF/ DKIM — das fällt erst bei der DMARC-Auswertung auf.
• Kein Monitoring nach dem Rollout: DMARC ist kein einmaliges Setup. Neue Tools, neue Marketing-Plattformen oder ein Providerwechsel können die Alignment- Rate jederzeit wieder verschlechtern.

Für einen schnellen Realitätscheck zwischen zwei Report-Zyklen hilft ein kostenloser Zustellbarkeitstest: Er zeigt dir sofort, ob SPF, DKIM und DMARC bei GMX, Web.de, T-Online, Gmail und weiteren Postfächern grün sind, inklusive Screenshot der Zustellung.