Shared ESP SPF Includes Can Let Spoofed Mail Pass DMARC

· Original article ↗

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

Related Articles