Phishing via Dormant Mailchimp Accounts: How Offboarding Gaps Break DMARC Trust
The incident: a phishing email that passed every check
An IT security team reports a phishing email to the abuse desk. The response they get back: the message was fully authenticated. SPF: pass. DKIM: pass. DMARC: pass. No filter triggered, no gateway blocked it. The email came through Mailchimp, was cryptographically signed, and appeared to originate from a legitimate domain.
The catch: the Mailchimp account belonged to a former employee who had left the company months earlier. The account was never deactivated. Someone had taken it over — or the ex-employee had used it themselves — and sent a convincing phishing campaign that sailed through every technical control.
This case, discussed on Reddit in r/EmailSecurity, is not an isolated incident. It exposes a structural gap that exists in many organizations.
What DMARC does — and what it cannot do
DMARC is an authentication protocol. It verifies whether an email genuinely originates from an authorized mail server for the stated domain, combining SPF (which IP addresses are permitted to send?) and DKIM (is the message cryptographically signed?).
What DMARC cannot do: it does not check whether the account that sent the message is still permitted to do so. It cannot distinguish between an authorized marketing employee and a former colleague whose Mailchimp access was never revoked.
This is not a flaw in DMARC — it is a boundary of the protocol. Authentication and authorization are two different problems. DMARC solves the first one, not the second.
The real gap: offboarding without a sender inventory
Most organizations have an offboarding process for internal systems: disable the Active Directory account, collect the laptop, revoke VPN access. What routinely gets missed: external services that employees set up independently during their time at the company.
Mailchimp is a textbook example. A marketing employee creates an account, connects it to the company domain, configures SPF and DKIM — and when they leave, the account stays active. The DNS records still point to Mailchimp’s servers. DMARC still trusts that configuration.
The result: anyone with access to that Mailchimp account can send email on behalf of the company domain, and every recipient-side filter will treat those messages as legitimate.
This gap does not arise from technical failure. It arises from missing processes:
- No central inventory of all authorized email senders
- No offboarding step covering external marketing or communication tools
- No regular review of which services are currently SPF-authorized
How to close the gap
Build a sender inventory. Who is allowed to send email on behalf of your domain? That question should produce a complete, current list: ESPs like Mailchimp, HubSpot, or Brevo; transactional services like SendGrid or Postmark; internal mail servers. Every entry in your SPF record should map to a specific, actively used service.
Extend your offboarding checklist. When an employee leaves, ask: which external services did this person configure on behalf of the domain? Mailchimp accounts, HubSpot instances, Zapier connections — anything that can send email needs to be reviewed and, where appropriate, deactivated or transferred.
Audit SPF records regularly. An SPF record configured three years ago may contain entries for services that are no longer in use. Regular audits — at minimum quarterly — help identify and remove stale entries before they become attack surface.
Read your DMARC aggregate reports. DMARC aggregate reports show which sources are actually sending email on behalf of your domain. If an unfamiliar Mailchimp server appears in those reports, that is a warning sign. This is precisely what aggregate reports are designed for: making unknown or unexpected senders visible.
The blind spot between authentication and authorization
The Reddit case highlights a distinction that often gets blurred in practice: authentication means a message technically originates from an authorized sender. Authorization means that sender still has the right to send on behalf of your domain today.
A Mailchimp account correctly configured with SPF and DKIM passes authentication. Whether that account should still be permitted to send is an authorization question — and no technical protocol answers that automatically.
This means technical measures alone are not enough. Setting DMARC to p=reject is important and correct. But it does not protect against abuse by accounts that are technically authorized but organizationally no longer sanctioned.
The solution is a combination: technical control through DMARC, paired with organizational control through process and inventory management.
What this means for MSPs
For managed service providers handling multiple clients, this case is especially relevant. If a client employee leaves and a Mailchimp account configured against the client’s domain remains active, the risk sits with the client — but the responsibility for detecting it often falls on the MSP.
A structured sender inventory and an offboarding process that covers external services are not nice-to-haves. They are part of a complete email security strategy.
Do you know which services are currently sending email on behalf of your domain? The free domain check from DMARCPulse gives you an immediate overview of your DMARC configuration and makes unknown senders visible in your aggregate reports: https://dmarcpulse.io/en/free-domain-check