How should I combine SPF records and what domain should I use with SendinBlue?
Updated on 19 Oct 2026: We updated the Brevo setup options and added practical SPF merge steps with DNS and message-header checks.
SendinBlue is now Brevo. Do not add a Brevo SPF include unless Brevo gives you an SPF record for your specific setup. Standard shared-IP domain authentication uses a Brevo code, DKIM, and DMARC. Brevo's authentication instructions confirm that SPF and MX records are not required for that authentication path.
Authenticate the domain used in the visible From address. For hello@example.com, that domain is example.com. A branded return-path such as mail.example.com is a separate setting and is normally connected to Brevo with the CNAME value shown in the account. If Brevo explicitly provides an SPF TXT record for a dedicated IP or legacy setup, publish one SPF record at that exact hostname and merge it with any SPF record already there.
Fast answer
- Do not add SPF just to authenticate a shared-IP Brevo domain.
- Authenticate example.com for a visible sender such as hello@example.com.
- For a branded return-path, use the hostname and DNS record type Brevo provides.
- When Brevo requires SPF at a hostname that already has an SPF record, merge the authorization into that record.
Current Brevo setup types
Brevo is rolling out a newer guided domain setup, so accounts do not all show the same DNS records. Copy the record type, hostname, and value displayed in the account instead of adapting an old SendinBlue example. Brevo's guided domain setup explains the individual-record and Brevo-managed options. The setup type decides whether SPF needs any change.
|
|
|
|---|---|---|
Standard shared IP | Brevo code, DKIM, DMARC | Do not add Brevo SPF |
Branded subdomain | CNAME for return-path and SPF | Publish the supplied CNAME |
Brevo-managed subdomain | Two NS records for subdomain delegation | Brevo manages the delegated DNS records |
Dedicated IP | Account-specific DNS records | Use the supplied value |
Legacy manual SPF | SPF TXT at a named host | Merge only at that host |
Use the DNS record Brevo displays for the selected setup.
Some accounts offer Brevo-managed setup using two NS records instead of individual DNS records. This option is for a dedicated sending subdomain, not the root domain. Use an unused subdomain and delegate only the hostname Brevo specifies so existing website and mailbox DNS remain under your control.
Do not mix CNAME and TXT instructions
If Brevo gives mail.example.com as a CNAME, do not add an SPF TXT record at mail.example.com. A CNAME hostname cannot also hold an SPF TXT record. The CNAME points SPF queries to Brevo's infrastructure; NS delegation is a different setup option.
When an SPF record needs combining
Combine SPF when a new sender requires an SPF authorization at a hostname that already has an SPF TXT record. Receivers do not merge separate records beginning with v=spf1. Multiple SPF records at one hostname produce an SPF permerror. Other TXT records, such as domain-verification tokens, can coexist with that one SPF record.
For a conventional record ending in all, keep one v=spf1 version marker, retain the required mechanisms without exact duplicates, and keep one final all mechanism. Do not combine records at different hostnames. example.com and mail.example.com have separate SPF evaluations, and subdomains do not inherit the root domain's SPF record.
Bad: two SPF records at one hostnamedns
example.com. IN TXT "v=spf1 include:_spf.google.com ~all" example.com. IN TXT "v=spf1 include:spf.brevo.com ~all"
Valid merge when Brevo supplied the includedns
example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.brevo.com ~all"
These examples use DNS zone-file syntax. In a DNS form, enter the text inside the quotes in Value or Data, and enter the hostname separately in Host or Name.
Treat the value as an example
The current Brevo merge example uses include:spf.brevo.com, but standard shared-IP authentication does not require it. Publish an include only when the DNS instructions in your account provide one.
|
|
|
|---|---|---|
Mailbox SPF | example.com | Keep existing senders |
Brevo CNAME | mail.example.com | Do not add TXT |
Additional SPF authorization | Same hostname | Merge mechanisms |
No host sending | SPF TXT hostname | Remove unused a or mx |
The hostname and record type decide the action.
How to merge SPF in your DNS settings
Make this change only when Brevo supplies an SPF TXT value for your setup. In a DNS zone for example.com, @ usually means example.com and mail usually means mail.example.com. Some DNS providers require the full hostname.
- Open the authoritative DNS provider's settings, copy the existing SPF value for rollback, and identify the live senders using that hostname.
- Edit the existing SPF TXT record. If none exists at that exact hostname, create one using the supplied value. Do not publish a temporary second SPF record.
- For a record ending in all, combine the required sender mechanisms before it. Keep one v=spf1 marker, remove exact duplicates, preserve mechanism qualifiers, and retain the intended final ~all or -all policy.
- Validate the merged value and its nested DNS-querying terms before saving. Replace the old SPF value and remove any duplicate SPF records at that hostname, while keeping unrelated TXT and MX records.
- Allow cached DNS answers to expire, recheck the public record, and send a test through each service whose SPF authorization you retained.
If the existing record uses redirect=, review that policy before merging. Adding an all mechanism causes SPF to ignore the redirect, so simple concatenation changes how that record works.
Which domain to authenticate in Brevo
The sender domain and branded return-path have different jobs. If recipients see hello@example.com, authenticate example.com in Brevo. If they see hello@news.example.com, authenticate news.example.com. The branded return-path is a child of that sending domain: mail.example.com or mail.news.example.com in these examples.
A dedicated sending subdomain separates sending streams and DNS changes, but does not guarantee independent reputation because receivers also assess the parent domain. The visible sender must use that subdomain when it is the domain authenticated in Brevo. Use a domain you own and control; free mailbox domains cannot be authenticated. The sending subdomain SPF explanation covers how SPF records are scoped by hostname.
Brevo domain authentication settings for the em.example.com sending subdomain.
Standard authentication
- Use the domain shown after @ in the visible From address.
- Add the Brevo code, DKIM, and DMARC values shown for standard authentication.
- Brevo uses its own return-path infrastructure in the standard setup, so no Brevo SPF include is needed.
Branded subdomain
- Choose an unused child hostname, such as mail.example.com, beneath the authenticated sender domain.
- For the individual-record option, copy Brevo's CNAME target without adding SPF TXT at that hostname.
- mail.example.com and example.com match under relaxed SPF domain-matching rules in DMARC. With aspf=s, the domains must match exactly.
The Brevo SPF merge guide explains how to combine mechanisms when an SPF TXT record is actually required. It does not mean every shared-IP Brevo domain needs that include.
How SPF decides what to check
Sender Policy Framework (SPF) checks the SMTP MAIL FROM domain, also called the envelope sender, which normally appears in the delivered message's Return-Path header. If MAIL FROM is empty, SPF checks the HELO identity. SPF does not authenticate the visible From address by itself. DMARC requires a passing SPF result or DKIM signature whose authenticated domain matches the visible From domain under the applicable DMARC rules.
Flowchart showing SPF evaluation of the SendinBlue (Brevo) return-path domain.
The mx mechanism authorizes the mail exchangers for the hostname being checked. Receiving mail does not prove that those servers send mail, so omit mx unless they send. The a mechanism authorizes addresses returned for the named host. Remove it when the web host does not send mail.
Mechanism order and qualifiers
SPF evaluates mechanisms from left to right and stops at the first match. Put v=spf1 first; for a record using all, put it last. Retain the intended qualifier when merging: ~all returns softfail and -all returns fail for unmatched senders. The receiving server decides delivery; neither result guarantees a particular folder or automatic rejection. Avoid +all because it authorizes every sending IP.
Valid but often too broaddns
example.com. IN TXT "v=spf1 a mx include:spf.brevo.com ~all"
Narrower when only the supplied include is neededdns
example.com. IN TXT "v=spf1 include:spf.brevo.com ~all"
How to check the finished setup
Check every exact hostname Brevo asked you to change. For standard authentication, confirm the Brevo code, DKIM, and DMARC records. For individual branded-subdomain records, confirm the CNAME; for Brevo-managed setup, confirm the requested NS delegation. SPF still needs to pass at the actual MAIL FROM hostname, even when Brevo manages its record. Cached DNS answers remain until their previous TTL expires; Brevo says authentication verification can take up to 48 hours.
When SPF is present, confirm that only one SPF record exists at the hostname. The limit of 10 applies to DNS-querying terms evaluated across the whole SPF check, including nested includes, not to the number of senders. include, a, mx, exists, ptr, and redirect count toward it; ip4, ip6, and all do not. Exceeding the limit produces permerror. These rules are defined in RFC 7208.
Send a real message through Brevo and inspect the receiving server's Authentication-Results header. Check spf=pass, dkim=pass, and dmarc=pass, then compare smtp.mailfrom and the DKIM signing domain, header.d, with the visible From domain. Standard shared-IP mail can pass DMARC through matching DKIM even when SPF authenticates a Brevo-owned return-path.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Use Suped's SPF checker on the MAIL FROM hostname to find duplicate records, syntax errors, or lookup-limit failures. Run the domain health checker to review SPF, DKIM, DMARC, and related DNS after Brevo marks the sender domain as authenticated.
Brevo SPF decision checks
Use these checks before changing SPF for a Brevo domain.
SPF records per hostname
1 max
Other TXT records do not count. More than one SPF record causes permerror.
DNS-querying terms
10 max
Nested evaluation also counts toward the processing limit.
Standard authentication
No SPF added
Brevo does not require SPF or MX for this setup.
Account instructions
Exact match
The record type and hostname must match the current setup screen.
Monitor Brevo authentication in Suped
DNS confirms what is published, while DMARC aggregate data shows which services are sending with the domain. Suped's product connects those views so a team can distinguish Brevo traffic from mailbox or transactional sources before editing SPF.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped can monitor DMARC results, check SPF and DKIM, send alerts after authentication changes, and track blocklist (blacklist) status. For this Brevo workflow, the useful sequence is to identify the live source, confirm its MAIL FROM domain, and then change DNS only when the account instructions require it.
If a setup uses an SPF TXT record and senders change often, Suped's Hosted SPF can reduce repeated DNS edits. Suped's SPF flattening can manage lookup pressure, but flattened IP lists need to stay current as senders change their infrastructure. Neither option should replace a branded-subdomain CNAME or NS delegation supplied by Brevo.
Practical Suped workflow
- Monitor the domain used in the visible From address.
- Confirm Brevo's source and authentication domains in DMARC data.
- Match public records against the current Brevo setup screen.
- Use alerts to catch failures after sender or DNS changes.
Common mistakes to avoid
Most errors come from treating the visible sender domain, authenticated domain, return-path, and DNS hostname as one value. Read each field in the Brevo setup screen and apply the supplied record only to its named host.
- Do not add Brevo SPF to a standard shared-IP authentication setup.
- Do not publish two v=spf1 records at one hostname.
- Authenticate the domain in the visible From address, rather than a different sending subdomain.
- Do not add SPF TXT to a hostname Brevo supplied as a CNAME.
- Remove a or mx unless those hosts send mail. Changing SPF does not require changing inbound MX records.
- With aspf=s, a child return-path does not match a root From domain; confirm matching DKIM before relying on it for DMARC.
- Use the current account's DNS values instead of copying spf.sendinblue.com or another value out of an old article.
If a sending subdomain and visible From domain differ, review the different From domain explanation before changing DMARC domain-matching settings.
Views from the trenches
Best practices
Check Brevo's current DNS screen before adding any SPF include to a sender domain.
Authenticate the visible sender domain and keep the branded return-path separate.
Merge a required SPF authorization into the existing record at that exact DNS hostname.
Remove unused a and mx mechanisms after confirming which systems actually send mail.
Common pitfalls
Adding legacy SendinBlue SPF to a standard Brevo setup creates needless DNS authorizations.
Publishing TXT beside a branded CNAME creates a DNS conflict at that exact hostname.
Testing only the root domain misses SPF errors on a separate MAIL FROM sending hostname.
Keeping old includes can exhaust SPF's DNS-query limit after email provider changes.
Expert tips
Inspect a delivered message header to identify the exact MAIL FROM domain Brevo used.
Treat Brevo's account-specific DNS record type as authoritative for each named hostname.
Verify DKIM domain matching because it can satisfy DMARC without matching SPF results.
Record the owner of each sending hostname so later DNS changes stay controlled over time.
Expert view
Brevo documentation says standard domain authentication needs Brevo code, DKIM, and DMARC, not SPF or MX.
2026-08-11 - Brevo documentation
Expert view
Brevo documentation describes both individual CNAME records and an NS-based managed option for subdomain setup.
2026-10-19 - Brevo domain setup documentation (reviewed)
Frequently asked questions
No. Brevo's current standard shared-IP authentication uses Brevo code, DKIM, and DMARC. Add SPF only when the account supplies it for your setup.
No. Keep one SPF TXT record at each hostname and merge any required sender mechanisms into it. Other verification TXT records can remain. For a conventional policy ending in all, keep one final all mechanism.
Authenticate example.com for hello@example.com, or news.example.com for hello@news.example.com. The branded return-path is configured separately.
No. Publish the CNAME exactly as supplied. That hostname cannot also contain an SPF TXT record. If your account instead supplies NS records for managed setup, use that delegation option rather than mixing it with CNAME instructions.
If Brevo explicitly supplies an SPF include for that hostname, merge it into the existing SPF record, verify every mechanism, and check the DNS-query limit.
