Subdomain-Übernahme-Versuche umgehen heute häufig die E-Mail-Authentifizierung, weil Organisationen davon ausgehen, dass die DMARC-Policy-Vererbung automatisch funktioniert. Das tut sie nicht. Wenn eine Subdomain keinen expliziten DMARC-Eintrag hat, erbt die Subdomain die Policy der Organisationsdomain – aber nur, wenn die Policy der Organisationsdomain existiert und korrekt konfiguriert ist. Schlägt die Vererbung fehl, können Angreifer unauthentifizierte E-Mails von marketing.example.com, support.example.com oder jeder anderen nicht beanspruchten Subdomain senden, selbst wenn example.com DMARC mit p=reject durchsetzt.
Die Subdomain-DMARC-Vererbung erzeugt drei Fehlerbedingungen, die Sicherheitsteams häufig übersehen: (1) Die Policy der Organisationsdomain existiert, ist aber falsch konfiguriert, sodass Subdomains eine schwächere Policy erben als beabsichtigt, (2) die Subdomain sendet E-Mails über einen Drittanbieter-Service, der nicht mit der Authentifizierung der Organisationsdomain übereinstimmt, sodass die geerbte Policy bei Alignment-Prüfungen fehlschlägt, oder (3) die Subdomain ist im DNS registriert, wird aber nicht aktiv verwaltet, was eine ausnutzbare Lücke schafft, in der Angreifer die Subdomain durch Hosting- oder DNS-Provider-Schwachstellen übernehmen und E-Mails versenden können, bevor sie entdeckt werden.
KI-gestützte Phishing-Kampagnen scannen diese Lücken nun mittels automatisierter DNS-Enumeration und Policy-Validierung. Wenn eine Subdomain NXDOMAIN oder einen null DMARC-Eintrag zurückgibt, testet der Angreifer, ob gefälschte E-Mails von dieser Subdomain DMARC bestehen. Falls ja, wird die Subdomain zu einem dauerhaften Phishing-Vektor.
Dieser Leitfaden erklärt, wie die Subdomain-DMARC-Vererbung tatsächlich funktioniert, wo die Vererbung stillschweigend fehlschlägt und wie Sie eine Durchsetzung konfigurieren, die ausnutzbare Lücken schließt, bevor Angreifer sie finden.
I. Wie die DMARC-Policy-Vererbung funktioniert (und wo sie fehlschlägt)

Wenn ein empfangender Mail-Server DMARC für [email protected] evaluiert, fragt er DNS nach einem DMARC-Eintrag bei _dmarc.marketing.example.com ab. Wenn kein Eintrag existiert, fragt der Server _dmarc.example.com ab. Wenn ein Eintrag bei der Organisationsdomain existiert, erbt die Subdomain die in diesem Eintrag definierte Policy.
Dieser Vererbungsmechanismus funktioniert korrekt, wenn:
- Die Organisationsdomain (
example.com) einen DMARC-Eintrag veröffentlicht - Die Subdomain (
marketing.example.com) keinen DMARC-Eintrag veröffentlicht - Die Subdomain E-Mails sendet, die mit der SPF- oder DKIM-Konfiguration der Organisationsdomain übereinstimmen
Die Vererbung schlägt fehl, wenn:
- Der DMARC-Eintrag der Organisationsdomain Syntaxfehler enthält, sodass der Eintrag ignoriert wird und die Subdomain effektiv keine Policy erbt
- Die Subdomain E-Mails über einen Drittanbieter-Service sendet, der seine eigene Envelope-Sender-Domain verwendet, was die SPF-Übereinstimmung unterbricht
- Der Drittanbieter-Service nicht mit einem DKIM-Selektor unter der Organisationsdomain signiert, was die DKIM-Übereinstimmung unterbricht
- Die Subdomain im DNS registriert, aber nicht aktiv verwaltet wird, sodass Angreifer sie durch Hosting-Provider-Kontowiederherstellung, DNS-Provider-Schwachstellen oder abgelaufene Domain-Registrierung übernehmen können
Wenn die Vererbung fehlschlägt, schlägt die Subdomain-E-Mail entweder stillschweigend bei DMARC fehl (wenn die Organisationspolicy p=none oder p=quarantine ist) oder schlägt sichtbar bei DMARC fehl, erreicht aber dennoch den Posteingang (wenn der empfangende Server die Durchsetzung nicht befolgt oder Reputations-Überschreibungen anwendet).
II. Häufige Subdomain-DMARC-Fehlerszenarien

Szenario 1: Policy der Organisationsdomain existiert, aber Subdomain-Authentifizierung stimmt nicht überein
Aufbau:
example.comveröffentlichtv=DMARC1; p=reject; aspf=s; adkim=smarketing.example.comsendet E-Mails über Mailchimp- Mailchimp-Envelope-Sender:
[email protected] - Mailchimp-DKIM-Signatur:
d=mcdlv.net
Was passiert:
- DMARC fragt
_dmarc.marketing.example.comab → kein Eintrag - DMARC fragt
_dmarc.example.comab → findetp=reject; aspf=s; adkim=s - SPF evaluiert
[email protected]→ besteht SPF fürmcdlv.net, nicht fürmarketing.example.com - DKIM evaluiert Signatur mit
d=mcdlv.net→ besteht DKIM fürmcdlv.net, nicht fürmarketing.example.com - DMARC-Alignment-Prüfung schlägt fehl, weil weder SPF noch DKIM mit
marketing.example.comim Strict-Modus übereinstimmen - Ergebnis: Die geerbte Policy weist Empfänger an, die Nachricht abzulehnen, aber da die Policy geerbt und nicht explizit für die Subdomain gesetzt wurde, wenden einige Empfänger möglicherweise lockerere Durchsetzung an
Lösung:
Veröffentlichen Sie einen expliziten DMARC-Eintrag bei _dmarc.marketing.example.com:
v=DMARC1; p=none; rua=mailto:[email protected]; sp=rejectKonfigurieren Sie dann Mailchimp so, dass mit d=marketing.example.com oder d=example.com DKIM-signiert wird, damit die DKIM-Übereinstimmung im Relaxed-Modus bestanden wird.
Alternativ verwenden Sie aspf=r; adkim=r bei der Organisationsdomain, um Relaxed Alignment für Subdomains zu erlauben.
Szenario 2: Subdomain im DNS registriert, aber nicht aktiv verwaltet
Aufbau:
example.comveröffentlichtv=DMARC1; p=rejectdev.example.comexistiert im DNS, sendet aber keine E-Mails mehr und hostet keine Services mehr- Angreifer entdeckt
dev.example.comdurch DNS-Enumeration - Angreifer übernimmt
dev.example.comdurch Hosting-Provider-Kontowiederherstellung, DNS-Provider-Schwachstelle oder Domain-Ablauf
Was passiert:
- Angreifer konfiguriert Mail-Infrastruktur bei
dev.example.com - Angreifer sendet Phishing-E-Mails von
[email protected] - DMARC fragt
_dmarc.dev.example.comab → kein Eintrag - DMARC fragt
_dmarc.example.comab → findetp=reject - Vom Angreifer kontrollierte Mail-Infrastruktur verwendet vom Angreifer kontrollierte SPF und DKIM, die beide mit
dev.example.comim Relaxed-Alignment-Modus übereinstimmen - DMARC besteht, weil der Angreifer die Subdomain kontrolliert und konforme Authentifizierung konfigurieren kann
- E-Mail erreicht Posteingang trotz Durchsetzung der Organisationsdomain
Lösung:
Veröffentlichen Sie explizit p=reject bei _dmarc.dev.example.com:
v=DMARC1; p=reject; rua=mailto:[email protected]Entfernen Sie DNS-Einträge für inaktive Subdomains. Wenn die Subdomain registriert bleiben muss, veröffentlichen Sie einen null-MX-Eintrag, um zu signalisieren, dass die Subdomain keine E-Mails sendet oder empfängt:
dev.example.com. IN MX 0 .Überwachen Sie DMARC-Reports auf unerwartete Authentifizierung von Subdomains.
Szenario 3: Syntaxfehler in der Policy der Organisationsdomain unterbricht Vererbung
Aufbau:
example.comveröffentlicht:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=50newsletter.example.comsendet E-Mails- Kein expliziter DMARC-Eintrag existiert für
newsletter.example.com
Was passiert:
- DMARC fragt
_dmarc.newsletter.example.comab → kein Eintrag - DMARC fragt
_dmarc.example.comab → findet Eintrag mitpct=50 - Viele moderne DMARC-Implementierungen ignorieren
pct=oder behandeln prozentuale Durchsetzung inkonsistent - Subdomain erbt eine Policy, die möglicherweise nicht vorhersehbar durchgesetzt wird
- Angreifer senden gefälschte E-Mails von
newsletter.example.comund beobachten, ob Durchsetzung angewendet wird
Lösung:
Entfernen Sie pct= aus der Policy der Organisationsdomain:
v=DMARC1; p=reject; rua=mailto:[email protected]Stufen Sie die Durchsetzung nach Subdomain oder Absendergruppe, nicht nach Prozentsatz.
III. Explizite Subdomain-Policy-Konfigurationsmuster

Muster 1: Policy der Organisationsdomain erben (Standardverhalten)
Eintrag der Organisationsdomain:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Subdomain-Verhalten:
marketing.example.comerbtp=rejectsupport.example.comerbtp=reject- Alle Subdomains erben
p=reject, es sei denn, es existiert ein expliziter Eintrag
Wann zu verwenden:
- Sie kontrollieren alle Subdomains
- Alle Subdomains senden E-Mails über Infrastruktur, die mit SPF oder DKIM der Organisationsdomain übereinstimmt
Muster 2: Geerbte Policy für bestimmte Subdomains überschreiben
Eintrag der Organisationsdomain:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Subdomain-Überschreibung:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Ergebnis:
marketing.example.comverwendetp=none- Alle anderen Subdomains erben
p=reject
Wann zu verwenden:
- Eine bestimmte Subdomain sendet E-Mails über Drittanbieter-Services, die noch nicht mit der Authentifizierung der Organisationsdomain übereinstimmen können
- Sie benötigen Transparenz über Authentifizierungsergebnisse, bevor Sie die Policy auf der Subdomain durchsetzen
Muster 3: Subdomain-Policy auf Ebene der Organisationsdomain setzen
Eintrag der Organisationsdomain:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"Ergebnis:
example.comverwendetp=reject- Alle Subdomains erben
p=quarantine(definiert durchsp=)
Wann zu verwenden:
- Sie möchten unterschiedliche Durchsetzung für Organisationsdomain vs. Subdomains
- Subdomains senden E-Mails mit geringerem Volumen oder geringerem Risiko
Muster 4: Explizite Durchsetzung für jede Subdomain
Eintrag der Organisationsdomain:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Explizite Subdomain-Einträge:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.support.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_dmarc.newsletter.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Wann zu verwenden:
- Sie möchten maximale Transparenz und Kontrolle
- Sie möchten Unklarheiten darüber beseitigen, welche Policy gilt
- Sie möchten Subdomain-Übernahme-Versuche durch Reporting-Anomalien erkennen
IV. Interaktion von Alignment-Modus und Subdomain-Vererbung
Der DMARC-Alignment-Modus (aspf= für SPF, adkim= für DKIM) kontrolliert, ob Alignment eine exakte Domain-Übereinstimmung erfordert (Strict-Modus) oder Organisationsdomain-Übereinstimmung erlaubt (Relaxed-Modus).
Relaxed-Modus (aspf=r; adkim=r):
- SPF besteht, wenn Envelope-Sender-Domain
mail.example.comist und Header-From[email protected]ist - DKIM besteht, wenn DKIM-Signatur-Domain
mail.example.comist und Header-From[email protected]ist
Strict-Modus (aspf=s; adkim=s):
- SPF besteht nur, wenn Envelope-Sender-Domain exakt mit Header-From-Domain übereinstimmt
- DKIM besteht nur, wenn DKIM-Signatur-Domain exakt mit Header-From-Domain übereinstimmt
Interaktion mit Subdomain-Vererbung:
Wenn eine Subdomain eine Policy mit Strict-Alignment-Modus erbt, muss E-Mail von dieser Subdomain exakt übereinstimmen. Wenn die Subdomain über einen Drittanbieter-Service sendet, der seine eigene Domain für SPF oder DKIM verwendet, schlägt Strict-Alignment fehl.
Beispiel:
- Organisationsdomain:
v=DMARC1; p=reject; aspf=s; adkim=s - Subdomain:
marketing.example.comsendet über Mailchimp - Mailchimp verwendet
[email protected]für Envelope-Sender - Mailchimp DKIM-signiert mit
d=mcdlv.net - DMARC evaluiert Strict-Alignment: sowohl SPF als auch DKIM schlagen bei Alignment fehl
- Ergebnis: DMARC schlägt fehl, Policy weist Ablehnung an
Lösungsoptionen:
- Ändern Sie Policy der Organisationsdomain auf Relaxed-Modus:
aspf=r; adkim=r - Veröffentlichen Sie explizite Subdomain-Policy mit Relaxed-Modus:
v=DMARC1; p=reject; aspf=r; adkim=r - Konfigurieren Sie Mailchimp für DKIM-Signierung mit Organisationsdomain oder Subdomain-Selektor
V. Subdomain-Übernahme-Angriffsmuster und DMARC-Lücken
Subdomain-Übernahme tritt auf, wenn ein Angreifer die Kontrolle über eine Subdomain übernimmt, die eine Organisation registriert, aber nicht mehr aktiv verwaltet. Häufige Angriffsvektoren umfassen:
- Abgelaufenes DNS-Hosting: Subdomain-CNAME zeigt auf ein Hosting-Provider-Konto, das abgelaufen ist. Angreifer registriert neues Konto beim selben Provider und übernimmt die Subdomain.
- Hängender CNAME: Subdomain-CNAME zeigt auf einen Service (GitHub Pages, AWS S3, Heroku usw.), der nicht mehr existiert. Angreifer registriert den Service-Namen und stellt Inhalte von der Subdomain bereit.
- DNS-Provider-Konto-Kompromittierung: Angreifer erhält Zugang zum DNS-Provider-Konto durch Credential-Wiederverwendung, Phishing oder Provider-Schwachstelle. Angreifer ändert Subdomain-Einträge, um auf vom Angreifer kontrollierte Infrastruktur zu zeigen.
DMARC-Vererbung verhindert keine Subdomain-Übernahme. Wenn ein Angreifer die Subdomain-Infrastruktur kontrolliert, kann der Angreifer SPF und DKIM so konfigurieren, dass sie mit der Subdomain übereinstimmen, und besteht DMARC, selbst wenn die Organisationsdomain p=reject durchsetzt.
Erkennung und Prävention:
- Explizite Subdomain-Policies: Veröffentlichen Sie DMARC-Einträge bei jeder Subdomain, um Transparenz über Authentifizierungsaktivität zu erhalten.
- DNS-Überwachung: Überwachen Sie DNS-Einträge auf unerwartete Änderungen an Subdomain-A-, AAAA-, CNAME-, MX- oder TXT-Einträgen.
- DMARC-Reporting-Analyse: Überprüfen Sie DMARC-Reports auf Authentifizierung von Subdomains, die keine E-Mails senden sollten.
- Null-MX-Einträge: Veröffentlichen Sie null-MX für Subdomains, die keine E-Mails senden oder empfangen:
inactive.example.com. IN MX 0 .- Entfernen Sie ungenutzte DNS-Einträge: Löschen Sie A-, AAAA- und CNAME-Einträge für Subdomains, die keine Inhalte mehr bereitstellen oder E-Mails senden.
VI. Debugging geerbter DMARC-Policy-Fehler
Wenn eine Subdomain eine DMARC-Policy erbt, aber E-Mails unerwartet die Durchsetzung nicht bestehen, befolgen Sie diesen Diagnoseprozess:
Schritt 1: Syntax der Policy der Organisationsdomain überprüfen
Fragen Sie den DMARC-Eintrag der Organisationsdomain ab:
dig TXT _dmarc.example.com +shortErwartete Ausgabe:
"v=DMARC1; p=reject; rua=mailto:[email protected]"Häufige Syntaxfehler, die Vererbung unterbrechen:
- Fehlendes
v=DMARC1 - Ungültiger
p=-Wert (mussnone,quarantineoderrejectsein) - Falsch formatierte
rua=-Adresse - Einschluss des veralteten
pct=-Tags
Wenn Syntaxfehler existieren, wird der Eintrag möglicherweise ignoriert, wodurch Subdomains effektiv keine Policy erben.
Schritt 2: Abwesenheit oder Vorhandensein des Subdomain-Eintrags überprüfen
Fragen Sie den DMARC-Eintrag der Subdomain ab:
dig TXT _dmarc.marketing.example.com +shortErwartete Ausgabe (bei Vererbung):
(keine Ausgabe)Erwartete Ausgabe (bei expliziter Überschreibung):
"v=DMARC1; p=none; rua=mailto:[email protected]"Wenn ein Eintrag bei der Subdomain existiert, erfolgt keine Vererbung. Die Subdomain verwendet ihre eigene Policy.
Schritt 3: SPF-Alignment überprüfen
Überprüfen Sie das SPF-Ergebnis und Alignment in DMARC-Reports oder E-Mail-Headern.
Häufiger SPF-Alignment-Fehler:
- Envelope-Sender-Domain:
[email protected] - Header-From-Domain:
[email protected] - SPF besteht für
mail.thirdpartyservice.com - SPF-Alignment schlägt fehl, weil Envelope-Sender-Domain nicht mit Header-From-Domain übereinstimmt
Lösung:
- Konfigurieren Sie Drittanbieter-Service zur Verwendung der Organisationsdomain oder Subdomain als Envelope-Sender
- Verwenden Sie Relaxed-Alignment-Modus auf Ebene der Organisationsdomain oder Subdomain
Schritt 4: DKIM-Alignment überprüfen
Überprüfen Sie die DKIM-Signatur-Domain in E-Mail-Headern:
DKIM-Signature: v=1; a=rsa-sha256; d=thirdpartyservice.com; s=selector; ...Wenn d=thirdpartyservice.com und Header-From [email protected] ist, schlägt DKIM-Alignment im Strict-Modus fehl.
Lösung:
- Konfigurieren Sie Drittanbieter-Service für DKIM-Signierung mit
d=marketing.example.comoderd=example.com - Verwenden Sie Relaxed-Alignment-Modus auf Ebene der Organisationsdomain oder Subdomain
Schritt 5: DMARC-Reports auf Subdomain-Aktivität überprüfen
DMARC-Aggregat-Reports enthalten Subdomain-Authentifizierungsergebnisse. Suchen Sie nach:
- Subdomains, die Sie nicht erkennen
- Hohen Fehlerraten von bekannten Subdomains
- Authentifizierung von IP-Adressen, die Sie nicht kontrollieren
Wenn eine Subdomain in Reports erscheint, Sie aber die Subdomain-Infrastruktur nicht kontrollieren, untersuchen Sie auf Subdomain-Übernahme.
Bei einem verwalteten Skysnag-Deployment verwenden Sie das von Skysnag generierte Reporting-Ziel. Das Folgende ist nur ein manuelles Beispiel:
v=DMARC1; p=none; rua=mailto:[email protected]Ein traditioneller statischer Eintrag kann funktionieren, aber nur, wenn Reports aktiv empfangen, geparst, analysiert und bearbeitet werden.
VII. Empfohlene Subdomain-DMARC-Konfigurationsstrategie
- Veröffentlichen Sie Policy der Organisationsdomain:
v=DMARC1; p=reject; rua=mailto:[email protected]; sp=quarantineDies setzt p=reject für die Organisationsdomain durch und standardmäßig p=quarantine für alle Subdomains.
- Veröffentlichen Sie explizite Policies für aktive Subdomains:
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
_dmarc.support.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Dies bietet Transparenz über Authentifizierungsaktivität und ermöglicht gestaffelte Durchsetzung pro Subdomain.
- Entfernen Sie DNS-Einträge für inaktive Subdomains.
- Veröffentlichen Sie null-MX für Subdomains, die keine E-Mails senden oder empfangen:
inactive.example.com. IN MX 0 .- Überwachen Sie DMARC-Reports auf unerwartete Subdomain-Aktivität.
Verwenden Sie Skysnag Protect, um legitime Absender zu identifizieren, nicht autorisierte Quellen zu erkennen und zur Durchsetzung überzugehen:
VIII. Wichtigste Erkenntnisse
Die DMARC-Vererbung von Subdomains funktioniert nur, wenn die Organisationsdomain einen gültigen DMARC-Eintrag veröffentlicht und die Subdomain keinen eigenen Eintrag publiziert. Die Vererbung schlägt fehl, wenn die Richtlinie der Organisationsdomain Syntaxfehler enthält, die Subdomain E-Mails über Drittanbieterdienste versendet, die nicht übereinstimmen, oder die Subdomain registriert, aber nicht aktiv verwaltet wird, wodurch Möglichkeiten zur Subdomain-Übernahme entstehen.
Veröffentlichen Sie explizite DMARC-Richtlinien für alle aktiven Subdomains, um Transparenz und Kontrolle zu erlangen. Entfernen Sie DNS-Einträge für inaktive Subdomains. Verwenden Sie Null-MX-Einträge für Subdomains, die keine E-Mails senden oder empfangen. Überwachen Sie DMARC-Berichte auf unerwartete Authentifizierungsaktivitäten von Subdomains.
Starten Sie das DMARC-Monitoring mit Skysnag und erhalten Sie Ihren kostenlosen DMARC-Eintrag: