Staged DMARC Enforcement With a Payroll Provider and Mailing Lists
Contoso Finance has published DMARC p=none for contoso.example for 14 months. Aggregate reports show 92% of its 1.8 million monthly messages pass DMARC, but four sources fail: (1) a payroll SaaS sends 120,000 messages per month using contoso.example in From, with SPF pass but no DKIM; (2) an internal application sends via an unauthenticated on-premises relay; (3) a partner mailing list re-sends Contoso marketing mail with the original From domain and breaks DKIM; (4) a subsidiary sends from a subdomain with its own SPF but no DKIM. The CISO wants p=reject in 30 days. Customer service depends on payroll notifications, and marketing says the mailing list has 60,000 subscribers. The subsidiary's IT team refuses to change its DNS. Contoso also sees 400 lookalike-domain phishing attempts per month. The security team proposes p=reject with pct=100 immediately.
1. Evaluate the CISO's 30-day p=reject plan. What would you change and why?
Read the worked answer
The 30-day p=reject plan is likely to break payroll and marketing. DMARC reject evaluates the From domain; a payroll SaaS that passes SPF with its own envelope domain but has no aligned DKIM will fail DMARC at p=reject even though the mail is legitimate. The same applies to the internal relay and the mailing list. A 14-month p=none history with 8% failing means roughly 144,000 messages per month would be rejected.
Changes:
- Do not go to p=reject until each known source has an aligned authentication path: payroll signs with a contoso.example DKIM key or sends from a subdomain with its own DMARC; the internal app gets a DKIM key and an authorized SPF IP; mailing-list traffic moves to a marketing subdomain or the list rewrites From.
- Use p=quarantine with a pct ramp (25, 50, 100) before reject, and monitor aggregate reports by source IP and header From.
- Apply a separate subdomain policy rather than forcing the subsidiary into the parent policy.
- Keep p=none on any subdomain that cannot be fixed, but isolate it so it cannot weaken the organizational domain.
2. How would you sequence enforcement across the main domain, subdomains, and mailing-list traffic?
Read the worked answer
Sequence:
- Fix authentication for revenue-critical sources first: payroll DKIM, internal relay SPF plus DKIM, and subsidiary DKIM. Validate with DMARC reports and message headers.
- Move marketing and mailing-list traffic to a dedicated subdomain such as news.contoso.example with its own SPF, DKIM, and DMARC record. Because DMARC alignment is relaxed by default, a subdomain can have its own policy without affecting the parent; if the mailing list rewrites From, the subdomain absorbs the failure.
- Enforce the parent domain in stages: p=quarantine pct=25, then 50, then 100; monitor false positives and use a temporary allowlist only for verified sources.
- Then move to p=reject. Set sp=reject for subdomains that are fully authenticated; leave the subsidiary at sp=quarantine until its IT team cooperates, and document the residual risk.
- Keep rua and ruf reporting and review weekly. Ramp only when a full week shows no unexplained failures.
The judgement is that DMARC enforcement is a sequencing problem, not a DNS switch.
3. What residual risk remains after p=reject, and what compensating controls address lookalike domains?
Read the worked answer
p=reject stops exact-domain spoofing but not lookalikes such as fabrikam-legal.com against fabrikam.com, display-name spoofing from freemail, or compromised legitimate accounts. Compensating controls include inbound impersonation protection for executive names and domains, external sender banners, blocking newly registered and lookalike domains at the edge, DMARC on all owned domains including parked ones, and registry or brand monitoring. You cannot publish DMARC for attacker-owned lookalike domains; you can detect and block them. Add user reporting and a payment-change verification process, because DMARC does nothing for a validly authenticated attacker domain with a deceptive display name.