DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Spf

How to Set Up SPF for a Custom Domain When Sending Through Brevo, SendGrid, or Mailgun

By DMARCGuardian Editorial Team ·

How to Set Up SPF for a Custom Domain When Sending Through Brevo, SendGrid, or Mailgun

You use Brevo or SendGrid to send email from your own domain. Your SPF record has the include statement. Your DNS looks correct. And yet your email lands in spam.

Here is what is probably happening: the include statement you added does not do what you think it does. SPF does not authenticate the From header - it authenticates the Return-Path, which is set to the ESP's domain on shared infrastructure. Your SPF record is being checked against the wrong domain.

This post explains what SPF actually does, why the include statement is not solving your deliverability problem, and what actually matters when you are sending through a third-party ESP. It also explains how to check whether your setup is working and how DMARC aggregate reports give you visibility into authentication failures that individual email headers cannot show you.

---

Why SPF Does Not Work the Way You Think It Does

Most people think SPF works like this: you add a sender to your DNS record, and now Gmail knows that sender is allowed to send email from your domain.

That is not what SPF does.

SPF authenticates the Return-Path header, not the From header. The Return-Path is the envelope sender - the address that bounced emails get returned to. When a mail server receives an email, it checks whether the IP address that delivered the email is authorized by the SPF record for the domain in the Return-Path header. This check has nothing to do with the visible From address that users see in their email clients.

When you send through Brevo, SendGrid, or Mailgun on their shared infrastructure, the Return-Path in your email is set to something like noreply@mail.brevo.com or bounces@example.sendgrid.net - not your domain. The SPF check happens against the ESP's domain, not yours.

Your include statement in your SPF record (like include:spf.brevo.com) authorizes Brevo's servers to send mail where the Return-Path is set to Brevo's domain. But the emails you send with a From header showing hello@yourdomain.com are not being SPF-authenticated against yourdomain.com. They are being SPF-authenticated against Brevo's domain, which Brevo already has covered.

This is why adding the include statement often does not fix deliverability. You are solving a different problem than the one causing your spam folder.

---

How SPF Actually Works - Return-Path vs From Header

Here is the sequence when an email is sent through Brevo with a custom From address:

1. You compose an email in Brevo with From: hello@yourdomain.com
2. Brevo sends the email from one of its own IP addresses
3. The Return-Path header is set to Brevo's domain, not yourdomain.com
4. The receiving mail server extracts the Return-Path domain and checks it against Brevo's SPF record
5. Brevo's SPF record passes because the sending IP belongs to Brevo
6. Your SPF record for yourdomain.com is never consulted for this email

The From header you see in your inbox is cosmetic from an authentication standpoint. SPF does not read it.

DKIM is what ties your domain to the email when you send through a third party. Brevo, SendGrid, and Mailgun all offer DKIM signing where they sign the email with a key under your domain (d=yourdomain.com). This is what actually associates the email with your domain in the eyes of the receiving mail server. DKIM is verified independently of the Return-Path, which is why it is the more relevant authentication mechanism for custom domain sending.

---

Shared IPs vs Dedicated IPs and Why the Difference Matters

Brevo, SendGrid, and Mailgun all use shared IP infrastructure by default. Hundreds or thousands of customers send from the same IP addresses. This means:

  • The reputation of the shared IP is built by all senders using it, not just you
  • If another sender on the same IP gets flagged for spam, your deliverability can suffer
  • You have no control over who else is sending from that IP

When you add include:spf.brevo.com to your SPF record, you are authorizing all IPs that Brevo has authorized in their SPF record - which includes all of their shared pool.

Some ESPs offer dedicated IP addresses as an upgrade. If you request a dedicated IP from Brevo or SendGrid, the Return-Path can be set to your domain rather than the ESP's domain. In that specific case, your SPF record becomes genuinely relevant because the receiving server will check SPF against your domain. You would include the dedicated IP in your SPF record like this:


v=spf1 ip4:YOUR_DEDICATED_IP -all

For shared IP sends, your SPF record does not control the authentication outcome. Focus your energy on DKIM and DMARC instead.

---

Building Your SPF Record with a Third-Party Email Sender

If you have a legitimate reason to add an ESP to your SPF record - for example, you send transactional email through both your own mail server and Brevo - here is how to construct the record correctly.

Basic SPF record format:


v=spf1 [mechanism] [value] [qualifier]all

The qualifier determines what happens when a mechanism matches:


  • + = pass (default if omitted)

  • - = fail

  • ~ = softfail

  • ? = neutral

A correct record that includes Brevo for receiving mail via ImprovMX and sending via Brevo:


v=spf1 include:spf.improvmx.com include:spf.brevo.com -all

Breaking this down:


  • v=spf1 identifies this as an SPF record

  • include:spf.improvmx.com authorizes ImprovMX servers to receive mail for your domain

  • include:spf.brevo.com authorizes Brevo's servers to send mail where the Return-Path is set to Brevo's domain

  • -all tells receiving servers to reject mail that does not match any of the above

If you also send from your own mail server, add it:


v=spf1 include:spf.improvmx.com include:spf.brevo.com ip4:YOUR_SERVER_IP -all

The order matters. More specific entries (your own server IP) should come before broader includes, though this is a minor optimization.

---

The 10 DNS Lookup Limit - Avoiding SPF Permerror

SPF records are limited to 10 DNS lookups. Each include: statement counts as one lookup. Nested includes count toward this limit.

If you exceed 10 lookups, the SPF check returns permerror - which most receivers treat as a failure, meaning the email is not rejected but also not authenticated.

Common mistake: chaining multiple ESPs without checking the lookup count.

Example of a record that might exceed the limit:


v=spf1 include:_spf.google.com include:spf.brevo.com include:spf.sendgrid.com include:spf.mailgun.org include:spf.smtp.com ... -all

Five includes, but each of those includes may resolve to multiple additional lookups. You can exceed 10 quickly.

How to check your lookup count:

Use an SPF checker tool or run this in Linux:

bash
dig +short TXT yourdomain.com | grep spf

Look at the include: statements and count each one. If you need to reduce lookups:

1. Use ip4: directly if you know the IP ranges instead of using include:
2. Use SPF1-redirect=_pm.domain.com to consolidate records from another domain
3. Consolidate to fewer sending sources if possible

If Brevo or SendGrid supports a CNAME approach for your SPF setup, that can sometimes reduce lookup counts. Check with your ESP's documentation.

---

Why DKIM Matters More Than SPF for Third-Party Senders

If you do one thing to improve email authentication when sending through a third-party ESP, set up DKIM signing with your own domain - not the ESP's domain.

DKIM attaches a cryptographic signature to your email that is verified against a public key published in your DNS. When Brevo signs your email with DKIM using d=yourdomain.com, the receiving server can verify that the email was indeed authorized by whoever controls the DKIM private key for yourdomain.com - regardless of what IP address it was sent from.

Steps to set up DKIM with Brevo:

1. In Brevo, go to Settings > Sender & IP > Your email domains
2. Add your domain if not already added
3. Brevo will provide two DNS TXT records to add to your domain
4. Add both records in your DNS panel
5. In Brevo, click "Verify" to confirm the records propagate

Once DKIM is verified, Brevo-signed emails will show dkim=pass in the Authentication-Results header when received by Gmail or Outlook. This is the signal that matters for inbox placement.

The same process applies to SendGrid and Mailgun. Each provides DKIM records to add to your domain DNS. The records are specific to each ESP and are usually at the subdomain level (like brevo._domainkey.yourdomain.com).

---

Checking Your Work - Reading Authentication-Results Headers

The Authentication-Results header is added by the receiving mail server (Gmail, Outlook, etc.) and tells you exactly what authentication checks were run and whether they passed or failed.

How to find it in Gmail:
1. Open the email
2. Click the three dots (More) in the top right
3. Click "Show original"
4. Look for "Authentication-Results"

What the header looks like:


Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=brevo header.b=ABC123;
       spf=pass (google.com: domain of noreply@mail.brevo.com designates 123.456.78.90 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Key things to note:


  • dkim=pass means the DKIM signature verified. This is the important one.

  • spf=pass here is checking Brevo's domain, not your domain. This is normal.

  • dmarc=pass means the email passed DMARC alignment (From header domain matches Return-Path or DKIM domain)

If you see dkim=fail but you have DKIM set up in Brevo, the most common causes are:


  • The DNS DKIM record has not propagated (wait 24-48 hours)

  • The record was added incorrectly (check for typos in the hostname and value)

  • Brevo has not yet verified your domain

Individual emails only show you one data point. DMARC aggregate reports (RUA) give you a daily summary of authentication results across all receivers for your domain. This is where you see whether your third-party senders are actually aligned with your DMARC policy.

Without aggregate reports, you have no way to know whether Brevo is consistently passing DKIM alignment across all major receivers - Gmail, Outlook, Yahoo, and everyone else. You are relying on the one email you happened to check. With aggregate reports, you see patterns: if Outlook is consistently failing DKIM alignment for your Brevo sends while Gmail passes, that is something you can investigate and fix before it becomes a larger deliverability problem.

DMARCFlow collects and parses these aggregate reports, showing you per-sender pass/fail rates across all receivers. For a setup like Brevo + SendGrid + your own mail server, you can immediately see which source is causing alignment failures, without having to parse raw XML reports from each receiver.

---

What to Do If SPF Still Fails After Setup

If you have followed all the steps above and your email is still not passing authentication, here is a systematic checklist:

1. Confirm your DKIM is actually signed - Check the Authentication-Results header in a received email. If dkim=fail or dkim=neutral, the signing is not working.

2. Check your DMARC record - Make sure you have a DMARC record published. Start with v=DMARC1; p=none; rua=mailto:your@email.com and monitor the reports before changing the policy.

3. Check your From header alignment - DMARC requires either DKIM or SPF alignment. If your DKIM is signed with your domain and is passing, you should be aligned even if SPF is not relevant to your setup.

4. Review your sending reputation - If you are on a shared IP with Brevo or SendGrid, your inbox placement depends heavily on the reputation of that shared IP. Warm up your IP by gradually increasing volume, clean your list of unengaged subscribers, and monitor your complaint rate.

5. Check for email content issues - Authentication can pass and still result in spam placement based on content, list quality, and recipient engagement. Authentication is not the only factor.

6. Talk to your ESP - Brevo and SendGrid both offer deliverability support for customers on paid plans. If you have persistent issues, open a support ticket with a sample Authentication-Results header from a failed email.

---

FAQ

Do I need SPF if I have DKIM?

For most third-party sending setups, DKIM is sufficient. DKIM provides cryptographic proof that your domain authorized the email, which is what receivers actually check. SPF becomes more relevant if you are sending from your own server infrastructure or using dedicated IPs where the Return-Path is set to your domain.

If you use a third-party ESP on shared infrastructure and have DKIM properly configured with your domain, you may not need to modify your SPF record at all. Your existing SPF record (if you have one) already covers your own mail server, and the ESP's SPF is checked against their own domain, not yours.

What if Brevo or SendGrid uses a CNAME for SPF?

Some ESPs offer CNAME-based SPF setup where instead of adding an include statement, you add a CNAME that points to the ESP's SPF record. CNAME lookups count toward the 10-lookup limit just like includes. The same limit applies.

If your ESP offers both a CNAME and an include option, the include is usually more transparent. CNAMEs can create additional DNS lookup chains that are harder to debug.

My email still goes to spam after correct SPF and DKIM setup. What now?

Authentication is necessary but not sufficient for inbox delivery. If your authentication is passing (dkim=pass, dmarc=pass) but you are still in spam, the issue is likely:


  • Sending reputation on your shared IP

  • List quality and engagement rates

  • Email content triggering spam filters

  • Sudden volume changes that look like a spike

Focus on sending practices before assuming there is a DNS configuration problem.

Can I send from multiple ESPs with one domain?

Yes, but each ESP needs DKIM signing configured with your domain. You can have Brevo DKIM and SendGrid DKIM both signing emails from the same From domain as each is set up correctly in your DNS.

For SPF, you can include multiple ESPs in one record, but watch the 10-lookup limit. Using DKIM alignment for DMARC means you do not need to modify SPF at all when using multiple ESPs - each ESP's DKIM signature with your domain will align with your DMARC policy.