Shared ESP SPF Includes Can Let Spoofed Mail Pass DMARC

Summary
The article explains how root-domain SPF includes for shared ESP IP pools can let spoofed mail pass SPF and DMARC despite p=reject. It recommends auditing includes and moving ESP authentication to dedicated sending subdomains.
Key points
- The author says MailerLite requires include:_spf.mlsend[.]com on the root domain even though its messages use a MailerLite-controlled return path.
- According to the article, authorizing a shared ESP IP pool in root-domain SPF can allow an attacker using that infrastructure to send mail that passes SPF and aligned DMARC.
- The article says root-domain includes for Mailchimp, SendGrid, and Brevo can also authorize shared sending IPs; it notes that Mailchimp says include:servers[.]mcsv[.]net is not required for authentication.
- The recommended mitigation is to authenticate ESPs on dedicated sending subdomains, limiting the scope of shared-IP authorization and reputation risks.
- The audit guidance is to review root-domain SPF includes against current senders and DMARC reports, configure and verify subdomain authentication, then remove unnecessary root-domain includes.
- The author also warns that Mailchimp’s auto-DKIM setup may replace an existing DMARC p=reject record with p=none.
Article Details
- Defense Focus
- Audit SPF authorization and DMARC alignment to identify shared ESP IP ranges authorized on root domains; contain ESP authorization on dedicated sending subdomains.
- Detection Methods
- Inspect the root domain's SPF record and review every include for active business need and whether the ESP actually sends using the root domain.
- Review DMARC aggregate reports for sending IP addresses, domain identifiers, and Envelope From values; identify ESP shared-pool IPs appearing as authorized sources.
- After migrating an ESP to a dedicated sending subdomain, verify authentication through DMARC reports before removing the root-domain SPF include.
- Check whether an ESP's auto-DKIM setup changes an existing DMARC policy from p=reject to p=none.
- Data Sources
- DNS TXT records containing SPF and DMARC configuration
- DMARC aggregate reports
- ESP domain-authentication and setup configuration
- Rule Types
- DNS TXT lookup using dig +short TXT
- Platforms
- MailerLite
- Mailchimp
- SendGrid
- Brevo
- Defensive Actions
- Remove stale ESP includes from root-domain SPF records when they are no longer needed.
- Configure active ESPs to authenticate on dedicated sending subdomains with their own SPF and DKIM records; add a subdomain DMARC record when appropriate.
- Keep root-domain SPF limited to services that genuinely send using the root domain.
- Migrate and verify the ESP's subdomain configuration before removing a root-domain include, since some ESP setup flows may flag its removal as an authentication failure.
- Review Mailchimp's recommended auto-DKIM setup for changes that could replace an existing p=reject DMARC record with p=none.
- Retain DMARC enforcement while recognizing that p=reject does not block mail that passes authentication through infrastructure authorized by SPF.
MITRE ATT&CK
Vendors
Brevosetup UI as non-negotiable. But the underlying pattern is not unique to MailerLite. Mailchimp, SendGrid, Brevo, and others have customers all over the internet who have added the ESP's shared IP range to their rootMailchimpin the setup UI as non-negotiable. But the underlying pattern is not unique to MailerLite. Mailchimp, SendGrid, Brevo, and others have customers all over the internet who have added the ESP's shared IPMailerLiteMailerLite's Required SPF Include Bypasses DMARC p=rejectSendGridin the setup UI as non-negotiable. But the underlying pattern is not unique to MailerLite. Mailchimp, SendGrid, Brevo, and others have customers all over the internet who have added the ESP's shared IP range to
