The direct answer is: publish one SPF TXT record per hostname, then put the SendinBlue, now Brevo, SPF include on the hostname Brevo uses as the envelope From, return-path, or bounce domain. Do not add a second SPF record beside an existing one. If two SPF records exist at the same hostname, receivers return an SPF permerror.
For most SendinBlue setups, I use a marketing subdomain such as em.example.com, mail.example.com, or news.example.com as the domain inside Brevo. The visible sender can still be hello@example.com. The SPF record goes on the subdomain because SPF checks the envelope domain, not the address the reader sees in the mail client.
Fast answer
- One record: Keep only one SPF TXT record at each hostname, then place every allowed sender in that single record.
- Right domain: Use the SendinBlue/Brevo return-path domain, usually a subdomain that you add inside Brevo.
- Cleaner split: Keep regular mailbox sending on example.com and marketing sending on em.example.com.
- Avoid extras: Drop a and mx unless that exact hostname sends through its web server or inbound mail servers.
The SPF record to publish
The record depends on which hostname actually sends. If your root domain handles mailbox mail through Google Workspace, keep that SPF record at example.com. If Brevo sends marketing mail with a custom return-path like em.example.com, put the Brevo include on em.example.com. Those are two separate hostnames, so each can have its own SPF record.
The wrong fix is creating two TXT records that both start with v=spf1 at the same hostname. Receivers do not merge them for you. They treat that as a broken SPF setup.
Bad: two SPF records at one hostnamedns
example.com TXT v=spf1 include:_spf.google.com ~all example.com TXT v=spf1 include:spf.sendinblue.com ~all
Better: root mail and Brevo subdomain splitdns
example.com TXT v=spf1 include:_spf.google.com ~all em.example.com TXT v=spf1 include:spf.sendinblue.com ~all
If the same hostname truly sends through both systems, merge the mechanisms into one record. This is common when a team has already configured the root domain as the Brevo domain and also uses that root domain for mailbox mail. I still prefer the subdomain split, but the combined record is the correct repair when the same hostname is unavoidable.
Valid: one combined SPF record at one hostnamedns
example.com TXT v=spf1 include:_spf.google.com include:spf.sendinblue.com ~all
|
|
|
|---|---|---|
Mailbox mail | example.com | Keep mailbox include |
Brevo mail | em.example.com | Add Brevo include |
Same hostname | example.com | Merge includes |
No web sending | Any host | Drop a |
No MX sending | Any host | Drop mx |
Use the hostname that appears in the envelope sender, not just the visible sender.
Why the SendinBlue domain is usually a subdomain
Brevo lets you add a domain for authentication and senders for visible From addresses. Those are related, but they are not the same thing. The sender address can be hello@example.com while the authenticated return-path uses em.example.com. That setup gives marketing mail its own reputation path while keeping the brand address familiar.
This also keeps DNS easier to reason about. The root domain SPF record stays focused on normal mailbox sending. The Brevo subdomain SPF record stays focused on Brevo. If you need a deeper explanation of subdomain SPF behavior, the sending subdomain SPF page covers that case.
Brevo domain authentication screen for a sending subdomain.
Root domain in Brevo
- Higher risk: Marketing sender changes touch the same hostname used for everyday mail.
- Messier SPF: One record collects mailbox senders, ESP senders, and old includes.
- Harder rollback: Removing a sender later needs more care because the record protects more mail streams.
Subdomain in Brevo
- Cleaner scope: Brevo SPF changes affect only the marketing or transactional sending subdomain.
- Better control: You can stage policy, reporting, and reputation decisions per mail stream.
- Same visible From: Recipients still see hello@example.com when the sender address uses the root domain.
Brevo has its own guidance for merging SPF records if you already have more than one at the same hostname. The useful part of the Brevo SPF merge guide is the same core rule: keep one SPF record and combine the mechanisms inside it.
How SPF decides what to check
SPF does not authenticate the visible From address by itself. It checks the SMTP envelope sender domain, also called the return-path or bounce domain. DMARC then compares that authenticated domain with the visible From domain using its domain-match rules. With relaxed DMARC matching, em.example.com and example.com share the same organizational domain, so the setup can satisfy DMARC when the rest of the authentication passes.
Flowchart showing SPF checking the return-path domain before pass or fail.
The mx mechanism is often misunderstood. It means the MX hosts for the SPF record's hostname can send mail for that hostname. It does not mean Brevo's MX hosts or the included domain's MX hosts are approved. The a mechanism has a similar issue: it authorizes the IP address for the hostname's A record. If your website server does not send mail for that hostname, remove it.
Mechanism order
The order of a, mx, and include mechanisms usually does not matter for correctness. I place host mechanisms near v=spf1 by convention, then includes, then the final all mechanism. The bigger decision is whether the mechanism belongs there at all.
Valid but often too broaddns
em.example.com TXT v=spf1 a mx include:spf.sendinblue.com ~all
Cleaner when only Brevo sendsdns
em.example.com TXT v=spf1 include:spf.sendinblue.com ~all
How to check the finished setup
After editing DNS, check the exact hostname you changed. If Brevo uses em.example.com, test em.example.com. Testing only example.com misses the record that matters for Brevo SPF. DNS caching also means the first check after an edit is not always final, so wait for the record's TTL when results disagree.
I also check lookup count. SPF has a hard limit of 10 DNS-querying mechanisms, and include, a, mx, exists, and redirect count toward it. Removing unused a and mx mechanisms helps keep the record under the limit.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Use an SPF checker to confirm there is one SPF record, no syntax error, and no lookup-limit failure. For a wider check across SPF, DKIM, DMARC, and common DNS issues, run the domain health checker after Brevo shows the domain as verified.
SPF hygiene thresholds
Quick rules I use before calling a SendinBlue/Brevo SPF setup complete.
SPF records per hostname
1
Anything above one breaks SPF evaluation.
DNS-querying mechanisms
10 max
SPF fails when the evaluation exceeds this limit.
Unused a or mx
0 ideal
Remove these unless the related host sends mail.
Softfail during setup
~all
Use a staged policy while confirming every sender.
Managing this in Suped
The manual approach works when you have one or two senders. It gets harder when marketing, transactional mail, billing, support, and mailbox sending all add their own SPF requirements. That is where Suped's product is useful: it shows which sources are passing, which sources are failing, and what DNS change fixes the issue.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
For most teams, Suped is the best overall DMARC platform for this workflow because it connects the SPF record to the live mail sources behind it. Suped brings DMARC monitoring, SPF and DKIM checks, real-time alerts, blocklist (blacklist) monitoring, issue detection, and steps to fix into one place.
If you change senders often, Hosted SPF lets you manage approved senders without repeated DNS edits. When the record is too close to the 10-lookup limit, SPF flattening helps reduce lookup pressure while keeping the sender list current.
Practical Suped workflow
- Add domain: Monitor example.com and the Brevo subdomain, such as em.example.com.
- Check sources: Confirm Brevo, mailbox mail, and any other sender appear as expected.
- Fix DNS: Apply the recommended SPF record or hosted include to the right hostname.
- Watch alerts: Use real-time alerts to catch failed authentication after sender or DNS changes.
Common mistakes to avoid
The mistakes I see most often are not exotic. They come from mixing visible sender addresses, envelope sender domains, and DNS hostnames into one mental model. Keep those separate and the answer becomes clear.
- Duplicate SPF: Do not publish two TXT records that both start with v=spf1 at the same hostname.
- Wrong hostname: Do not put the Brevo include at example.com if Brevo uses em.example.com.
- Broad mechanisms: Do not keep a and mx just because they appeared in an old template.
- Strict mode: Do not assume a subdomain return-path works with strict DMARC matching.
- DNS sprawl: Do not keep old provider includes after the sender stops sending.
If you are sending with a subdomain while the visible From address uses a different domain, read the different From domain explanation before changing DMARC policy.
Views from the trenches
Best practices
Put each ESP on its own sending subdomain unless one hostname truly sends through all systems.
Keep SPF records narrow by removing a and mx when web and inbound hosts do not send mail.
Check the envelope sender domain first, then compare it with the visible From domain.
Common pitfalls
Publishing two SPF records at one hostname causes SPF permerror at receiving systems.
Adding SendinBlue SPF to the root domain is wrong when Brevo uses a subdomain return-path.
Leaving old includes in place can push SPF over the 10-lookup limit without warning.
Expert tips
Use relaxed DMARC domain matching for subdomain return-path setups unless strict mode is required.
Treat Brevo's green verification as one check, then validate the public DNS record yourself.
Document which hostname each sender uses so future DNS edits do not break valid mail.
Marketer from Email Geeks says one SPF record with both needed includes is enough when a single hostname must authorize both senders.
2024-03-12 - Email Geeks
Marketer from Email Geeks says the mx mechanism authorizes the MX hosts of the checked domain, not the MX hosts of included providers.
2024-05-08 - Email Geeks
The safest recommendation
Use a dedicated Brevo sending subdomain, publish the Brevo SPF record only on that subdomain, and leave the root SPF record for mailbox mail. If you already added SendinBlue SPF to the root domain by mistake, delete it when Brevo uses a subdomain. If the root domain truly sends through both systems, merge the includes into one SPF record.
The practical test is simple: find the return-path domain, check that exact hostname, and confirm it has one SPF record. Once that passes, send a real message and confirm SPF and DKIM pass and DMARC reports show the expected source.
