Blog · Dmarc
DMARC Alignment Fails With Third-Party Senders - Why It Happens and What to Do
You have set up SPF. You have set up DKIM. Your DMARC record is published. Then a DMARC report arrives and shows failures from a sender you do not recognize - a marketing platform, a billing system, a CRM tool. Your SPF and DKIM are correct. Why is DMARC failing?
The answer is alignment. DMARC does not just check whether SPF or DKIM pass. It checks whether the domain that SPF or DKIM authenticate matches the domain in the email From header. When you send through a third-party platform, they send from their own servers using their own domain. Alignment breaks, and DMARC reports catch it.
The practical question is not just why it happens, but how to find every third-party sender in your DMARC reports and get each one properly configured before you enforce DMARC. That is the work DMARCFlow is built for: turning raw DMARC reports into an actionable list of senders that need attention.
Authentication vs. Alignment - Why the Distinction Matters
SPF and DKIM are authentication mechanisms. They answer the question: was this email actually sent by or on behalf of the organization that claims to have sent it?
SPF verifies that the sending mail server IP is authorized for the domain published in the SPF record. DKIM verifies that the email was signed with a private key corresponding to a public key in DNS.
DMARC adds a third check: alignment. Alignment asks whether the domain that SPF or DKIM validated is the same domain that appears in the From address of the email.
Here is the key point. An email can pass SPF and DKIM but still fail DMARC if the authenticated domain does not match the From domain. This is not a bug. It is the actual security feature that makes DMARC useful. A spoofed email from an attacker might pass SPF from the attacker's own server, but that server is not authorized for your domain, so SPF alignment fails.
The problem is that legitimate third-party senders can trigger exactly the same failure pattern.
Why Third-Party Senders Break DMARC Alignment
Consider a real example. You own example.com. You use Google Workspace for your primary email. You also use a marketing platform to send newsletters, and a billing system to send invoices.
When the marketing platform sends an email on behalf of example.com, it typically sends from its own servers. The email's From header shows newsletter@example.com, but the SPF record for the marketing platform's domain authorizes their servers, not yours. The DKIM key belongs to the marketing platform's domain, not example.com.
The From header says example.com. SPF authenticates the marketing platform's domain. DKIM signs for the marketing platform's domain. Neither matches example.com. DMARC alignment fails.
This happens with any third-party sender that does not use your domain in its sending infrastructure. The common ones:
- Marketing automation platforms (Mailchimp, HubSpot, SendGrid transactional, and similar)
- Billing and invoice systems
- CRM platforms with built-in email sending
- Shared hosting providers that send on behalf of customers
- Internal tools that relay mail through external gateways
The failure is not caused by a misconfiguration on your end. It is caused by the fundamental architecture of how third-party sending works.
Option 1 - Use the Platform's Custom DKIM Domain
Many third-party email platforms support custom DKIM signing. Instead of signing emails with their own domain's DKIM key, they sign with a DKIM key you publish for your own domain.
The general steps:
1. You publish a DKIM record for a subdomain of your domain in your DNS
2. You give the public key to the third-party platform
3. The platform configures their systems to sign outbound email with your subdomain's DKIM key
4. DMARC checks DKIM alignment and the signing domain now matches your From domain exactly
This is the cleanest solution when the platform supports it. DKIM alignment passes because the signing domain matches the From domain. SPF still fails unless you also relay through your own servers, but DKIM alignment alone is sufficient for DMARC to pass.
Not all platforms support custom DKIM signing. Some only offer it on higher-tier plans. Some do not offer it at all.
Option 2 - Send From a Subdomain Through the Third Party
A different approach is to designate a subdomain specifically for each third-party sender. Instead of sending from newsletter@example.com through the third party, you use a subdomain structure like newsletter@example.com, where the DKIM key is published under your subdomain.
The key advantage is that DMARC alignment passes because the signing domain is a subdomain of your From domain. This approach requires the third-party platform to support custom DKIM or subdomain-level sending configuration. It also requires careful DNS management to avoid creating confusion about which subdomains belong to which platform.
This approach is useful when you have multiple third-party senders and want to keep each one isolated from your primary domain's sending reputation.
Option 3 - Relaxed Alignment Mode
By default, DMARC uses strict alignment for DKIM. The signing domain must exactly match the From domain. For SPF alignment, the MAIL FROM domain must match the From domain.
Relaxed DKIM alignment allows the signing domain to be a subdomain of the From domain. Relaxed SPF alignment allows the MAIL FROM domain to be a subdomain of the From domain.
This does not solve the third-party sender problem in most cases. Most third-party platforms use completely different domains - not subdomains of your domain. Relaxed alignment helps when your own mail servers sometimes send from subdomains, but it does not help when a SendGrid or Mailchimp sends from sendgrid.net or mailchimp.com.
Strict alignment is the safer default. Do not loosen it without a specific reason.
How to Find Which Third-Party Senders Are Failing in Your DMARC Reports
Before you can fix alignment failures, you need to know which senders are causing them. The only reliable way to see this is in your DMARC aggregate reports.
In a DMARC aggregate report, look for
Once you have identified the senders, you can decide which approach to use for each:
- Use a custom DKIM domain if the platform supports it
- Route through a dedicated subdomain if feasible
- Document the sender as a known third-party source if alignment cannot be fixed
- Stop using the sender if it cannot be configured and causes too many failures
This is where the difference between reading raw DMARC XML and using a monitoring tool becomes practical. DMARCFlow parses aggregate reports and surfaces which senders are failing alignment, which source IP they are using, and whether they are passing authentication even if alignment fails. Without that visibility, going from a DMARC report to an actionable fix requires manually parsing XML from multiple report providers - each with their own format quirks.
The alignment breakdown in a DMARCFlow report might show something like: SendGrid marketing server at 198.51.100.15 is passing DKIM but failing alignment because it signs for sendgrid.net rather than yourdomain.com. That specificity is what makes it actionable.
When to Move to p=reject With Third-Party Senders in the Mix
The goal of DMARC enforcement is to reject email that spoofs your domain. Adding third-party senders does not change that goal, but it complicates the path to p=reject.
Before moving to p=reject, you need to be confident that every legitimate sender using your From domain is authenticated and aligned. That means:
- All your own mail servers are passing SPF and DKIM alignment
- All third-party senders are either passing DKIM alignment via custom DKIM or are documented as known alignment failures
- No internal systems are sending email that could break without you noticing
The practical path:
1. Start at p=none and monitor for at least 4 to 8 weeks
2. Identify every source that appears in your DMARC reports
3. Classify each source as known and aligned, known and misconfigured, or unknown
4. Fix or exclude the misconfigured and unknown sources before moving to p=quarantine
5. Repeat monitoring at p=quarantine before moving to p=reject
If you move to p=reject while an unconfigured third-party sender is still active, that sender's email will be rejected. If that sender is your billing system, you stop receiving invoices. If it is your CRM, your sales team misses outbound emails. This is an avoidable problem if you do the monitoring work first.
Ongoing monitoring matters here too. New third-party senders get added. Platforms change DKIM configurations. People spin up tools without telling IT. A quarterly review of your DMARC reports catches these changes before they become delivery emergencies or security gaps.
FAQ
Does SPF alignment help with third-party senders?
Not really. SPF alignment checks whether the MAIL FROM domain matches the From domain. Most third-party senders use their own MAIL FROM domain, which does not match yours. The more practical solution is DKIM alignment via custom DKIM signing.
My third-party sender does not support custom DKIM. What can I do?
Two options. If the sender is not critical, document it as a known alignment failure and accept that it will never pass strict DMARC. If the sender is critical, ask them about custom DKIM support or subdomain sending options. If they cannot accommodate either, consider routing their email through a relay you control, so the email goes out via your own mail servers with your own authentication.
Can I use relaxed alignment as a workaround for third-party senders?
Only if the third-party sender uses a subdomain of your domain. If they send from their own unrelated domain, relaxed alignment does not help. Strict alignment is also more secure, so do not loosen it without a specific reason.
How do I know if Google Workspace DKIM is aligned?
When you enable DKIM in Google Workspace, Google signs emails with a key published under google.com, not under your domain. This means DKIM alignment fails for your apex domain. However, Google Workspace passes SPF alignment if your MX records point to Google and your SPF record includes Google's servers. Many organizations achieve DMARC compliance with Google Workspace through SPF alignment alone, without DKIM alignment.
What happens to email from third-party senders when I set p=reject?
If that sender has not been configured for alignment, their email will be rejected by receivers that enforce DMARC. This is the intended behavior for spoofed email. It is also the outcome for legitimate third-party senders that have not been properly configured. This is why the monitoring phase before enforcement is critical.
DMARCFlow is a practical tool for the entire process described here. It parses DMARC aggregate reports and identifies which senders are failing alignment, which makes it faster to work through the list of third-party senders and get each one properly configured before you enforce p=reject.
The process of getting third-party senders aligned is not a one-time fix. New senders get added, platforms change their DKIM configurations, and people spin up new tools without telling IT. Ongoing DMARC monitoring is the only way to catch these changes before they cause delivery problems or before they are exploited by spoofers using the same third-party platform.