Suped

Why doesn't Brevo offer full SPF alignment and how much does it impact deliverability?

Matthew Whittaker profile picture
Matthew Whittaker
Co-founder & CTO, Suped
Published 1 Jul 2025
Updated 20 Jun 2026
11 min read
Summarize with
Brevo SPF alignment, DKIM, and DMARC authentication on shared IP sending.
Updated on 20 Jun 2026: We updated this guide to clarify Brevo's shared-IP Return-Path behavior, SPF qualifier choices, and when a dedicated IP is worth considering.
Brevo usually does not provide full SPF alignment on shared IP sending because the envelope sender, also called the Return-Path or SMTP MAIL FROM domain, stays under Brevo's infrastructure instead of your visible From domain. That makes SPF pass for Brevo's bounce domain, not for your brand domain. The practical impact is usually small when DKIM is passing with your domain and DMARC passes through DKIM.
The caveat is important: an SPF alignment warning is not the same thing as a delivery failure or a spam-folder diagnosis. Delivery means the receiving server accepted the message, while deliverability is where the message lands after filtering. Treat the warning as a diagnostic signal, not a reason to buy a dedicated IP by default. For low or inconsistent volume, especially when monthly sending is well below 100,000 emails per month, a dedicated IP often creates more reputation risk than it solves because the sending pattern is too thin to build stable IP history.
  1. Direct answer: Brevo keeps shared-IP bounce handling on its own domain, so SPF does not match your From domain.
  2. Deliverability impact: Low when DKIM is valid, domain-matched, and DMARC passes.
  3. When it matters: It becomes a real issue when DKIM fails, DMARC fails, or reporting tools mark the source as unauthenticated.
  4. Best next step: Check headers, DKIM, DMARC reports, and the Return-Path before changing infrastructure.

The short answer

SPF alignment is a DMARC concept. It asks whether the domain that passed SPF is the same organizational domain as the visible From address. SPF itself can pass perfectly while SPF alignment fails. Under relaxed alignment, a subdomain can match its organizational domain. Under strict alignment, the domains must match exactly. A provider-owned Brevo bounce domain does not match your From domain in either mode. That domain is visible in Authentication-Results as smtp.mailfrom and often appears in Return-Path after delivery.
DMARC does not require both SPF and DKIM to match the From domain. It requires at least one of them to pass and match. If Brevo signs with DKIM using your authenticated sending domain, DMARC can pass through DKIM even when SPF alignment is not present. That distinction is the difference between a noisy warning and a real authentication failure. The separate concepts are easier to debug when you keep SPF authentication and alignment apart.
Typical Brevo shared-IP resulttext
Authentication-Results: spf=pass smtp.mailfrom=mail123.sender-sib.com dkim=pass header.d=example.com dmarc=pass header.from=example.com Result: SPF passes, but SPF alignment is not present. DKIM passes and matches the From domain. DMARC passes.
The key question is not "does SPF match?" The key question is "does DMARC pass for the domain in the visible From address?" If yes, the Brevo SPF alignment warning deserves attention, but it does not automatically explain spam placement.

Why Brevo handles SPF this way

On shared IPs, Brevo needs a predictable Return-Path domain so it can receive bounces, classify delivery responses, process suppressions, and protect shared infrastructure. Giving every shared-IP customer a custom SMTP MAIL FROM domain, also called a custom MAIL FROM or custom Return-Path, requires more than a DNS toggle. It changes bounce routing, customer setup, monitoring, support, and failure handling.
On a Brevo dedicated IP, the setup uses a sending subdomain that appears as the mailed-by or Return-Path domain in message headers. When the Return-Path uses a customer-controlled subdomain, SPF has a domain that can match the visible From domain under relaxed DMARC alignment. That is why the dedicated IP path can change SPF alignment, while adding another SPF include to a shared-IP setup usually cannot.
That is why support often points customers toward a dedicated IP for full SPF alignment. With a dedicated IP setup, a provider can associate the sending subdomain and Return-Path more directly with the customer domain. There is also a Brevo community thread that describes this exact pain point.
Shared IP
Shared IP sending keeps operational control with the ESP. That helps bounce processing and protects the sending pool, but it often means the Return-Path domain is provider-owned.
  1. Upside: Simpler setup and less responsibility for low-volume senders.
  2. Tradeoff: SPF can pass for the provider domain instead of your From domain.
Dedicated IP
Dedicated IP sending can use a custom sending subdomain and Return-Path. It also puts more warm-up, reputation, and volume consistency work on the sender.
  1. Upside: Full SPF alignment is usually achievable with the right provider configuration.
  2. Tradeoff: Low monthly volume can make IP reputation unstable.
Brevo domain authentication settings for SPF, DKIM, DMARC, and dedicated IP setup.
Brevo domain authentication settings for SPF, DKIM, DMARC, and dedicated IP setup.
The frustrating part is that this can look like a defect in your DNS even when your DNS is doing exactly what it can. Adding another include to your root SPF record does not force Brevo to use your domain in the Return-Path. SPF checks the domain in the envelope sender, so the envelope sender has to change for SPF alignment to change.

How much deliverability risk this creates

For normal marketing or transactional mail on Brevo shared IPs, the risk is usually modest if DKIM passes with your domain, DMARC passes, complaint rates are low, bounce rates are controlled, and the list is engaged. Mailbox providers care about authentication, but they also judge domain and IP reputation, engagement, complaints, bounces, list quality, content quality, sending consistency, and user feedback.
SPF alignment becomes more important when DKIM is unreliable. It is also useful as a secondary signal in reports and diagnostics. When both SPF and DKIM match the From domain, there is less ambiguity during audits, migrations, and incident response. For a third-party ESP, domain-matched DKIM should come first.
Risk by authentication result
Use this as a practical triage scale for Brevo shared-IP sending.
Low risk
DKIM pass
DKIM passes with your domain and DMARC passes.
Medium risk
Mixed DKIM
DKIM passes inconsistently or only some mail streams are signed.
High risk
DMARC fail
DKIM fails and SPF is not matched to the From domain.
Do not treat a dedicated IP as a universal fix. A dedicated IP needs warm-up, steady volume, and active reputation management. If your volume is low, inconsistent, or well below 100,000 emails per month, the dedicated IP can have thin reputation history. That can hurt consistency more than missing SPF alignment on a healthy shared pool.
  1. Mostly harmless: SPF is not matched, DKIM is matched, and DMARC passes across real inbox tests.
  2. Needs attention: Different campaign types show different DKIM domains or unsigned mail.
  3. Fix first: DMARC aggregate reports show Brevo volume failing DMARC.
  4. Watch closely: Inbox placement drops at the same time authentication failures rise.

What to check before changing anything

Start with the received message headers, not the dashboard warning. Send a real email to a mailbox you control, open the original message, and check SPF, DKIM, and DMARC results. You want to know which domain passed DKIM, which domain passed SPF, which domain appears in smtp.mailfrom, and which mechanism DMARC used.
Then check your DNS. If your SPF record is broken, too long, duplicated, or over the 10 DNS-querying-term limit, fix that even if Brevo's shared-IP SPF alignment cannot be completed. A broken root SPF record can affect other senders that do use your domain in the envelope sender. A focused SPF checker helps separate record syntax problems from Brevo's Return-Path behavior.
If Brevo asks you to add include:spf.brevo.com and mx, merge those mechanisms into your existing SPF record rather than publishing a second record. Keep one final all mechanism at the end. For most active domains that use several senders, ~all is the safer default until the sender inventory is fully controlled.
That SPF include authorizes Brevo as a sender for the domain, but it does not create SPF alignment unless the SMTP MAIL FROM domain also uses your domain. Changing ~all to -all only changes the result for unauthorized IPs. It does not change the domain DMARC compares. Treat every SPF include as active sending permission, not as proof of DMARC alignment.
Publish only one SPF TXT record for the domain. Multiple SPF records return permerror, and oversized SPF answers can fail inconsistently depending on DNS transport and resolver behavior. That does not make Brevo's shared-IP Return-Path match your domain, but it stops a separate SPF defect from damaging other mail streams.

SPF checker

Find SPF syntax issues, lookup limits, and weak records.

?/16tests passed
For a broader view, run a domain health check and compare it with your DMARC aggregate reports. The important pattern is whether Brevo appears as a passing DKIM source, not whether every single checker likes the SPF alignment result.
Minimum DNS state to verifytext
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" example.com. TXT "v=spf1 include:spf.brevo.com mx ~all" selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLICKEY"
Suped's product is useful in this workflow because it groups DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability signals in one place. The value is seeing whether the error maps to real DMARC failure, which source caused it, and what to fix next.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records

Your practical options

There are four realistic paths. The right one depends on whether DMARC passes today, whether your volume supports a dedicated IP, and whether you need stricter reporting consistency for compliance or brand protection. A dedicated IP is about custom Return-Path control and reputation ownership, not simply removing a warning.

Option

Best fit

Tradeoff

Stay shared
Low or uneven volume
SPF warning remains
Fix DKIM
DMARC gaps
Needs DNS access
Dedicated IP
100k+ steady volume
Warm-up required
Move provider
Strict policy
Migration work
Common choices for Brevo SPF alignment issues.
For most teams, first make DKIM and DMARC boring. That means the sending domain is authenticated, DKIM is stable, DMARC reporting is collected, and policy movement is staged. Suped's product supports that work by turning raw reports into source-level issues, alerts, and fix steps. When SPF complexity grows across multiple senders, Hosted SPF in Suped's product helps manage sender includes without constant DNS edits.
If Brevo is your only sender and DKIM is passing cleanly, do not chase full SPF alignment at any cost. Switching the SPF qualifier from ~all to -all will not make a shared Return-Path match your domain. If Brevo volume is large, steady, business-critical, and you already have a warm-up plan, a dedicated IP becomes more reasonable. If DMARC reports show Brevo failing because DKIM is missing or broken, fix that before anything else.
Priority order
A simple way to rank fixes before spending money on infrastructure.
Do first
Do later
Avoid early

Views from the trenches

Best practices
Verify DKIM by message headers before acting on SPF alignment warnings in checkers.
Use DMARC reports to confirm whether Brevo traffic passes through DKIM at volume.
Keep low-volume senders on shared IPs unless there is a proven reputation reason.
Common pitfalls
Adding more SPF includes will not change the Return-Path domain Brevo uses on shared IPs.
Buying a dedicated IP without enough volume can create unstable sender reputation.
Treating checker warnings as inbox placement proof leads to poor remediation work.
Expert tips
Prioritize domain-matched DKIM because it survives the shared-IP SPF limitation.
Monitor failed DMARC sources, then decide whether SPF alignment deserves budget.
Ask providers whether custom SMTP MAIL FROM works on shared IPs before migration.
Marketer from Email Geeks says Brevo's shared-IP limitation is product work, not a DNS mistake, and custom SMTP MAIL FROM support changes the platform's bounce handling.
2025-02-24 - Email Geeks
Marketer from Email Geeks says SPF alignment is common as a concern, but domain-matched DKIM usually keeps DMARC passing for ESP mail.
2025-02-24 - Email Geeks

What to do next

Do not treat Brevo's missing shared-IP SPF alignment as an automatic deliverability problem. Prove the authentication path first. If DKIM passes with the From domain and DMARC passes in real mailbox headers and aggregate reports, the SPF alignment warning is usually a known limitation rather than the root cause of poor placement.
The sensible order is simple: validate DKIM, collect DMARC reports, check actual inbox symptoms, then decide whether a dedicated IP has enough volume to support it. Do not switch from ~all to -all as a workaround for shared-IP SPF alignment. Suped's product fits that order because it connects authentication failures, source identification, policy staging, real-time alerts, Hosted SPF, SPF flattening, and blocklist (blacklist) monitoring in one workflow.
For a sender with low or inconsistent volume, the default answer is: stay on shared IPs, make DKIM and DMARC clean, monitor results, and avoid paying for dedicated IP infrastructure just to remove one SPF alignment warning.

Frequently asked questions

DMARC monitoring

Start monitoring your DMARC reports today

Suped DMARC platform dashboard
What you'll get with Suped
Real-time DMARC report monitoring and analysis
Automated alerts for authentication failures
Clear recommendations to improve email deliverability
Protection against phishing and domain spoofing