A Brussels-based financial services company with 2,400 employees received a compliance directive requiring DMARC p=reject on all corporate domains by end of Q2. Their security team had already set DMARC to p=none on the primary domain and understood the requirement. What they had not anticipated was the complexity of discovering every system that sent email as the corporate domain.
Initial DMARC aggregate report analysis revealed 14 distinct sending systems — 6 of which were completely unknown to the IT security team. These included: a third-party HR system sending offer letters, a legacy invoice system operated by a subsidiary, a customer satisfaction survey platform, and several smaller web applications.
Discovery processRather than moving directly to enforcement, the implementation began with a 30-day monitoring period at p=none, with aggregate report collection and analysis. Every source IP sending as the corporate domains was catalogued — including sources that were failing SPF alignment, failing DKIM alignment, or failing both.
Authentication remediation for all 14 systems was completed over 8 weeks. Systems that could not be configured for DKIM (two legacy applications scheduled for deprecation) were migrated to route through the primary MTA — allowing DKIM signing at the gateway level without application changes.
DMARC policy moved to p=quarantine at week 9 with ruf (failure report) sampling enabled. Failure reports confirmed only 0.2% of messages were failing alignment — all from a single external forwarding service used by two employees. After addressing the forwarding configuration, p=reject was applied at week 12. Zero legitimate messages were blocked.
Moving from DMARC p=none to p=reject in a large financial services environment is one of the highest-risk authentication changes an organization can undertake. At p=none, DMARC failures generate reports but do not affect delivery. At p=reject, DMARC failures cause messages to be rejected or silently dropped by receiving MTAs. Misconfigured sending paths that were invisible under p=none suddenly produce delivery failures affecting legitimate business communications.
The Belgian financial services firm managed 23 distinct sending domains — some customer-facing, some internal, some operated by third-party partners. The challenge was not configuring DMARC correctly on the primary sending infrastructure; it was identifying and correcting every sending path across all 23 domains before enforcement could be activated without causing collateral delivery failures.
Sending Path DiscoverySix weeks of DMARC aggregate report analysis (with rua= configured at p=none) revealed 47 distinct IP addresses sending as the company's domains. Of these, 23 were known and correctly configured. The remaining 24 were unknown or partially configured:
Internal monitoring tools, project management systems, and corporate applications were addressed first because they were the most straightforward to correct: configure SMTP relay through the main PowerMTA infrastructure (which already has DKIM signing for the corporate domain) rather than sending directly. This eliminated 6 IPs from the DMARC failure list without requiring any DNS changes.
Third-party vendors required either: configuring them to relay through the main infrastructure, publishing their sending IPs in the firm's SPF record (if they used SPF-based sending), or enabling DKIM signing with a subdomain-specific key. Each vendor had a different technical capability and different integration timeline. The claims processing vendor required 6 weeks to implement subdomain DKIM signing.
The acquired subsidiary operating on separate infrastructure required the most complex migration. Their PowerMTA environment was configured to sign with DKIM keys for the parent company's DMARC-covered domains, and their sending IPs were added to the consolidated SPF record. This required coordination between two separate IT teams and two separate DNS management systems.
With all sending paths identified and remediated, DMARC enforcement was activated progressively: p=quarantine at pct=5 for two weeks (5% of failing messages quarantined), pct=25 for two weeks, pct=50 for two weeks, pct=100 for two weeks, then p=reject at pct=100. Each stage was monitored via aggregate reports and PowerMTA accounting log for unexpected delivery failures.
| Stage | DMARC Policy | Duration | Monitoring Focus |
|---|---|---|---|
| Baseline | p=none | 6 weeks | Aggregate report collection; sending path discovery |
| Initial enforcement | p=quarantine; pct=5 | 2 weeks | Monitor for unexpected quarantine events |
| Ramp quarantine | p=quarantine; pct=100 | 4 weeks | Confirm no legitimate failures at 100% |
| Full enforcement | p=reject; pct=100 | Permanent | Ongoing monitoring; alert on any new failures |
DMARC enforcement reveals the complexity of large organizations' email sending practices. What appears to be a simple DNS change at p=reject is actually an audit of every system that sends as your domain — a project that typically uncovers sending paths that IT, marketing, and compliance teams did not know existed. This discovery phase is the most valuable part of the project.
— Cloud Server for Email Infrastructure TeamContact the technical team to discuss your specific situation. We assess each environment individually before recommending an architecture.
