Blog · Dmarc
How to Fix DMARC Alignment When Google Workspace and Third-Party Senders Both Send from Your Domain
The Problem: SPF Passes, DKIM Passes, DMARC Fails
You set up SPF and DKIM for your Google Workspace domain. Both checks pass. Then you add a third-party marketing platform or a billing system that also sends from your domain. DMARC suddenly starts failing, even though nothing in your Google Workspace setup changed.
This is not a Google Workspace problem. This is an alignment problem.
The fastest way to see exactly which third-party platforms are causing alignment failures in your Google Workspace domain is to run it through a DMARC aggregate report analyzer. DMARCFlow reads your reports and shows DKIM and SPF alignment failures separately, naming the sending platforms that are not aligned, so you know exactly which vendors to contact rather than guessing from raw XML data.
DMARC requires more than authentication passing. It requires the domain used in the From header to match the domain used for SPF and DKIM authentication. When a third-party platform sends from your domain but authenticates with its own infrastructure, alignment breaks even though both SPF and DKIM technically pass.
Why DMARC Alignment Is Different from SPF or DKIM Passing
SPF and DKIM each answer a specific question. SPF asks: is this server authorized to send mail for this envelope domain? DKIM asks: does this email have a valid cryptographic signature from this domain? DMARC asks something different: do SPF and DKIM authentication both use the same domain that appears in the From header?
This distinction matters. A third-party platform can pass SPF on its own domain and DKIM on its own domain, while your From header still carries your domain. DMARC sees two passing checks but zero alignment. That is why you get failures in the aggregate report with both SPF and DKIM showing pass while DMARC shows fail.
The two specific ways this happens in mixed sender environments are DKIM alignment failure and SPF alignment failure.
DKIM Alignment Failure: The Third-Party Platform Uses Its Own Selector
When a third-party platform sends email on your behalf, it often adds its own DKIM signature using its domain as the d= value. The DKIM signature is valid, but the signing domain does not match your From header domain.
For example, a SendGrid-sent email might have a DKIM signature with d=sendgrid.net while the From header shows yourdomain.com. DMARC checks the DKIM result and finds a pass, but the aligned domain (sendgrid.net) does not match the From domain (yourdomain.com). Result: DKIM alignment fail.
This is the most common alignment failure in mixed sender environments. It happens whenever a third-party ESP uses its own DKIM infrastructure instead of signing with your domain.
SPF Alignment Failure: The Envelope Domain Does Not Match the From Domain
SPF validates the envelope domain (RFC5321.MailFrom), not the From header domain. Many bulk email platforms use their own bounce domain for SPF, which is different from the From header domain.
For example, the envelope domain might be bounce.sendgrid.net while the From header is yourdomain.com. SPF checks the bounce domain, finds it authorized, and returns pass. But DMARC compares the envelope domain (bounce.sendgrid.net) against the From domain (yourdomain.com). Result: SPF alignment fail.
This is less common than DKIM alignment failure but equally disruptive. It is especially likely during email migrations or when a platform uses a shared infrastructure domain.
How to Fix DKIM Alignment with Third-Party Senders
The core fix is to get the third party to sign with your domain, not theirs. There are three ways to do this, roughly in order of preference.
Option 1: Require the third party to use your domain in their DKIM selector
Some third-party platforms allow you to configure custom DKIM domains. The platform generates a selector on your domain, you add the DNS record, and the platform signs with your domain. This is the cleanest option because DKIM alignment works automatically.
This requires the third-party platform to support custom DKIM domains, which most major platforms do. You will need to create a DKIM record in your DNS for the selector the platform provides.
Option 2: Use a custom DKIM domain in Google Workspace
Google Workspace lets you add custom DKIM domains so that all outgoing mail, including mail forwarded through third-party platforms, can be signed with the same domain. This requires the third party to route through your Google Workspace infrastructure or use a shared signing key you control.
This approach works well when you have tight integration with the third-party platform and can configure their sending settings to use your DKIM domain.
Option 3: Authorize the third-party DKIM domain in your DMARC record
If you cannot get the third party to sign with your domain, you can add their DKIM domain to your DMARC record using the "aspf=r" relaxed alignment mode and an explicit DKIM domain list. This approach is fragile and not recommended as a long-term solution because it requires ongoing maintenance as the third-party platform changes selectors.
The cleanest long-term fix is Option 1. If your third-party platform does not support custom DKIM domains, escalate this with their support team or consider switching to a platform that does.
How to Fix SPF Alignment in Mixed Sender Environments
SPF alignment failure is harder to solve because the fix requires either rewriting the envelope domain or changing how the third party sends mail.
SRS (Sender Rewriting Scheme)
SRS rewrites the envelope return-path domain so that SPF validates against your domain while the mail still routes through the third-party platform. When a forwarder or third-party sender uses SRS, the envelope domain is rewritten to a domain you control, SPF alignment is preserved, and DMARC passes.
SRS is the standard solution for forwarding chains. If your third-party platform supports SRS or you can add an SRS gateway in front of your mail flow, this solves SPF alignment failure cleanly.
Use a subdomain for third-party sending
If SRS is not available, route third-party sender traffic through a subdomain that explicitly inherits your DMARC policy. For example, marketing.yourdomain.com can have its own SPF record and DKIM key while inheriting your DMARC policy through a "rua" reporting address on your main domain.
This approach isolates third-party sending risk to a subdomain while maintaining DMARC protection on your main domain.
Verify envelope domains using raw email headers
To check which envelope domain a sender is actually using, look at the Return-Path header in a raw email. This shows the actual envelope domain that SPF validated. Compare it to the From header domain. If they differ, SPF alignment will fail.
What Happens During Platform Migration That Breaks DMARC Alignment
Email platform migrations are a common trigger for sudden DMARC alignment failures. During a migration, both old and new sending infrastructure may be active simultaneously, each using different DKIM selectors and SPF mechanisms.
A typical migration failure looks like this: you set up DKIM on your new email platform before fully retiring the old platform's DKIM keys. For a short window, mail is being signed by both the old and new selectors. If the new selector is not correctly configured, DMARC fails for mail that should be legitimate.
The fix is to sequence the migration carefully. Set up the new DKIM selector in DNS first, then configure the new platform to sign, then verify alignment using a DMARC aggregate report before retiring the old selector. Run both systems in parallel for a period long enough to confirm all legitimate mail is aligned.
Migration planning should include a DMARC audit step: check your aggregate reports during the transition to confirm that new sending sources appear as aligned pass rather than unaligned pass.
How to Audit Your Sending Infrastructure Before Alignment Problems Hit
Most alignment failures are predictable if you know what to look for. An audit of your current sending infrastructure takes about thirty minutes and prevents failures that would otherwise surface as DMARC reject incidents.
Step 1: List every domain and IP that sends from your address space
Your DMARC aggregate reports already contain this information. Look at the source IPs and envelope domains in the
Step 2: Check which sources have alignment failures
In your aggregate reports, look for sources where
Step 3: Identify third-party platforms by their envelope domains and DKIM selectors
Third-party platforms tend to use recognizable envelope domains and DKIM selectors. SendGrid uses sendgrid.net. Mailchimp uses mailchimp.com. Stripe uses stripe.com. If you see these domains in your aggregate reports and they are not aligned, that is a known third-party platform causing alignment failures.
Step 4: Fix alignment before it causes reject incidents
For each unaligned third-party sender, contact the platform and ask about custom DKIM domain support. If they support it, configure it and verify alignment using your aggregate report within 48 hours. If they do not support it, evaluate SRS or subdomain isolation as a workaround.
How DMARCFlow Catches Alignment Failures Before They Reach Recipients
DMARCFlow reads your aggregate reports and surfaces alignment failures separately from authentication failures. When a third-party platform starts causing alignment failures, DMARCFlow flags it by name in the sending source inventory, so you know which platform to contact rather than hunting through XML reports.
The sending source inventory in DMARCFlow maps each third-party platform to its alignment status over time. When a new platform appears in your reports, you can see immediately whether it is aligned before it causes reject incidents.
Before onboarding a new third-party sender, use DMARCFlow to verify that alignment is working. Run a check after configuration to confirm the platform is signing with your domain or using SRS correctly. Catching alignment problems in monitoring is much easier than discovering them when a critical billing email stops arriving.
FAQ
Why does DMARC fail when SPF and DKIM both pass?
Because DMARC checks alignment, not just authentication. Both SPF and DKIM must use domains that match your From header domain. If a third-party platform sends from your domain but authenticates with its own domain, authentication passes but alignment fails.
How do I know if my third-party platform is causing DKIM alignment failures?
Check your DMARC aggregate report. Look for sources where both SPF and DKIM show pass but the DKIM domain (d= value) does not match your From domain. DMARCFlow surfaces these as DKIM alignment failures specifically.
Can I use Google Workspace DKIM keys for third-party platforms?
Only if the third-party platform supports custom DKIM configuration and can be configured to use your Google Workspace DKIM selector. Most major platforms support this. Smaller platforms may not.
What is SRS and do I need it?
SRS (Sender Rewriting Scheme) rewrites the envelope return-path domain so that SPF validates against your domain. You need SRS if you have forwarding chains or third-party senders whose envelope domains differ from your From domain and who cannot be configured to use your domain for DKIM signing.
How long does it take to fix DMARC alignment with a third-party platform?
It depends on the platform. If the platform supports custom DKIM domains, configuration takes a few hours plus DNS propagation time. If they do not support it and you need SRS or a subdomain workaround, plan for a day or two of configuration and testing.
Should I move to p=reject if I have unaligned third-party senders?
No. Moving to p=reject while unaligned third-party senders are active will cause those senders' mail to be rejected. Fix alignment first, then move to enforcement. Use p=none monitoring to understand your full sending picture before making any policy changes.