Stand: Juli 2026

Zusammenfassung: Der optional eingesetzte Tag sp= in einem DMARC-Eintrag legt eine eigenständige Richtlinie ausschließlich für alle Subdomains fest. Er ermöglicht es, Subdomains strikt abzusichern oder bei Migrationen flexibler zu behandeln als die Hauptdomain.

Standardmäßig gilt bei DMARC (Domain-based Message Authentication, Reporting, and Conformance) das Prinzip der Vererbung: Wenn du einen DMARC-Record unter _dmarc.example.com veröffentlichst, gilt die im Tag p= definierte Richtlinie nicht nur für example.com, sondern automatisch auch für jede Subdomain wie mail.example.com oder shop.example.com.

In komplexen Infrastrukturen oder während einer schrittweisen Einführung benötigen Subdomains jedoch oft eine andere Behandlung als die Hauptdomain. Genau dafür existiert der Tag sp= (Subdomain Policy).

Funktionsweise laut RFC 7489

Der Tag sp= akzeptiert die gleichen Werte (none, quarantine, reject) wie der Haupt-Policy-Tag p=. Der entscheidende Unterschied ist sein Geltungsbereich: Er gilt ausschließlich für Subdomains und überschreibt dort die Hauptrichtlinie.

Laut RFC 7489 regelt die Spezifikation Folgendes: sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains.

Ein DMARC-Record mit abweichender Subdomain-Policy sieht wie folgt aus:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

In diesem Beispiel werden unautorisierte Nachrichten von der Hauptdomain (example.com) sofort abgelehnt (p=reject), während E-Mails von Subdomains im Zweifelsfall in die Quarantäne (sp=quarantine) beziehungsweise in den Spam-Ordner geleitet werden.

Praxis-Szenarien für den sp= Tag

Der Tag sp= wird vor allem in zwei typischen Situationen eingesetzt:

1. Subdomains absichern, während die Hauptdomain im Testmodus läuft

Viele Unternehmen benötigen Monate, um alle Absender für ihre Hauptdomain zu verifizieren. Solange example.com noch im Testmodus läuft (p=none), könnten Angreifer beliebige Subdomains (login.example.com, billing.example.com) für Phishing missbrauchen.

Indem du p=none; sp=reject setzt, schützt du sofort alle ungenutzten und nicht-versendenden Subdomains vor Spoofing, während du auf der Hauptdomain weiterhin ohne Risiko Analysedaten sammelst.

2. Weichere Policy für Subdomains bei Umstellungen

Wenn deine Hauptdomain bereits unter p=reject geschützt ist, du aber eine neue Tochtergesellschaft oder ein externes Newsletter-Tool auf einer Subdomain (news.example.com) anbindest, kann eine sofortige harte Ablehnung zu E-Mail-Verlusten führen. Mit sp=quarantine schaffst du einen Sicherheitspuffer für alle Subdomains, bis die Konfiguration der neuen Dienste vollständig verifiziert ist.

Konfiguration überprüfen

Um sicherzustellen, dass deine Hauptrichtlinie und deine Subdomain-Richtlinie korrekt greifen und keine Syntaxfehler im TXT-Record vorliegen, kannst du deine Konfiguration mit dem kostenlosen MXAudit-Scanner testen. Das Tool zeigt dir die genaue Vererbung für deine Subdomains an.

Weitere Praxis-Tipps zur Strukturierung von Sicherheitsrichtlinien findest du in der DMARC-Übersicht und in Schritt-für-Schritt-Anleitungen wie DMARC bei IONOS einrichten.