5 August 2026 · 5 min read
The short answer: changing sending IPs cannot break DMARC alignment, because alignment compares domains, not addresses. What IP changes can break is plain SPF authorisation, and only in one situation: your SPF record lists infrastructure addresses directly. If your SPF is built from provider include: mechanisms and your mail is DKIM-signed with your own domain, your IPs can change hourly and your DMARC results will not move.
This article explains which setups are genuinely fragile when addresses change, which widely repeated worries are myths, and how to build authentication that does not care what your infrastructure does.
Two different things called "SPF failure"
The confusion around IPs and DMARC almost always comes from mixing two checks:
- SPF authorisation asks: did this message arrive from an IP address my SPF record permits? This is the check that involves addresses.
- DMARC alignment asks: does the domain that passed authentication match the
From:domain a human sees? This check never looks at an IP.
A message passes the SPF half of DMARC only when both are true: the connecting IP is authorised and the envelope domain aligns with the From: domain. Changing an IP can only ever disturb the first half. If you are new to the distinction, start with DMARC alignment explained; it is the single most misunderstood part of email authentication.
The one genuinely fragile setup
SPF breaks under IP change when the record enumerates addresses that stop being yours:
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 -allIf those are autoscaled relay nodes, Kubernetes egress addresses, a rotating pool from your provider, or a connection on a dynamic range from an ISP, the record is wrong the moment the infrastructure moves. Mail then fails SPF authorisation at the receiver, and if it is not DKIM-signed with an aligned domain, it fails DMARC too and your policy is applied to your own legitimate mail.
The failure is easy to spot in your aggregate reports: legitimate mail volume appears under source IPs you no longer control or recognise, failing SPF, shortly after an infrastructure change.
The fixes, in order of preference
1. Send through a provider and use its include. When mail leaves via Google Workspace, Microsoft 365, Amazon SES or a transactional provider, your record names their infrastructure indirectly:
v=spf1 include:_spf.google.com -allThe provider updates its own ranges as its pools change. Their IP churn is their problem, not yours, which is precisely why include: exists.
2. Give self-hosted mail a fixed egress. If you run your own MTA on cloud infrastructure, route its outbound connections through a static address (an elastic IP or NAT gateway) and list that one stable address. A mail server's reputation is tied to its address anyway, so a fixed egress is what you want for deliverability reasons before SPF even enters the picture.
3. Sign with DKIM and align it. A DKIM signature travels inside the message and verifies identically from any source address. DMARC needs only one aligned mechanism to pass, so a message DKIM-signed with your domain passes DMARC regardless of which IP sent it. This is also the mechanism that survives forwarding, which changes the source IP en route by design. Whatever you do with SPF, aligned DKIM on every sending system is the durable half of your authentication.
What not to do: script frequent SPF record updates that chase ephemeral addresses. You will always be behind the change, briefly wrong, and one bad push away from failing everything. If your record is instead growing past the 10-DNS-lookup limit as you add providers, that is a different problem with a proper solution; see SPF flattening explained.
Common worries that are myths
| Worry | Reality |
|---|---|
| "Our load balancer / CDN rotates IPs, will DMARC break?" | Load balancers and CDNs handle inbound web traffic. They are not your outbound mail path, and web infrastructure has no effect on SPF, DKIM or DMARC. |
| "We send from multiple provider regions" | The provider's include: covers its regional ranges. Nothing extra to maintain on the SPF side. |
| "We are enabling IPv6" | Provider includes already cover their IPv6 ranges. Only self-hosted MTAs connecting over IPv6 need their own ip6: mechanism added, exactly as with ip4:. |
| "Our IPs changed, so alignment broke" | Alignment compares domains. If DMARC results changed after an IP move, what actually failed is SPF authorisation of the new addresses, or mail started leaving from a system that does not DKIM-sign. |
How to verify your setup is IP-proof
- Read your record: if it contains hardcoded
ip4:/ip6:mechanisms, confirm each address is static and still yours. The SPF checker resolves the full record, includes and all. - Confirm every sending system applies a DKIM signature with your domain, not just the provider's. The DKIM checker shows what a selector publishes.
- Watch your DMARC aggregate reports across an infrastructure change. Sources that keep passing DKIM while SPF wobbles are fine; sources failing both are the ones to fix.
DMARC Engine does the third step continuously: reports are collected and grouped by sending source, so an infrastructure change that starts failing authentication shows up as a change against a named source rather than a mystery IP in raw XML.