When a well-known professional services firm noticed a sudden spike in lookalike emails and invoice fraud attempts, they faced a familiar dilemma: how do you protect busy employees and clients from convincing email impersonation without slowing the business to a crawl? This case study walks through how the team systematically implemented SPF, DKIM, and DMARC to cut phishing by 82% in six months\u2014while improving deliverability and preserving a seamless experience for legitimate senders.<\/p>\n
The organization in this case is a mid-sized professional services firm with about 2,000 employees and multiple client-facing brands. Over one quarter, the security team recorded a 3x increase in spoofed messages claiming to be from executives, HR, and billing.<\/p>\n
Their existing email security gateway blocked many malicious messages, but attackers were increasingly abusing lookalike domains and forwarding paths, slipping past filters. The team needed a domain-level control that told receiving mail systems which messages were legitimately from them\u2014and which were not.<\/p>\n
Enter SPF, DKIM, and DMARC: a trio of open standards that authenticate sending sources, verify message integrity, and give domain owners a policy-based say in what happens to impostors.<\/p>\n
Before making any changes, the team defined success and captured a baseline. They looked at:<\/p>\n
They set three practical objectives for a six-month program:<\/p>\n
SPF (Sender Policy Framework) tells receiving mail servers which IPs and services are allowed to send mail for your domain. Think of it as an approved sender list published in DNS.<\/p>\n
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. Receiving servers use a public key in your DNS to verify that the message wasn\u0019t altered and truly came from an authorized sender.<\/p>\n
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties it all together. It requires messages to pass SPF or DKIM and<\/em> align with the visible From domain. Then it lets domain owners specify a policy: do nothing (none), send to spam (quarantine), or reject. DMARC also provides reporting so you can see who\u0019s sending on your behalf and how many messages pass or fail.<\/p>\n In short: SPF = who can send, DKIM = message integrity, DMARC = enforce and report. These standards don\u0019t replace secure email gateways or awareness training, but they powerfully reduce domain spoofing.<\/p>\n The firm set up a small cross-functional working group:<\/p>\n They planned three phases across six months:<\/p>\n With DMARC reporting (RUA aggregate reports) enabled on day one, the team quickly identified all sources claiming to send from the domain, including forgotten tools used by departments. They also asked stakeholders to list any system that sends email externally.<\/p>\n The team published a single SPF record at the root domain, carefully including each authorized service. They avoided common pitfalls:<\/p>\n For subdomains used by specific tools (e.g., mail.brand.example.com<\/em>), they created dedicated SPF records where appropriate and sometimes delegated sending to vendor-owned domains to simplify alignment.<\/p>\n Next, they enabled DKIM on the corporate mail system and each third-party platform. Key practices included:<\/p>\n They published DMARC at DMARC requires SPF or DKIM pass and<\/em> alignment with the From domain. The biggest fixes involved:<\/p>\n With authentication stable, they moved to Several issues surfaced during rollout, each with a practical resolution:<\/p>\nProject Plan, Roles, and Timeline<\/h2>\n
\n
\n
Step-by-Step Implementation<\/h2>\n
1) Inventory every legitimate sender<\/h3>\n
\n
2) Configure SPF correctly<\/h3>\n
\n
include:<\/code> for vendor-maintained records rather than raw IPs.<\/li>\n-all<\/code> to explicitly fail non-authorized sources.<\/li>\n<\/ul>\n3) Enable DKIM signing<\/h3>\n
\n
4) Turn on DMARC with monitoring<\/h3>\n
p=none<\/code> with RUA reporting to a vendor mailbox for analysis. This produced daily summaries of pass\/fail rates by source, letting the team fix issues before blocking anything.<\/p>\n\n
v=DMARC1; p=none; rua=mailto:dmarc-reports@vendor.example;<\/code><\/li>\nrelaxed<\/code> alignment (adkim=r; aspf=r<\/code>), tightening later where feasible.<\/li>\n<\/ul>\n5) Fix alignment gaps<\/h3>\n
\n
6) Enforce gradually<\/h3>\n
p=quarantine<\/code> at 25%, then 50%, then 100% over four weeks. After two more weeks of monitoring, they switched to p=reject<\/code> with pct=50<\/code>, then 100%.<\/p>\n\n
p=none<\/code> temporarily while vendors completed DKIM setup.<\/li>\n<\/ul>\n7) Optional enhancements<\/h3>\n
\n
Technical Hurdles and Fixes<\/h2>\n
\n
include:<\/code> statements.<\/li>\ninclude:<\/code> chains risked exceeding 10 DNS lookups. They pruned unused vendors and used vendor \u001cmacro\u001d includes where offered.<\/li>\n