Domain hat keinen DMARC-Eintrag
Worum es geht
Ihre Domain hat keinen DNS-Eintrag _dmarc.example.cz vom Typ TXT. DMARC teilt den empfangenden E-Mail-Servern (Gmail, Seznam, Outlook) mit, was sie tun sollen, wenn sie eine Nachricht erhalten, die sich als von example.cz ausgibt, aber weder die SPF- noch die DKIM-Prüfung besteht.
Ohne DMARC lautet die Antwort „entscheiden Sie selbst“ — und große Provider stellen die gespoofte Nachricht in der Praxis zu.
Warum das ein Problem ist
Jeder kann eine E-Mail im Namen Ihrer Domain versenden. Konkret:
- Phishing von Mitarbeitenden. Ein Angreifer schickt von „reditel@example.cz“ eine Rechnung oder die Bitte um eine Überweisung. Ohne DMARC stellt Gmail (und andere) ihm diese Nachricht zu.
- Markenmissbrauch. Spam unter Ihrem Namen — und Gmail erkennt das zu spät, sodass die Reputation Ihrer E-Mail-Domain als Absender leidet.
- Zustellbarkeit. Gmail verlangt einen veröffentlichten DMARC-Eintrag von Absendern mit mehr als 5.000 Nachrichten pro Tag an Gmail-Konten. Yahoo verlangt ihn von Bulk-Absendern und nennt bewusst keinen Mengen-Schwellenwert.
p=noneist die niedrigste Richtlinie, die beide akzeptieren — gar kein Eintrag genügt nicht.
Wie man es behebt
Rollen Sie DMARC in Phasen aus. Ein direkter Sprung auf eine erzwingende Richtlinie, bevor Sie Ihre Reports gelesen haben, schadet dem legitimen Mailing.
Phase 1 (1-2 Wochen) — Monitoring
Legen Sie einen DNS-TXT-Eintrag an:
Name: _dmarc.example.cz
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.cz; fo=1p=none drückt überhaupt keine Präferenz dazu aus, was Empfänger mit fehlschlagender Mail tun sollen (RFC 9989, Abschnitt 4.7) — jeder filtert weiterhin nach eigenem Ermessen. Worum dieser Eintrag tatsächlich bittet, sind die Reports: rua ist die E-Mail-Adresse, an die Provider Ihnen aggregierte Reports senden.
Phase 2 (nach 1-2 Wochen) — Quarantäne
Aus den Reports sehen Sie alle legitimen Server, die in Ihrem Namen versenden (Mailchimp, Mailgun, Microsoft 365, eigener Server). Ergänzen Sie sie in SPF und DKIM. Dann eskalieren Sie:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.czp=quarantine ist eine vollwertige erzwingende Richtlinie (RFC 9989, Abschnitt 3.2.9) — Mail, die DMARC nicht besteht, landet im Spam statt im Posteingang.
Fügen Sie hier kein pct=10 hinzu. Ältere Anleitungen nutzen pct=, um eine Richtlinie schrittweise über einen Prozentsatz der fehlschlagenden Mail hochzufahren. Das pct-Tag wurde jedoch mit RFC 9989 aus DMARC entfernt (Mai 2026), und ein konformer Empfänger ignoriert es. Bei jedem Empfänger, der auf RFC 9989 umgestellt hat, wird p=quarantine; pct=10 also auf 100 % der fehlschlagenden Mail angewendet, nicht auf 10 % — und ein pct=0 als „sicherer Test“ ist dort volles Enforcement. Da Sie nicht steuern, welche Empfänger bereits umgestellt haben, taugt pct überhaupt nicht mehr für einen stufenweisen Rollout.
Für einen Testlauf definiert RFC 9989 in Abschnitt 4.7 stattdessen das t=-Tag. Bei einem Empfänger, der auf RFC 9989 umgestellt hat, bittet t=y um eine Stufe unter der veröffentlichten Richtlinie, während die Reports weiterlaufen: p=quarantine; t=y wird dort wie p=none behandelt, p=reject; t=y wie p=quarantine.
t= und pct sind aber nicht dasselbe: pct wurde aus dem Protokoll entfernt und wird von Empfängern, die RFC 9989 folgen, ignoriert, während t= sein gültiger Ersatz ist — er wirkt allerdings nur bei Empfängern, die auf RFC 9989 umgestellt haben. Das Tag ist neu in RFC 9989 (Anhang A.6), und Abschnitt 4.8 verlangt von einem Empfänger, ihm unbekannte Tags zu ignorieren: wer nicht auf RFC 9989 umgestellt hat, wendet Ihre veröffentlichte Richtlinie vollständig an — bei p=quarantine; t=y landet dort alles in der Quarantäne, was DMARC nicht besteht. Veröffentlichen Sie t= deshalb nur zu einer Richtlinie, deren volle Wirkung Sie tragen können; die einzige Phase, die nirgends etwas erzwingt, bleibt p=none. Entfernen Sie das Tag (oder setzen Sie t=n), wenn der Test abgeschlossen ist.
Phase 3 (optional) — reject
v=DMARC1; p=reject; rua=mailto:dmarc@example.czBei p=reject weist der Empfänger die gespoofte Nachricht direkt ab. RFC 9989 Abschnitt 7.4 knüpft daran zwei Bedingungen: Eine Domain, die p=reject veröffentlicht, muss ihre Mail mit gültigem DKIM signieren und darf sich nicht allein auf SPF verlassen (SPF bricht beim Weiterleiten), und Domains, die Nutzer beherbergen, die auf Internet-Mailinglisten schreiben könnten, sollten p=reject gar nicht erst veröffentlichen.
Trifft eine der beiden Bedingungen auf Sie zu, ist ein Verbleib bei p=quarantine ein legitimer Endzustand und kein unfertiges Rollout.
Überprüfung
Überprüfen Sie den Eintrag nach jeder Phase mit einem neuen Scan auf vulscan.app — die DMARC-Prüfung (zusammen mit SPF) ist Teil des kostenlosen Scans. Die aggregierten Reports kommen als XML-Anhänge an der rua-Adresse an; zur ersten Orientierung genügt es zu beobachten, welche Server Mail versenden, die DMARC nicht besteht.
Referenzen
- Vulscan-Doku: SPF
- RFC 9989 — DMARC (löst RFC 7489 ab)
- Google: Email sender guidelines — die Gmail-Anforderung oben
- Yahoo Sender Hub: best practices — die Yahoo-Anforderung oben