You moved your domain to p=reject. You think spoofing is blocked. Then your ESP tells you to add an SPF include to your root domain — and quietly, your DMARC protection gets weaker than it was before.
DMARC at p=reject is the strictest policy the protocol offers. In theory, it tells every compliant receiving server to reject any message from your domain that fails authentication. In practice, it assumes your SPF and DKIM records describe your sending environment accurately. When an ESP's setup UI forces you to authorize a shared IP range on your root domain — a range you don't control, containing IPs used by thousands of other customers — the strictness of your DMARC policy stops mattering for that specific attack vector.
This is not a theoretical risk. It's a prescribed configuration, documented in the setup flows of platforms millions of organizations use. And the ESP with the most explicit version of this problem is MailerLite, which requires include:_spf.mlsend.com on your root domain as a condition of their product working — even though MailerLite never sends from your root domain.
The Configuration That Creates the Exposure
Here's what MailerLite's domain setup instructs customers to do: add include:_spf.mlsend.com to the SPF record on the root domain of the sending organization. If that include is missing, the setup flow flags authentication as failed and the customer can't proceed.
But MailerLite doesn't use the root domain as the Envelope From when it sends email. The messages go out with a MailerLite-controlled return path, which means SPF is never evaluated against the customer's root domain in the first place. The record accomplishes nothing for DMARC alignment. It doesn't help SPF pass. It doesn't help DKIM pass. It does exactly one thing: it adds MailerLite's entire shared IP range to the list of IPs authorized to send mail on behalf of the customer's root domain.
This is the exposure. If any IP in that shared range is compromised — and shared sending IPs are a regular target for credential theft, account takeover, and abuse — an attacker can send email from the customer's root domain that passes SPF. Because SPF passes, DMARC evaluates to pass (alignment succeeds on the envelope sender). The receiving server sees a p=reject domain with a passing authentication result. The message is delivered.
The customer's DMARC policy did not fail. The DMARC specification did not fail. The customer's SPF record, following the ESP's instructions to the letter, authorized the attacker's traffic.
Why This Pattern Exists Across ESPs
MailerLite is the most explicit example because it prescribes the configuration in 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 their root domain SPF record — sometimes because outdated documentation suggested it, sometimes because a well-meaning admin added it years ago and forgot, sometimes because a troubleshooting guide for a deliverability problem pointed them there.
The Mailchimp version of this is instructive. Mailchimp officially states that include:servers.mcsv.net on the root domain is not required for authentication. But the number of organizations that have it anyway is significant — and every one of those organizations has authorized Mailchimp's shared IP pool to send mail as them, even with p=reject in place. When we audit DMARC reports for organizations in this configuration, we can see Mailchimp's IPs showing up as authorized sources even when the organization hasn't used Mailchimp in years.
The common thread across ESPs is this: documentation accumulates, customer configurations persist, and shared IP pools keep broadening. The more customers an ESP has on a given IP range, the larger the blast radius of a compromise on that range. A single attacker with access to one IP in a major ESP's shared pool can spoof the root domain of every customer who ever added the ESP's include to their root SPF — which, for the largest platforms, is a lot of domains.
Some ESPs manage this risk better than others. A few use dedicated SPF records per customer, listing only the IPs actually assigned to that customer. Most don't — the engineering and deliverability tooling investment to do per-customer SPF records at scale is non-trivial, and the business case is weak when the cost is operational complexity and the benefit is security for third-party domains, not for the ESP itself.
In the thread where Alex originally raised the MailerLite point, a deliverability manager at Google put it directly: only a few ESPs use a dedicated SPF record for each client, listing only the IPs that client actually uses. The rest provide a generic include with some pretty big IP ranges in it. This isn't a secret in the industry. It's an accepted architectural tradeoff that every customer inherits, often without understanding the exposure.
The Mechanics of a Shared-IP Spoofing Attack
It's worth being specific about what an attacker actually gets when they compromise an IP in a shared ESP pool that's included in your root domain's SPF.
First, the attacker doesn't need to compromise your account, your DKIM keys, or anything in your infrastructure. The attack vector is upstream — at the ESP level. An attacker who gains access to any sending infrastructure that terminates to an authorized IP in the shared pool can send mail that passes SPF checks for your domain.
Second, the attacker can send from your root domain's Envelope From and your root domain's header From. Because the envelope sender matches your root domain and the sending IP is authorized by your SPF record, SPF passes with alignment. DMARC evaluates authentication results; SPF passing with alignment is sufficient for DMARC to pass. The receiving server then honors whatever disposition policy you've set — and because authentication passed, there's nothing to reject.
Third, this bypasses p=reject entirely. The policy does what it's supposed to do: it tells receiving servers to reject messages that fail DMARC. These messages don't fail DMARC. They pass.
Fourth, the attack has a much wider surface area than people usually assume. A major ESP's shared pool can have dozens or hundreds of IP addresses. Any one of them becomes the vector. And the IP reputation, ironically, is often quite good — these are IPs used by legitimate senders every day, which means the attacker's phishing traffic arrives from a "trusted" IP with a warm sending history.
The attacker doesn't need to maintain access for long. Send a batch of phishing, credential harvesting, or BEC emails; rotate off the IP before the ESP notices. The victim organization's DMARC reports will show the attack IPs as authorized sources, which is alarming but not actionable — because the customer themselves authorized them years ago by following the ESP's setup instructions.
What "Correct" Looks Like: Dedicated Sending Subdomains
The architectural fix for this class of vulnerability is well understood: authenticate the ESP on a dedicated sending subdomain, not on the root domain. MailerLite actually has the feature to do this — their Domain Alignment capability supports authenticating on a dedicated subdomain. Mailchimp supports it. SendGrid supports it. Brevo supports it. Every major ESP supports it.
What dedicated subdomains change is the scope of authorization. If your ESP sends mail on behalf of mail.example.com rather than example.com, then only mail.example.com has the ESP's shared IP pool authorized in its SPF record. Your root domain stays clean, authorizing only the IPs of services that actually need to send from example.com directly.
If a shared IP in the ESP's pool is compromised, the attacker can spoof mail.example.com — not example.com. That's a meaningful improvement. Most phishing attacks that depend on visual impersonation target the root domain because that's what recipients recognize. An attack from mail.example.com is much more likely to be flagged by recipients, by mailbox providers' heuristics, and by security tools monitoring the organization's domain.
The deeper benefit is reputation isolation. If the ESP's shared pool has a bad day — abuse incident, major customer's list compromised, IP listed on Spamhaus — the reputation damage lands on the subdomain, not on the root. Your transactional email from example.com keeps landing in the inbox while you work out what's happening on mail.example.com.
This is why SH Consulting configures subdomains for bulk sending streams on every client engagement where the volume and risk profile justify the complexity. It's not an advanced optimization — it's a baseline architectural decision that limits the damage any single compromise can do.
The MailerLite case is particularly frustrating because the platform has the subdomain alignment feature already. They just don't make it the default in their onboarding flow, which means the majority of customers follow the prescribed configuration and end up with the root-domain exposure. If MailerLite made Domain Alignment the default and walked every new customer through setting up a sending subdomain, the exposure would disappear for the entire customer base.
What p=reject Actually Protects Against
Part of why this issue is worth writing about is that it reveals a common misunderstanding about DMARC enforcement. p=reject is sometimes treated as the end-state of email security — the box you check that says "my domain is protected from spoofing." It isn't.
DMARC enforcement at p=reject protects against one specific attack class: email sent from your domain that fails SPF and DKIM authentication. It works extremely well for that class. Attackers spoofing from random infrastructure, using arbitrary mail servers they control, sending from IPs nowhere near your legitimate sending footprint — those attacks get blocked at enforcement. The vast majority of domain impersonation attempts fall into this category, which is why p=reject dramatically reduces spoofing for almost every domain that enforces it.
What p=reject does not protect against is email that passes authentication because the attacker is using infrastructure your SPF record authorizes. Shared IP pools in your SPF record are the most common version of this. But the pattern also applies to look-alike domains included via typo'd SPF entries, to ESPs where DKIM keys are shared across tenants in ways that create cross-tenant spoofing, to any architectural choice that puts authorization inside a trust boundary you don't control.
This is the framing we use on LinkedIn and with clients: p=reject is a policy request, not a technical enforcement mechanism. It instructs compliant receiving servers to reject non-authenticated mail. It does not verify that the mail actually belongs to you. If your SPF record says an IP is authorized, DMARC treats that IP's traffic as yours, and the policy does exactly what it was designed to do: let it through.
Enforcement is still worth doing. It's the single most effective protection available for email-based brand impersonation, and it's a prerequisite for almost every other email security investment. But it's a layer in a stack, not a finish line. The layers below it — clean SPF records, proper alignment, subdomain segmentation, DNSSEC — determine what enforcement actually delivers.
How to Audit Your Own Exposure
If you've read this far and are wondering whether you're exposed, there's a straightforward audit that any technically literate team can run on their own domain. It's the same sequence we walk through in the first phase of a client engagement.
Start by pulling your current root domain SPF record. On any machine with dig installed:
dig +short TXT example.com
Look at every include: entry. For each one, ask: does an ESP currently authenticate my root domain on this sender, or did we add this years ago for a service we no longer use? If you find includes for ESPs you've long since migrated off of, remove them. Those are pure exposure with zero benefit — the ESP isn't using them, and the IP range is still authorized on your root domain.
For the ESPs you are actively using, determine how they send on your behalf. You can see this directly in your DMARC aggregate reports. Look at which IP addresses appear under the domain identifier and which Envelope From addresses they use. If an ESP sends with an Envelope From at a dedicated subdomain (e.g., bounces.mail.example.com), the root domain SPF include is probably unnecessary — the ESP's authentication flows through the subdomain's records. If an ESP uses a subdomain of the ESP itself (e.g., bounces.mlsend.com), the root domain SPF include was never doing anything useful for DMARC in the first place.
The correct configuration for most ESP integrations is a dedicated sending subdomain with its own SPF, DKIM, and — if volume warrants — its own DMARC record. The ESP's shared IP pool gets included only on that subdomain. The root domain's SPF stays lean and authorizes only the services that send from the root (typically your corporate mail provider and a small number of transactional senders).
One caution: don't just delete ESP includes from your root domain without checking first. Some ESPs — MailerLite is the prime example — will flag your authentication as broken and refuse to send even though the include isn't actually being used. The correct sequence is to configure the subdomain first, migrate the ESP's setup to use the subdomain, verify authentication is passing through the new configuration in DMARC reports, and then remove the root domain include. If the ESP's setup flow doesn't support a dedicated subdomain configuration, push them on it — most do, even when the default flow doesn't surface it.
If you're looking at a DMARC report that shows an ESP's shared IPs as authorized sources and you can't figure out whether the mail is yours or someone else's, that's the problem the audit is designed to surface. At that point, the exposure is already in place and has been for as long as the include has been there.
The Harder Problem: ESP Documentation
The single most effective thing the email ecosystem could do to reduce this class of risk is to change how ESP documentation frames SPF and DKIM setup. Right now, the typical ESP documentation says something like "to authenticate your domain, add these records to your DNS." The records include an SPF include on the root. A technically literate admin reads this, adds the records, and moves on. There's no discussion of the tradeoffs. No explanation of what the include actually does. No pointer to the subdomain alignment option as the preferred path.
This isn't a failure of any individual customer's technical judgment. It's a documentation and UI design problem at the ESP layer. Customers follow the instructions they're given. When the instructions prescribe a configuration that creates security exposure, most customers inherit the exposure whether they understand it or not.
The ESPs that care about this will eventually move in the direction of subdomain alignment by default. MailerLite could do it tomorrow — the feature exists, it just isn't the default. Mailchimp could stop recommending the root-domain include in any documentation at all. SendGrid could push dedicated sending subdomains for every new customer rather than letting customers choose the path of least resistance. Until they do, the burden of recognizing and correcting the exposure falls on the customer — which means, in practice, it falls on whoever is paying attention to their domain's DMARC reports.
Closing Thoughts
The MailerLite example is worth paying attention to not because MailerLite is uniquely bad, but because they've made the problem explicit in a way most ESPs haven't. When the setup flow says "add this include or we won't work," the tradeoff is surfaced — even if the customer doesn't understand it in the moment. The quieter version of this problem, where outdated documentation from five years ago suggested the same configuration and the customer's SPF record has been carrying that exposure ever since, is far more common and much harder to detect without an audit.
The practical implication for any organization sending at scale is that DMARC enforcement is necessary but not sufficient. Getting to p=reject protects against the easy attacks — the random spoofing from arbitrary infrastructure that makes up most spoofing traffic. It does not protect against attacks that originate from infrastructure your own SPF record authorizes. Closing that gap requires understanding what your SPF record actually authorizes, trimming the entries that don't need to be there, and moving ESP authentication onto dedicated subdomains where the blast radius of a compromise is contained.
This is tedious work. It's not as satisfying as flipping a policy from p=none to p=reject and calling the project done. But it's what separates a domain that looks protected from a domain that actually is.
At SH Consulting, we audit SPF records, DKIM configurations, and DMARC reports across every ESP a client is sending through — and move ESP authentication onto dedicated subdomains where shared-IP exposure is the risk. If your domain is at p=reject but you're not sure what your SPF record actually authorizes, book a call and we'll walk through it.
