Kostenloser DMARC-Record- Checker

Was ist DMARC und warum ist es 2026 wichtig

DMARC — Domain-based Message Authentication, Reporting & Conformance — ist die Policy-Schicht, die SPF und DKIM zusammenhält. SPF sagt empfangenden Servern, welche IPs E-Mails für deine Domain senden dürfen. DKIM signiert jede Nachricht kryptografisch, damit Empfänger prüfen können, dass sie unterwegs nicht manipuliert wurde. DMARC ist die Anleitung dazu: Es sagt Gmail, Outlook, Yahoo und allen anderen Inbox-Providern, was sie tun sollen, wenn eine Nachricht angeblich von deiner Domain kommt und einen oder beide Checks nicht besteht. Ohne DMARC können Angreifer deine Absenderadresse fälschen und auf deiner Reputation direkt in Kunden-Inboxen landen.

2026 ist das nicht mehr optional. Seit Februar 2024 — und 2025 sowie 2026 stetig verschärft — verlangen Gmail und Yahoo von jedem Sender mit mehr als 5.000 Nachrichten pro Tag einen gültigen DMARC-Record. Microsoft 365 hat mit eigener Durchsetzung für Versender mit hohem Volumen nachgezogen. Domains ohne DMARC sehen Bulk-Mail abgewiesen oder direkt im Spam landen, und Brand-Impersonation-Phishing-Raten verdoppeln sich grob, wenn DMARC fehlt.

Aufbau eines DMARC-Records

Ein DMARC-Record ist ein einzelner TXT-Record, veröffentlicht unter _dmarc.deinedomain.com. Er ist eine Liste von Tags, getrennt durch Semikolons. Hier ein typischer Record und was jedes Element macht:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=r; adkim=r;

• v=DMARC1 — Pflicht-Versionstag. Muss exakt DMARC1 (case-sensitive) sein, sonst wird der gesamte Record ignoriert.
• p= — Die Policy selbst. p=none bedeutet nur überwachen — Fehlschläge werden weiterhin zugestellt. p=quarantine schickt fehlschlagende Mail in den Spam-Ordner. p=reject blockiert sie direkt an der SMTP-Grenze.
• rua= — Mailbox für Aggregate-Reports. Empfänger schicken hier täglich XML-Reports hin, die zusammenfassen, welche IPs Mail über deine Domain verschickt haben und wie viele Nachrichten bestanden oder fehlgeschlagen sind. Format: rua=mailto:dmarc-reports@deinedomain.com.
• ruf= — Mailbox für Forensik- (Failure-)Reports. Per-Message-Failure-Samples mit Headern und manchmal einem geschwärzten Body. Die meisten Provider senden diese aus Datenschutzgründen nicht mehr, daher ist rua in der Praxis viel nützlicher.
• pct= — Prozentsatz der fehlschlagenden Mail, auf den die Policy angewendet wird (1–100). Damit kannst du Rollouts staffeln: pct=25 mit p=quarantine quarantäniert ein Viertel der Fehlschläge, während 75% weiterhin zugestellt werden.
• aspf= / adkim= — Alignment-Modus. aspf=s/r und adkim=s/r steuern, ob das SPF/DKIM-Domain-Matching strict (exakte Übereinstimmung) oder relaxed (Subdomain erlaubt) ist. Standard ist relaxed, was fast immer das Richtige ist.

5 häufige DMARC-Fehler und wie du sie behebst

Fehler: Kein DMARC-Record gefunden

Der häufigste Fehlermodus. Führe dig TXT _dmarc.deinedomain.com aus — wenn nichts zurückkommt, fehlt der Record. Prüfe drei Dinge: (1) Du hast den TXT-Record auf _dmarc als Subdomain veröffentlicht, nicht auf der Root-Domain; (2) das Host-Feld ist exakt _dmarc mit führendem Unterstrich (manche DNS-UIs entfernen ihn); (3) du hast auf Propagierung gewartet. TTL liegt typischerweise bei 300–3600 Sekunden, aber Cloudflare und Route53 sind meist binnen einer Minute live. Vermeide Großschreibung wie _DMARC — DNS-Labels sind case-insensitiv, aber manche Validatoren sind streng.

Fehler: Mehrere DMARC-Records

Wenn zwei oder mehr TXT-Records auf _dmarc existieren, verlangt RFC 7489, dass Empfänger alle ignorieren — deine Domain fällt auf keine Policy zurück. Das passiert oft, wenn ein Marketing-Tool oder Migrations-Skript einen zweiten Record veröffentlicht, ohne den ersten zu entfernen. Führe dig +short TXT _dmarc.deinedomain.com aus — siehst du mehr als eine v=DMARC1-Zeile, lösche die ältere oder schwächere. Konsolidiere alles zu einem einzigen Record mit allen Tags, die du brauchst (p, rua, ruf, pct, aspf, adkim).

Fehler: Ungültige Syntax

DMARC-Parser sind streng. Die fünf häufigsten Syntaxfehler: (1) fehlende Semikolons zwischen Tags — jedes Tag-Paar muss mit ; enden; (2) =-Zeichen in mailto-URIs ohne korrekte Encodierung; (3) Smart-Quotes aus einem Word-Dokument statt gerader ASCII-Anführungszeichen; (4) Tippfehler wie p=quarentine oder p=rejct; (5) den ganzen Record in zusätzliche Anführungszeichen wickeln, wenn die DNS-UI die schon hinzufügt. Validiere mit unserem Checker oben — er parst Tag für Tag und sagt dir genau, welches Token fehlgeschlagen ist.

Fehler: SPF/DKIM-Alignment-Fehlschläge

DMARC besteht nur, wenn entweder SPF oder DKIM authentifiziert UND mit der From-Domain ausgerichtet ist. Häufige Falle: Dein ESP (z. B. Mailchimp) authentifiziert mit eigenem Return-Path wie bounces.mcsv.net, also besteht SPF, aber stimmt nicht mit deinedomain.com überein. Beheben, indem du DKIM-Signing mit deiner Domain beim ESP aktivierst — DKIM-Alignment ist einfacher als SPF-Alignment, weil das d=-Tag in der DKIM-Signatur deiner Root-Domain entsprechen kann. Für Subdomains setze aspf=r und adkim=r (relaxed, der Standard), damit Subdomain-Mail mit der Root übereinstimmt.

5-Schritte-DMARC-Setup-Walkthrough

1. Aktuelle Authentifizierung auditieren — Bevor du DMARC veröffentlichst, repariere SPF und DKIM. Lass unseren SPF-Checker und DKIM-Checker auf jeder sendenden Domain und Subdomain laufen. Bestätige, dass SPF unter dem 10-DNS-Lookup-Limit liegt und mit -all oder ~all endet. Bestätige, dass DKIM mit einem 2048-Bit-Schlüssel signiert und mit deiner From-Domain ausgerichtet ist.
2. Monitoring-Record veröffentlichen (p=none) — Füge diesen TXT-Record auf Host _dmarc hinzu: v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.com; pct=100; aspf=r; adkim=r. p=none bedeutet keine Auswirkung auf den Mail-Flow — Empfänger fangen an, dir Aggregate-Reports zu schicken, ohne irgendwas zu quarantänieren oder abzulehnen. Das ist deine Daten-Sammelphase. Nutze eine dedizierte Mailbox oder ein DMARC-Analyse-Tool, weil rohes XML ab einem gewissen Volumen unlesbar ist.
3. Aggregate-Reports sammeln — Innerhalb von 24 Stunden solltest du täglich XML-Reports von großen Empfängern bekommen. Parse sie, um jede IP und Plattform zu identifizieren, die Mail über deine Domain verschickt. Erwartete Sender (Google Workspace, Mailchimp, SendGrid) sollten bestehen. Unerwartete sind entweder Schatten-IT oder Spoofer — recherchiere, bevor du die Policy verschärfst.
4. Auf Quarantine mit pct=25 wechseln — Sobald 95%+ der legitimen Mail SPF und DKIM mit Alignment besteht, verschärfe auf v=DMARC1; p=quarantine; pct=25; rua=...;. Jetzt geht 25% der fehlschlagenden Mail in Spam. Beobachte Reports und Helpdesk-Tickets auf False Positives. Nach zwei sauberen Wochen erhöhe pct auf 50, dann 100.
5. p=reject erreichen — Endzustand: v=DMARC1; p=reject; rua=mailto:dmarc@deinedomain.com; pct=100;. Fehlschlagende Mail wird an der SMTP-Grenze abgewiesen — Phisher können deine Domain nicht mehr spoofen. Das ist die einzige Konfiguration, die deine Marke vollständig schützt. Die meisten Domains erreichen reject innerhalb von 8 Wochen nach Start bei p=none.

DMARC-Rollout-Phasen (4 bis 8 Wochen)

Ein sicherer DMARC-Rollout folgt einer prozentualen Rampe, damit du Fehlkonfigurationen findest, bevor sie der Zustellbarkeit schaden. Der minimale tragfähige Zeitrahmen ist vier Wochen; acht sind sicherer für Organisationen mit vielen sendenden Plattformen.

• Woche 1-2: Monitor (p=none) — Veröffentliche p=none mit rua=-Reporting. Sammle Aggregate-Reports, identifiziere jeden legitimen Sender und schließe SPF/DKIM-Lücken. Rechne damit, mindestens einen Schatten-ESP zu entdecken, von dem die IT nichts wusste.
• Woche 3-4: Quarantine pct=25 — Wechsle zu p=quarantine; pct=25. Ein Viertel der nicht authentifizierten Mail landet jetzt in Spam. Beobachte Reports täglich auf unerwartete Einbrüche bei legitimer Mail. Bricht ein Sender weg, rolle zurück zu p=none, repariere, versuche es erneut.
• Woche 5-6: Quarantine pct=100 — Erhöhe auf p=quarantine; pct=100. Alle fehlschlagende Mail geht in Spam. Zu diesem Zeitpunkt sollten deine Reports 99%+ Pass-Raten von bekannten Sendern zeigen. Gespoofte Mail, die deine Domain versucht, ist jetzt im Empfänger-Postfach neutralisiert.
• Woche 7-8: Reject — Wechsle zu p=reject; pct=100. Fehlschlagende Mail wird in der SMTP-Transaktion abgewiesen — kommt nie beim Empfänger an. Das ist der Zielzustand. Lass das Reporting (rua=) eingeschaltet, damit du Regressionen siehst, wenn ein neuer ESP hinzukommt.

Gmail- und Yahoo-Anforderungen 2026

Wenn du mehr als 5.000 Nachrichten pro Tag an Gmail- oder Yahoo-Adressen schickst, ist DMARC Pflicht. Der minimal akzeptable Record ist p=none — aber Googles eigene Empfehlung lautet inzwischen p=quarantine oder strenger. Ohne gültigen DMARC-Record sehen Bulk-Sender Nachrichten mit 5.7.26 'unauthenticated email is not accepted' bouncen oder direkt im Spam landen, unabhängig vom Inhalt. Die anderen 2026er-Anforderungen kommen obendrauf: One-Click-Unsubscribe in den Headern, Spam-Beschwerderaten unter 0,3% und TLS für SMTP. DMARC ist davon das günstigste — typischerweise ein einziger TXT-Record und 30 Minuten Arbeit — und es ist der größte Hebel für die Zustellbarkeit transaktionaler und Marketing-Mail.