DKIM signature alignment with SPF under DMARC requires more precision than most implementations achieve on the first attempt — specifically, SPF's "Mail From" domain and DKIM's "d=" signing domain must align with the visible "From" header domain according to specific rules that differ between strict and relaxed alignment modes, and getting this wrong causes DMARC failures even when SPF and DKIM individually pass
The previous articles on this site covered SPF basics, the 10-lookup PermError, email compliance regulations, SPF mechanism deep dives, the envelope sender distinction, and SPF flattening/monitoring. This article addresses SPF and DMARC alignment in multi-domain and third-party sending scenarios — the specific configuration challenges that arise when an organisation sends email through multiple platforms, subdomains, or on behalf of other domains.
Strict vs relaxed alignment: the precise rules
DMARC alignment determines whether SPF and DKIM's authenticated domains are considered to "match" the visible From header domain — and this match (not just SPF/DKIM passing individually) is what DMARC actually checks.
Relaxed alignment (the default, aspf=r and adkim=r): the authenticated domain (SPF's Mail From domain, or DKIM's d= domain) must share the same "organizational domain" as the From header — meaning the same registrable domain, even if subdomains differ.
Example: From header is [email protected]. SPF authenticates bounce.example.com. Both share the organizational domain example.com — relaxed alignment passes.
Strict alignment (aspf=s and adkim=s): the authenticated domain must exactly match the From header domain, including subdomain.
Example: From header is [email protected]. SPF authenticates bounce.example.com. These are different subdomains — strict alignment fails, even though both are part of example.com.
The practical default: most DMARC records use relaxed alignment for both SPF and DKIM (aspf=r; adkim=r, often simply omitted since relaxed is default) — strict alignment is rarely used because it requires exact subdomain matching that many legitimate sending architectures don't naturally produce.
Multi-platform sending: the alignment challenge
Organisations using multiple email sending platforms (Google Workspace for regular email, SendGrid for transactional, Mailchimp for marketing, Salesforce for sales emails) face a specific alignment challenge:
The problem: each platform typically signs DKIM with its own domain (d=sendgrid.net, d=mailchimp.com) by default — using the platform's own signing domain rather than your organisation's domain. This fails DKIM alignment even if SPF passes (because DKIM's d= domain doesn't match your From header's organizational domain).
The solution — custom DKIM signing (domain delegation): each platform supports configuring custom DKIM signing using your own domain. You add specific CNAME records the platform provides, which delegate a subdomain's DKIM key management to that platform while keeping the signing domain as your own (d=yourdomain.com or d=mail.yourdomain.com).
Example SendGrid custom DKIM setup:
CNAME: s1._domainkey.yourdomain.com → s1.domainkey.uXXXXX.wl.sendgrid.net
CNAME: s2._domainkey.yourdomain.com → s2.domainkey.uXXXXX.wl.sendgrid.net
After this configuration, SendGrid signs your outgoing email with d=yourdomain.com (or a subdomain you control) instead of d=sendgrid.net — achieving DKIM alignment with your From header domain.
Subdomain DMARC policy and the sp= tag
DMARC's subdomain policy tag (sp=) controls the policy applied to subdomains that don't have their own explicit DMARC record:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
This says: the main domain (example.com) uses p=reject; any subdomain (mail.example.com, news.example.com, etc.) that doesn't have its own DMARC record uses p=quarantine instead.
Why this matters for multi-platform architecture: if your transactional email comes from mail.example.com and marketing email from news.example.com, each subdomain can have an independent policy via sp= (applying to all subdomains uniformly) or individual subdomain-specific DMARC records (allowing different policies for different subdomains based on each one's authentication maturity).
The staged rollout pattern: when implementing DMARC across a complex multi-platform architecture, it's common to set the main domain's policy aggressively (p=reject) once confident, while initially setting sp=none for subdomains still being configured — preventing a misconfigured subdomain from causing legitimate subdomain email to be rejected while the main domain enforcement proceeds.
Third-party sending on behalf of your domain: the legitimate use case
Some scenarios require a third party to send email using your domain's From address legitimately — not spoofing, but authorised representation:
Examples: a marketing agency sending campaigns on behalf of a client using the client's domain; a SaaS platform sending transactional emails (password resets, notifications) using the customer's domain for branding purposes; an HR platform sending onboarding emails using the company's domain.
The correct configuration for these cases: the third party needs either:
- SPF inclusion: the client adds
include:thirdparty-spf.comto their SPF record, authorising the third party's sending IPs - DKIM delegation: the client sets up CNAME records delegating a DKIM selector to the third party (as in the SendGrid example above), so the third party can sign with the client's domain
The risk this creates: every third party granted SPF or DKIM authorisation for your domain is effectively trusted to send authenticated email as you. A compromised third-party platform (or a third party with poor security practices) becomes a vector for sending DMARC-passing phishing as your domain. This is why minimising the number of authorised third parties and periodically auditing SPF includes and DKIM selectors (removing unused ones) is a meaningful security practice.
Diagnosing alignment failures from DMARC aggregate reports
DMARC aggregate reports (rua=) show per-source authentication results including alignment status specifically:
<row>
<source_ip>192.0.2.1</source_ip>
<count>47</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
<auth_results>
<spf>
<domain>bounce.example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</row>
Reading this report: SPF passed (the sending IP is authorised), but DKIM failed AND the overall DMARC disposition was "quarantine" — meaning despite SPF passing, alignment failed somewhere, or DKIM genuinely failed validation. Cross-referencing the SPF domain shown (bounce.example.com) against the organisation's actual From header domain reveals whether this is an alignment issue (domains don't match the relaxed alignment rule) or a genuine authentication failure.
How to use the SPF Lookup on sadiqbd.com
- For multi-platform audit: check your SPF record's complete include chain and verify each included service corresponds to a platform you're actively using and have configured custom DKIM signing for — removing entries for discontinued platforms reduces both lookup count and unnecessary trust relationships
- For alignment verification: confirm that your SPF-authorised sending domain matches (under relaxed alignment) your organisation's domain used in the From header — a mismatch here causes DMARC alignment failures even with passing SPF
- For subdomain architecture planning: before implementing DMARC across multiple subdomains, document each subdomain's sending platform and authentication configuration to plan appropriate
sp=policy and any subdomain-specific DMARC records needed
Frequently Asked Questions
If SPF passes and DKIM passes individually, why would DMARC still fail?
Because DMARC requires alignment, not just individual authentication success. SPF can pass because the sending IP is correctly authorised in your SPF record — but if that authorisation is for a domain that doesn't match (under relaxed or strict alignment rules) your visible From header domain, SPF's pass doesn't count toward DMARC. The same applies to DKIM: a valid signature from d=sendgrid.net passes DKIM validation but doesn't align with a From header of yourdomain.com unless you've configured custom DKIM signing. DMARC passes if EITHER SPF or DKIM passes AND is aligned — both individually passing without alignment still results in DMARC failure, which is the single most common cause of confusion when troubleshooting DMARC implementations.
Is the SPF Lookup free? Yes — completely free, no sign-up required.
Try the SPF Lookup free at sadiqbd.com — check any domain's SPF record, resolve the include chain, and verify configuration.
