DMARC Enforcement at a Retailer With a Rewriting CRM
Northwind Retail (northwind.example) has used DMARC p=none with rua reporting for 20 months. Marketing sends 60% of volume through a CRM that rewrites From to a bounce domain, then DKIM-signs with its own key; the CRM's SPF is not aligned. Stores send through an on-premises relay with SPF only. A recent spoofing campaign used promotions.northwind.example, which has no DMARC record, and 4,000 customers received fake clearance-sale mail. The security team proposes publishing p=reject at the organizational domain immediately. Last month's aggregate reports show 11% of legitimate mail failing both SPF and DKIM alignment, concentrated in the CRM and a new HR platform. The CIO wants enforcement before Black Friday, six weeks away, but the CRM vendor says alignment changes take one release cycle. No budget for a new gateway.
1. Explain why immediate p=reject at the organizational domain is unsafe here and lay out a sequenced path to enforcement.
Read the worked answer
Immediate p=reject is an outage risk: 11% of legitimate volume fails both alignment mechanisms, so rejecting would block roughly one in nine real messages, including CRM and HR mail.
Reasoning steps:
- Break the 11% down by source IP, header From domain, envelope From, and DKIM d=/selector. Distinguish misconfiguration (no aligned identifier) from unauthorized sources.
- Confirm whether the CRM rewrites the visible header From. If From stays northwind.example but DKIM signs d=crminc.example, DMARC fails even though the message authenticates. Fix with custom DKIM.
- Fix the HR platform similarly or scope a temporary gateway exception.
- Ramp: p=quarantine with pct=10, then 25/50/100 while monitoring rua/ruf and help-desk volume; only then move to p=reject.
- Keep temporary gateway allowlists for known-good sources, not a permanent DMARC override.
Enforcement before Black Friday is feasible only if the CRM and HR fixes land first; otherwise freeze at quarantine and publish sp=reject for subdomains that never send.
2. What DMARC record should protect promotions.northwind.example, and how does discovery treat a subdomain with no record?
Read the worked answer
DMARC discovery checks the exact host first (_dmarc.promotions.northwind.example), then falls back to the organizational domain (_dmarc.northwind.example). If the organizational record contains sp=, that subdomain policy applies; otherwise the organizational p= applies. Therefore p=reject at northwind.example would cover promotions by inheritance, but inheritance gives no separate reporting and no explicit intent.
Better: publish an organizational record such as v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected] for subdomains that never send mail, and a dedicated record at _dmarc.promotions.northwind.example if that subdomain has different needs. Confirm first that promotions does not legitimately send marketing or tracking mail, and check that the organizational domain is really northwind.example and not delegated elsewhere. Also remember pct applies to the selected policy, so a pct=50 record still lets half the spoofed mail through.
3. The CRM says it cannot make SPF align. What alignment mechanism should be used, and what exactly must change at the vendor and in DNS?
Read the worked answer
SPF alignment cannot be fixed by adding CRM IPs to the SPF record when the envelope/return-path domain is the vendor's bounce domain; SPF is evaluated on that envelope domain and must align with the header From. The durable fix is DKIM.
The vendor generates a selector key pair and signs with d=northwind.example and s=. Northwind publishes a CNAME at ._domainkey.northwind.example pointing to the vendor's DNS target. Under relaxed DKIM alignment, d=northwind.example matches the header From organizational domain, so DMARC passes even though the envelope is the vendor's domain.
Critical constraint: the vendor must not rewrite the visible header From to its own domain. If it does, the message is no longer northwind mail and DMARC at northwind cannot protect the brand. Rotate keys periodically, use 2048-bit keys, and keep the selector CNAMEs in place. Do not weaken DMARC to p=none just to accommodate the CRM.