DMARC subdomain policy sp=
dmarc sp tag · subdomain dmarc policy · sp=reject
When sp= matters for mail.example.com, how it inherits from p=, and why separate subdomain senders need explicit alignment.
Von DN01 Network Team
The sp= tag defines policy for organizational subdomains when their From addresses use a subdomain of the DMARC domain. Der DN01 DMARC-Analyzer holt den _dmarc-TXT, parst Tags und hebt Policy sowie Alignment vor Enforcement hervor. Operatoren nutzen ihn bei Migrationen, Incident-Triage und Vendor-Onboarding, wenn wiederholbare Belege statt Einzelscreenshots gebraucht werden.
Marketing platforms, support desks, and product mailers often send from subdomains that never inherit the parent policy you thought covered them.
Check sp= in DN01 output alongside p=, list every active subdomain sender, and publish aligned SPF or DKIM for each before tightening enforcement. Kombinieren Sie DMARC-Ausgabe mit SPF- und DKIM-Validatoren derselben Domain für gemeinsame Auth-Fixes. Speichern Sie den Ergebnis-Permalink im Ticket, notieren Sie den Prüfzeitpunkt und vergleichen Sie die Ausgabe vor und nach Konfigurationsänderungen oder Client-Updates.
Wiederholen Sie die Prüfung nach jeder wesentlichen Änderung und bewahren Sie den Guide-Link im Team-Runbook, damit neue Operatoren dieselbe Diagnose-Reihenfolge einhalten.
Tags, die DN01 hervorhebt
Policy p= und Subdomain sp= definieren Empfängeraktionen; pct= begrenzt den Mail-Anteil während des Rollouts.
Alignment-Modi aspf und adkim steuern relaxed oder strict Matching zwischen authentifizierten Domains und sichtbarem From-Header.
Rollout-Fehler
Reject veröffentlichen, während Marketing oder Ticketing mit Vendor-DKIM senden, bricht legitime Mail in Spam-Ordnern.
Aggregate Reports ignorieren bedeutet, misaligned Quellen erst nach Beschwerden über fehlende Belege zu entdecken.
Sicherer Enforcement-Pfad
Starten Sie mit p=none und rua, fixen Sie Alignment für jeden genehmigten Sender, dann quarantine vor reject.
Nutzen Sie pct<100 nur als temporäre Brücke; dokumentieren Sie das Zieldatum für vollständiges Enforcement im Mail-Runbook.
Dokumentation und nächste Schritte
Archivieren Sie Checker-Ausgaben in Change-Tickets, Vendor-Reviews und Incident-Records, damit der nächste Operator dieselben geparsten Belege sieht.
Verlinken Sie diesen Leitfaden und die Tool-Landingpage in Team-Wikis und kombinieren Sie Ergebnisse mit anderen DN01-Diensten, wenn DNS, Mail, TLS oder Security betroffen sind. Notieren Sie Prüfer, verwendete Eingabe und ob der Ergebnis-Permalink mit dem Anfragenden geteilt wurde.
Wann eskalieren oder Checks kombinieren
Wenn die Ausgabe von DMARC-Analyzer nach Neustart oder Cache-Leerung weiter vom Nutzerbericht abweicht, erfassen Sie Zeitstempel, Roheingaben und den DN01-Permalink, bevor Sie Production-DNS, Mail, TLS oder Auth ändern.
Eskalieren Sie an Plattform- oder Identity-Owner, wenn Enterprise-Policy den Fix blockiert; andernfalls kombinieren Sie diesen Leitfaden mit angrenzenden DN01-DNS-, Mail-, TLS- oder Security-Tools, um den Loop in einem Ticket zu schließen.
| Policy | Typische Nutzung |
|---|---|
| p=none | Monitoring und rua sammeln |
| p=quarantine | Fehler in Spam abmildern |
| p=reject | Spoof blocken nach sauberem Alignment |
| pct<100 | Nur schrittweises Enforcement |
Häufig gestellte Fragen
- Ersetzt DMARC SPF oder DKIM?
Nein. DMARC hängt von SPF und DKIM plus Alignment mit der From-Domain ab.
- Soll jede Domain p=reject nutzen?
Viele sendende Domains sollten es, aber erst nach Reports mit aligned legitimer Mail ohne Überraschungsquellen.
- Warum pct separat zeigen?
reject mit pct=20 ist kein volles Enforcement. DN01 zeigt pct, damit Operatoren den Schutz nicht überschätzen.
- Kann ich Ergebnisse mit dem Team teilen?
Ja. Kopieren Sie die DN01-Ausgabe oder den Permalink in Tickets, damit alle dieselbe geparste Evidenz statt einzelner Screenshots sehen.