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.
Par DN01 Network Team
The sp= tag defines policy for organizational subdomains when their From addresses use a subdomain of the DMARC domain. L'analyseur DMARC DN01 récupère le TXT _dmarc, analyse les tags et met en évidence politique et alignement avant l'enforcement. Les opérateurs l'utilisent lors de migrations, triage d'incidents et onboarding fournisseurs quand ils ont besoin de preuves reproductibles plutôt que de captures isolées.
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. Combinez la sortie DMARC avec les validateurs SPF et DKIM du même domaine pour corriger l'authentification ensemble. Enregistrez le permalink du résultat dans le ticket, notez l'heure du contrôle et comparez la sortie avant et après changements de configuration ou mises à jour client.
Répétez le contrôle après chaque changement important et conservez le lien du guide dans le runbook d'équipe pour que les nouveaux opérateurs suivent le même ordre de diagnostic.
Tags mis en avant par DN01
La politique p= et le sous-domaine sp= définissent les actions des destinataires; pct= limite la part de courrier couverte pendant le déploiement.
Les modes aspf et adkim contrôlent l'alignement relaxed ou strict entre domaines authentifiés et l'en-tête From visible.
Erreurs de déploiement
Publier reject alors que marketing ou ticketing envoient avec DKIM fournisseur casse le courrier légitime en spam.
Ignorer les rapports agrégés fait découvrir les sources non alignées seulement après plaintes sur reçus manquants.
Chemin d'enforcement sûr
Commencez à p=none avec rua, corrigez l'alignement pour chaque expéditeur approuvé, puis quarantine avant reject.
Utilisez pct<100 seulement comme pont temporaire; documentez la date cible d'enforcement complet dans le runbook mail.
Documentation et prochaines étapes
Archivez la sortie du vérificateur dans les tickets de changement, revues fournisseurs et incidents afin que le prochain opérateur voie la même preuve analysée.
Liez ce guide et la page outil dans les wikis d'équipe, puis associez les résultats aux autres utilitaires DN01 quand le problème touche DNS, mail, TLS ou sécurité. Indiquez qui a lancé le contrôle, quelle entrée a été utilisée et si le permalink a été partagé avec le demandeur.
Quand escalader ou combiner les contrôles
Si la sortie de Analyseur DMARC contredit encore l'utilisateur après redémarrage ou vidage du cache, capturez horodatages, entrées brutes et permalink DN01 avant de modifier DNS, mail, TLS ou auth de production.
Escaladez vers les responsables plateforme ou identité quand la politique entreprise bloque le correctif ; sinon associez ce guide aux utilitaires DN01 DNS, mail, TLS ou sécurité pour boucler le ticket.
| Politique | Usage typique |
|---|---|
| p=none | Surveiller et collecter rua |
| p=quarantine | Adoucir les échecs vers spam |
| p=reject | Bloquer le spoof après alignement propre |
| pct<100 | Enforcement graduel seulement |
Questions fréquentes
- DMARC remplace-t-il SPF ou DKIM?
Non. DMARC dépend de SPF et DKIM plus l'alignement avec le domaine From.
- Chaque domaine doit-il utiliser p=reject?
Beaucoup devraient, mais seulement après des rapports montrant un courrier légitime aligné sans sources surprises.
- Pourquoi afficher pct séparément?
reject avec pct=20 n'est pas un enforcement complet. DN01 affiche pct pour éviter de surestimer la protection.
- Puis-je partager les résultats avec l'équipe ?
Oui. Copiez la sortie DN01 ou le permalink dans les tickets de changement pour que chacun examine la même preuve analysée plutôt que des captures isolées.