Die undelegierte Subdomain-Falle: Warum p=reject allein nicht reicht

Zwei Wochen Spoofing trotz p=reject

In einem Reddit-Thread tauchte kürzlich ein Praxisbericht auf, der das pauschale „Setz einfach p=reject, dann bist du sicher” gehörig in Frage stellt. Eine Organisation hatte alles richtig gemacht: DMARC eingeführt, monatelang im Monitoring gefahren, dann auf p=reject umgestellt, sich gut gefühlt. Kein sp=-Tag im Record — schließlich sagt RFC 7489 eindeutig, dass die Subdomain-Policy von p= erbt, wenn sp= fehlt.

Was dann passierte: Ein Angreifer fand eine Subdomain, die nicht existierte. Sie war nirgends in DNS hinterlegt, niemand hatte sie jemals delegiert, sie tauchte in keinem Inventar auf. Trotzdem begann er, Mails mit Finanzthemen als billing.<kundendomain> zu verschicken. Manche Empfänger blockten korrekt. Andere stuften die fehlende DMARC-Antwort am Subdomain-Label nicht als „suche an der Org-Domain weiter”, sondern als „keine Policy hier, zustellen” ein. Die Mails kamen durch.

Das Spoofing lief zwei Wochen lang, bis ein Kunde eine Beispiel-Mail weiterleitete. Der Fix war im Nachhinein offensichtlich. Vorher war er es nicht.

Was die Spec sagt — und was Receiver wirklich tun

RFC 7489 ist auf dem Papier eindeutig. Wenn _dmarc.billing.example.com keine Antwort liefert, muss der Receiver in der DNS-Hierarchie nach oben laufen und die Policy von _dmarc.example.com anwenden. Dieses sogenannte „Tree Walking” stellt sicher, dass eine fehlende Subdomain-Policy zur Org-Policy zurückfällt. Wenn alle Receiver das täten, wäre sp= ein redundantes Tag.

Sie tun es aber nicht zuverlässig. Große Provider wie Google, Microsoft und Yahoo implementieren das Tree Walking weitgehend korrekt. Bei kleineren Mail-Diensten, Spam-Filter-Appliances und manchen On-Premise-Setups sieht die Realität anders aus: Es wird ein Exact-Lookup auf _dmarc.<vollständige-subdomain> gemacht, das Ergebnis NXDOMAIN gelesen, und daraus die Schlussfolgerung „keine Policy für dieses Label” gezogen. Manche Implementierungen wenden zusätzliche Heuristiken an, je nachdem, ob SPF oder DKIM zufällig vorhanden sind.

Genau diese Inkonsistenz ist der Grund, warum die kommende DMARCbis-Spezifikation einen strengeren Tree-Walk-Algorithmus mitbringt — und das neue Tag np= für nicht-existente Subdomains explizit als eigene Direktive einführt. Dass der heutige Zustand uneindeutig ist, sieht die zuständige IETF-Arbeitsgruppe selbst so.

Der „Wildcard-DMARC”-Trick — und warum er nicht funktioniert

In genau solchen Threads taucht regelmäßig ein vermeintlicher Königsweg auf: „Publiziere einfach einen TXT-Record an *._dmarc.<deinedomain> mit demselben Inhalt wie dein Org-Record — dann findet jeder Receiver eine Antwort, egal welches Label sich der Angreifer ausdenkt.”

Das klingt elegant. Es funktioniert aber nicht — aus einem schlichten DNS-Grund. Ein Wildcard greift genau auf der Label-Ebene, auf der das * steht. *._dmarc.example.com synthetisiert Antworten für Namen der Form <irgendwas>._dmarc.example.com. Der Lookup, den ein Receiver für eine Mail von billing.example.com tatsächlich durchführt, ist aber _dmarc.billing.example.com — hier steht _dmarc links, nicht rechts. Diese beiden Namen passen nicht aufeinander: Der Wildcard *._dmarc.example.com deckt _dmarc.billing.example.com schlicht nicht ab. Der Receiver bekommt weiterhin NXDOMAIN.

Schlimmer noch: Die Probe, mit der man so einen Wildcard zu verifizieren glaubt — dig TXT _dmarc.<zufallsstring>.<deinedomain> —, fragt denselben nicht-abgedeckten Namen ab. Sie liefert NXDOMAIN, egal ob der Wildcard im Zonefile steht oder nicht. Der Record sieht aus, als täte er etwas, und tut nichts.

Und der „große” Wildcard *.<deinedomain>? Der würde eine Abfrage auf _dmarc.billing.example.com zwar technisch beantworten — aber nur, solange billing.example.com selbst gar nicht existiert (DNS-Wildcards greifen nicht, wenn dazwischen ein echter Knoten liegt; ausgerechnet deine bestehenden Subdomains wären also ausgenommen). Und er beantwortet dann jede TXT-Abfrage unter der Domain mit deinem DMARC-Record: ACME-Challenges, subdomain-spezifische SPF-Einträge, Verifizierungs-Tokens. Genau diese „Wildcard liefert Nicht-DMARC-Daten bzw. DMARC-Record an der falschen Stelle”-Konstellation ist laut dmarc.org mit weitem Abstand die häufigste Ursache kaputter DMARC-Records weltweit. Kein gangbarer Weg.

Kurz: Es gibt keinen DNS-Record, den du an deiner Org-Domain hinterlegen kannst, der einen Receiver, der gar nicht erst nach oben läuft, dazu zwingt, deine Policy auf ein erfundenes Label anzuwenden. Wenn der Receiver weder _dmarc.billing.example.com korrekt auflöst noch den Tree Walk macht, kann an einem Namen, der nie abgefragt wird, auch nichts stehen.

Was tatsächlich hilft

1. sp= bzw. das schon vorhandene p=reject. Ein Org-Record mit p=reject deckt Subdomains für jeden Receiver ab, der RFC 7489 korrekt umsetzt — der Tree Walk landet bei _dmarc.<deinedomain> und wendet p= an. Ein explizites sp=reject wird nur dann zu mehr als Kosmetik, wenn deine Org-Policy nicht reject ist (etwa p=quarantine; sp=reject). Steht ohnehin p=reject, ist sp=reject für konforme Receiver ein No-op — schadet aber nicht. Gegen Receiver, die das Subdomain-Lookup gar nicht machen, hilft beides nicht.

2. DMARCbis np=reject. Der strukturell sauberste Weg: ein eigener Tag für „non-existent subdomains” plus der überarbeitete, strengere Tree-Walk-Algorithmus, der die heutige Receiver-Divergenz beseitigt. Der Haken: DMARCbis liegt beim RFC Editor mit erwarteter Veröffentlichung in diesem Jahr, die Receiver-seitige Adoption ist aber noch dünn — bislang wurde im Wesentlichen nur bei United Internet (GMX, mail.com, WEB.DE) beobachtet, dass überhaupt DMARCbis-Format-Reports rausgehen. Bis Gmail, Microsoft 365, Yahoo und Co. den neuen Algorithmus ausliefern, ist np= mehr Zukunftssicherung als Enforcement. Setzen kostet nichts.

3. Bestehende Subdomains aufräumen. Für Subdomains, die es gibt, kannst du sehr wohl etwas tun: jeder aktiv sendenden Subdomain einen eigenen, korrekten _dmarc-Record geben (und nicht aus Versehen auf p=none lassen), und jeder nicht-sendenden Subdomain einen „Riegel” vorschieben — _dmarc.<sub> mit v=DMARC1; p=reject;, dazu v=spf1 -all und einen leeren DKIM-Eintrag. Das schützt deine bekannten Labels — gegen ein Label, das du nie hattest und nie inventarisieren wirst, bringt es nichts. Hygiene, kein Wundermittel.

Was du heute prüfen solltest

Check 1 — Org-Record: Steht an _dmarc.<deinedomain> p=reject? Wenn deine Org-Policy schwächer ist, ergänze mindestens sp=reject. Das schließt die Subdomain-Lücke für alle Receiver, die die Spec korrekt umsetzen.

Check 2 — np=: Ergänze np=reject. Heute überwiegend Dokumentation, aber kostenlos und der Standard-Pfad nach vorn, sobald DMARCbis-Receiver flächendeckend sind.

Check 3 — bestehende Subdomains: Geh die Subdomains durch, die wirklich existieren. Sendet eine davon Mail? Dann eigener, sauberer _dmarc-Record. Sendet sie keine? Dann p=reject + -all + leerer DKIM. Erfundene, undelegierte Labels lassen sich so nicht abdecken — das ist die Restlücke, und sie hängt am Verhalten des empfangenden Servers, nicht an deinem Zonefile.

Check 4 — Reports lesen: Deine Aggregate-Reports zeigen dir, welche (Sub-)Domain-Namen in deinem Namen tatsächlich auftauchen und wie die großen Receiver damit umgehen. Ein erfundenes billing.<deinedomain> in den Reports ist genau das Frühwarnsignal, das im Reddit-Fall zwei Wochen lang gefehlt hat — und der Grund, warum jemand wie wir hier mitliest.

Ein Nachwort

Die Standard-Empfehlung — „Geh auf p=reject, dann ist alles gut” — ist nicht falsch, nur unvollständig: Sie verlässt sich darauf, dass jeder Receiver die Spec gleich auslegt. Das tun sie nicht, und sie werden es absehbar erst tun, wenn DMARCbis breit angekommen ist.

Was du dagegen tun kannst, ist überschaubar und unspektakulär: p=reject halten, sp=/np= setzen, bestehende Subdomains sauber halten, Reports beobachten. Was du nicht tun solltest, ist dich auf einen Wildcard-Record verlassen, der das Problem laut Spec gar nicht adressieren kann — auch wenn er in Foren-Threads gern als der eine Trick verkauft wird. Die ehrliche Antwort ist hier leider unbequemer als die clevere.