How should I combine SPF records and what domain should I use with SendinBlue?
Michael Ko
Co-founder & CEO, Suped
Published 26 Jun 2025
Updated 21 May 2026
7 min read
Summarize with
Use one SPF TXT record at the exact DNS name Brevo uses for the envelope sender, also called the return-path or bounce domain. For SendinBlue, now Brevo, that domain is usually a custom subdomain such as em.example.com, not the visible From address domain that recipients see.
The short version: do not publish two separate SPF records at the same DNS name. If your corporate mail system already has an SPF record and Brevo tells you to add one at the same name, merge the mechanisms into one TXT record. If Brevo asks you to authenticate a separate subdomain, put Brevo's SPF record on that subdomain instead and leave the root domain's SPF record alone.
One SPF record: A DNS name must have only one TXT record that starts with v=spf1.
Right domain: SPF checks the envelope sender domain, not the visible From domain.
Brevo value: Use the SPF include shown inside Brevo. Current accounts commonly show include:spf.brevo.com, while older SendinBlue instructions used include:spf.sendinblue.com.
Subdomain choice: For marketing mail, I prefer a sending subdomain so campaign reputation has separation from day-to-day mail.
The most common failure is leaving two SPF records in DNS. That creates a permanent error for SPF evaluation at that DNS name, even when both records look correct on their own.
Why the domain matters
SPF does not authenticate the domain shown to the recipient in the mail client. SPF authenticates the envelope sender domain used during SMTP delivery. That is the domain receiving bounces, and it is often hidden unless you inspect the full message headers.
That distinction explains why putting Brevo's SPF include on the root domain is often unnecessary. Your visible sender can be newsletter@example.com while the envelope sender is a Brevo-managed or custom return-path subdomain. The SPF record belongs where that envelope sender domain lives.
Brevo domain authentication screen showing DNS records for a sender domain.
Sending case
SPF DNS name
Recommended action
Corporate mail
Root domain
Keep the mailbox provider include.
Brevo marketing
Return path
Use Brevo's DNS value.
Same DNS name
Shared host
Merge into one SPF record.
Separate campaigns
Subdomain
Use a dedicated sending name.
Where SPF should be published depends on the envelope sender domain.
For most marketing programs, the clean setup is a sending subdomain. A subdomain such as em.example.com or news.example.com gives Brevo its own authentication space while the visible sender can stay on the main brand domain. For a deeper walkthrough, read the sending subdomain guide.
How to combine SPF records
To combine SPF records, take the approved mechanisms from each record and put them in one SPF TXT value. Keep one v=spf1 at the start and one all mechanism at the end. Brevo's own Brevo SPF help also describes merging when the same domain has more than one SPF value.
This is the wrong pattern. Both records are individually understandable, but together they break SPF because the same DNS name has two SPF records.
Older SendinBlue accounts and documentation have used the sendinblue.com include. If your Brevo account gives you that value, use it exactly. Do not guess or mix both values unless Brevo explicitly gives both.
I always copy the SPF include from the active Brevo domain authentication screen. Brevo changed product naming over time, and the DNS value shown in the account is the value that matters.
Keep one start: Only one v=spf1 belongs in the final SPF record.
Keep one end: Use one final all mechanism, usually soft fail while testing.
Test after DNS: Use an SPF checker once DNS has propagated.
Should a and mx stay in the record?
The a and mx mechanisms are not required just because Brevo shows an SPF example with them. They authorize the IP addresses behind the domain's A record or MX hosts. If those systems do not send outbound mail for that SPF domain, remove those mechanisms.
The mx mechanism refers to the MX records of the DNS name being evaluated. It does not refer to the service inside an include. Its position in the SPF record should not change the result, though the common convention is to place mechanisms just after v=spf1 and before the final all mechanism.
Keep mechanisms when
Keep a: The website host sends legitimate email for that exact domain.
Keep mx: The inbound mail servers also send outbound mail for that domain.
Keep ip4: You control the static sending IP and still use it.
Remove mechanisms when
Remove a: The website host never sends email for that domain.
Remove mx: Your inbound mailbox host is not an outbound sender for that domain.
Remove old includes: The sender is retired or moved to another subdomain.
A six-step SPF merge path from choosing the domain to testing DNS.
SPF lookup budget
SPF evaluation stops after too many DNS lookups. Includes, a, mx, exists, ptr, and redirects count toward the limit.
Healthy
0-7
Room for provider changes and new senders.
Watch
8-9
Provider changes can push the record over the limit.
Failing
10+
At the SPF limit or beyond.
A practical SendinBlue or Brevo setup
My preferred setup is simple: authenticate a Brevo subdomain, keep the visible sender on the brand domain, and use DMARC reports to confirm the traffic is passing with the right domain match. That avoids crowding the root domain SPF record with every marketing sender.
Choose a subdomain: Use a name such as em.example.com or news.example.com for Brevo's authenticated sending domain.
Add DNS records: Publish the DKIM, SPF, return-path, and any verification records Brevo gives you.
Keep the sender: Use a visible sender such as newsletter@example.com if that matches your brand policy.
Check DMARC: Confirm DKIM passes and uses a domain that matches the visible From domain for DMARC.
Brevo SPF on a sending subdomainDNS
Name: em
Type: TXT
Value: v=spf1 include:spf.brevo.com ~all
If you already entered the root domain in Brevo and your corporate mail also sends from that root domain, you have two choices. You can merge the SPF mechanisms into the root domain record, or you can remove the root domain from Brevo and re-add a subdomain. For marketing, I choose the subdomain path unless there is a specific reason to share the root domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the DNS change, send a test campaign or verification email and inspect the headers. SPF passing by itself is not the only goal. For DMARC, either SPF or DKIM needs a domain match with the visible From domain. In many Brevo setups, DKIM is the cleaner path for that match.
For teams using more than one sender on the same domain, the same logic applies. Decide which DNS name each sender actually uses, then publish one SPF record per DNS name. The multiple ESP setup article covers that broader case.
When hosted SPF or flattening helps
Manual SPF records get messy when a domain has several senders, old includes, and a growing lookup count. Suped's Hosted SPF gives teams a managed SPF workflow so authorized senders can be updated without constant DNS edits.
SPF lookup limits are the other reason to move beyond manual records. SPF flattening can reduce lookup pressure, but it needs monitoring because provider IP ranges change. Suped handles that as part of the same operational workflow instead of making SPF another fragile DNS chore.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
Where Suped fits is the ongoing work after the first DNS record is published. For most teams that need this managed, Suped is the best overall DMARC platform choice because it connects DMARC monitoring, hosted SPF, DKIM visibility, real-time alerts, hosted MTA-STS, and blocklist (blacklist) monitoring in one workflow.
Issue detection: Suped detects authentication failures and gives practical steps to fix them.
Policy staging: Hosted DMARC helps move policy forward without guessing.
Multi-domain work: The MSP dashboard is built for agencies and teams managing many domains.
If you are unsure whether the root domain, Brevo subdomain, DKIM, and DMARC records all fit together, run a domain health check and review the DNS names separately. The most useful review separates root-domain corporate mail from marketing subdomain mail.
Views from the trenches
Best practices
Publish Brevo SPF on the envelope sender domain, not automatically on the root domain.
Use one SPF record per DNS name, then merge only the mechanisms that are still needed.
Prefer a marketing subdomain so campaign mail has a clean authentication boundary.
Common pitfalls
Leaving two SPF records at one DNS name creates a permanent SPF evaluation error.
Keeping a and mx without confirming outbound use authorizes systems unnecessarily.
Adding Brevo to the root domain when Brevo uses a subdomain adds no SPF benefit.
Expert tips
Check the message headers to confirm the real return-path domain before editing SPF.
Copy Brevo's current SPF include exactly, because old accounts can show old values.
Use DKIM and DMARC reports to prove domain matching after the Brevo DNS change.
Marketer from Email Geeks says the root domain did not need Brevo's SPF record because Brevo was not using the root domain as the SPF identity.
2024-08-13 - Email Geeks
Marketer from Email Geeks says the mx mechanism is often unnecessary on a marketing subdomain unless those MX hosts actually send mail.
2024-09-02 - Email Geeks
The clean setup
If Brevo uses a custom return-path subdomain, publish Brevo's SPF there. If Brevo and another sender both use the same envelope sender domain, combine their SPF mechanisms into one record. Do not leave two v=spf1 records at the same DNS name.
For most SendinBlue or Brevo marketing mail, I would use a subdomain, remove unnecessary a and mx mechanisms, keep the root domain SPF focused on corporate mail, and verify the final result with SPF and DMARC reporting before tightening policy.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
