How to Make SPF and DKIM Work When Your Email Goes Through a Third-Party Sender

When a third party sends email from your domain, the authentication checks that should pass can still fail -- and the reason is alignment, not a broken record.

If you use Brevo to send marketing emails from your domain, your SPF record might include Brevo's servers and your DKIM might be signed by Brevo. But if those signatures do not align with your domain in the DMARC check, your emails will fail DMARC even though individually SPF and DKIM are configured correctly.

This is the alignment problem. It catches most people when they first add a third-party sender, and it is the reason many domains stay at p=none instead of moving to p=reject. DMARCFlow catches this specific problem through continuous alignment monitoring, which we will come back to at the end.

Here is what alignment means, why third-party senders break it, and exactly how to fix it.

What SPF Alignment Means

SPF checks whether the sending server is permitted for your domain. The alignment check in DMARC asks a second question: does the domain in the RFC 5321 MAIL FROM match the domain in the RFC 5322 From header?

These two domains can be different. A third-party sender often uses its own infrastructure for the MAIL FROM while the From header shows your brand domain. That mismatch triggers an alignment failure, even when the sending server is authorized.

When your own mail server sends directly, the MAIL FROM and From header are the same domain. When Brevo or SendGrid sends on your behalf, the MAIL FROM is typically something like s1._domainname.example.com, which belongs to the sender, not to you. DMARC sees that as a misalignment.

What DKIM Alignment Means

DKIM signs the message with a private key held by the sender. The signature includes a domain called the d= domain, which the sender chooses. DMARC alignment checks whether that d= domain matches your From header domain.

When you send directly from your own mail server, your DKIM d= domain is your own domain. When a third-party sender adds a DKIM signature, their d= domain is their own domain (e.g., sendgrid.com). If they do not configure custom DKIM signing with your domain as the d=, alignment fails.

Most major third-party email providers can sign with your domain if you configure them to do so. But if that step is missed, DKIM alignment fails even when DKIM passes at the signature level.

How DMARC Combines Both

DMARC requires at least one of SPF or DKIM to pass AND to align. If SPF passes but does not align, DMARC fails. If DKIM passes but does not align, DMARC fails. If neither passes, DMARC fails.

The practical implication: you can have SPF and DKIM both configured correctly and still get DMARC failures if alignment is broken. This is what trips up most practitioners who add a third-party sender for the first time.

The Four Approaches to Third-Party Email Authentication

Here are the four ways to handle authentication when a third party sends from your domain.

1. Add the Third Party to Your SPF Record

The simplest fix: add the third-party sender's include mechanism to your SPF record.

If you use Brevo and want to send from your own domain, you add their include to your SPF:

v=spf1 include:spf.brevo.com ~all

If you already have other includes, combine them:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

The third-party sender is now authorized in your SPF record. But this only solves the SPF alignment problem if the MAIL FROM domain they use matches your From domain -- which for most bulk senders, it does not.

This approach works for straightforward cases where the third-party sender uses your domain in the MAIL FROM. Many transactional email providers (Mailgun, SendGrid, Postmark) do this correctly by default. Do not assume -- verify by checking the Authentication-Results header on a test message.

2. Use a Subdomain for Third-Party Senders

A cleaner approach: separate your third-party traffic onto its own subdomain with its own SPF record.

Your main domain (example.com) sends through your own mail server. Your marketing subdomain (marketing.example.com) sends through your email service provider. The two are completely separate.

SPF for your main domain does not need to know about your marketing vendor:

v=spf1 include:_spf.example.com ~all

SPF for your marketing subdomain is dedicated to the vendor:

v=spf1 include:spf.sendgrid.com ~all

DKIM for the marketing subdomain is also signed by the vendor and aligned to marketing.example.com, not example.com. DMARC alignment for the main domain is unaffected.

This approach keeps your main domain clean and limits the blast radius of a third-party problem. If the vendor misconfigures something, it only affects the subdomain. Your main domain DMARC policy can stay strict while you learn the vendor's behavior.

3. Configure SRS for Forwarded Mail

Forwarding breaks SPF and DKIM alignment in a different way. When a message is forwarded, the original MAIL FROM is replaced with the forwarder's MAIL FROM. SPF that was passing for the original sender now fails for the forwarder.

The Sender Rewriting Scheme (SRS) fixes this. SRS replaces the original MAIL FROM with a rewritten address that encodes the original sender. When the forwarded message reaches its destination, the SRS address redirects back to the original sender.

SRS is primarily a tool for forwarding services and mailing list operators, not for third-party senders who send directly from your domain. If your use case involves forwarded transactional emails or mailing list distributions, SRS is the approach that preserves SPF alignment through the forwarding chain.

SRS is not typically a do-it-yourself project. Most DMARC-aware forwarding services handle SRS automatically. If you run your own forwarder, OpenDMARC and other filters can be configured for SRS rewriting.

4. Set Up an SMTP Relay with Authentication

For full control and minimal alignment risk, an authenticated SMTP relay sits between your domain and the outside world.

Your application or mail server sends to the relay using authentication (username and password, or TLS client certificates). The relay re-signs the message with your domain credentials, maintaining alignment throughout.

This approach is more operationally complex but gives you complete control over DKIM signing and SPF behavior. It is the approach most enterprise environments use when they have dedicated sending infrastructure and cannot accept alignment risk.

Decision Tree: Which Approach Should You Use?

Here is how to pick the right approach for your situation.

Does your application send directly, or does a vendor send on your behalf?

• Vendor sends on your behalf: go to step 2


• You send directly from your own infrastructure: your SPF and DKIM should align by default. No third-party complication.

Are you using the vendor for marketing or bulk email?

• Yes: use a dedicated subdomain for that vendor. Keep your main domain separate.


• No (transactional email, CRM notifications): add the vendor's SPF include and verify custom DKIM signing.

Does your use case involve forwarded mail chains?

• Yes: check if your forwarding service supports SRS. If not, find a DMARC-aware forwarder.


• No: SRS is not relevant to your setup.

Do you need full control over DKIM signing and cannot accept alignment risk?

• Yes: use an authenticated SMTP relay with custom DKIM signing.


• No: one of the simpler approaches above will work.

How to Verify Your Setup Is Working

Configuration is not enough. You need to check that alignment is actually happening.

Check SPF Alignment

Send a test message through your third-party sender and look at the authentication results. Most email clients show this in the message headers under Received-SPF and Authentication-Results.

Look for the pattern where SPF passes but DMARC fails. If you see SPF pass and DKIM pass individually but DMARC fail, alignment is the problem.

You can also use DMARC aggregate reports to identify the failure source. A high percentage of alignment failures from a specific vendor, with SPF and DKIM showing pass, means the vendor is not aligning correctly.

Check DKIM Alignment

Look at the DKIM-Signature header in a test message. The d= parameter is the signing domain. Does it match your From header domain exactly?

If the d= domain is sendgrid.com and your From header is example.com, DKIM alignment fails. The fix is to configure custom DKIM signing in the sender's platform. Most major providers support this in their DNS settings.

Check DMARC Alignment

Use a DMARC lookup tool to confirm your DMARC record is published correctly. Then use a monitoring tool to watch your aggregate reports for alignment failures.

The aggregate report shows you, in bulk, how many messages are passing and failing each authentication check. It will not tell you which individual messages failed, but it will identify which sending source is causing the most alignment failures.

How DMARCFlow Catches Third-Party Sender Problems Before They Become Incidents

This is where ongoing monitoring matters more than one-time configuration.

When you add a new third-party sender to your domain, SPF and DKIM records look correct at setup. But vendors change their infrastructure, add new IP addresses, or update their DKIM signing keys. Any of these changes can break alignment without warning -- and you will not know unless someone notices a spike in bounces or deliverability problems.

DMARCFlow monitors your aggregate DMARC reports continuously and alerts you when alignment failures spike after a vendor change. If Brevo adds a new sending IP that is not in your SPF include, or if a CRM tool stops signing with your custom domain and reverts to their default domain signing, DMARCFlow flags it as an alignment failure before it becomes a deliverability incident.

For MSPs managing multiple client domains, this matters even more. Each client may have their own set of third-party senders. DMARCFlow's multi-domain view shows which clients are affected by which vendor, making it possible to diagnose and fix problems across an entire client roster from one dashboard.

The specific things DMARCFlow monitors for third-party senders:

• SPF include changes: when a vendor adds or removes IPs from their SPF include, DMARCFlow detects the change and alerts you immediately


• DKIM signature drops: when a vendor stops signing with your custom domain and switches to their default domain signing, DMARCFlow flags it as an alignment failure


• Aggregate failure spikes: any sudden increase in alignment failures is surfaced with the source IP or sending domain identified

The alternative is waiting for someone to notice deliverability problems. That means finding out about a broken vendor configuration days or weeks after it started causing damage.