Why is DMARC failing when using 'on behalf of' sending, and how can I fix it?
Published 9 Jun 2025
Updated 24 Jul 2026
10 min read
Summarize with
Updated on 24 Jul 2026: We updated the alignment examples for RFC 9989 and corrected the return-path and subdomain rollout guidance.
DMARC fails with "on behalf of" sending when the domain that passes SPF or DKIM does not align with the visible From domain. The mailbox provider does not use the phrase "on behalf of" or the Sender header for the DMARC decision. It checks whether either SPF or DKIM passes using an authenticated domain that aligns with the RFC5322.From domain.
In the common setup, the message shows a customer address in the visible From field, but the ESP signs DKIM with its own sending domain and uses its own return-path domain for SPF. SPF can pass. DKIM can pass. DMARC still fails because neither authenticated domain aligns with the customer domain in the visible From header.
The clean fix is to authenticate the customer's domain on the sending platform, then sign DKIM with an aligned customer domain. A second workable fix is to use an aligned SPF return-path domain, but DKIM is usually the more stable path because forwarding and routing changes break SPF more often.
Why on behalf of mail fails DMARC
The misunderstanding usually starts with the phrase "on behalf of". It looks like two parties are being authenticated together, but DMARC does not combine two domains into one result. DMARC evaluates the Author Domain in the visible From header against the authenticated SPF and DKIM domains. The optional Sender header can explain who transmitted the message, but it does not repair alignment.
- Visible From: This supplies the Author Domain that DMARC protects, such as customer.com.
- SPF domain: This is the RFC5321.MailFrom domain used by the envelope sender or return-path.
- DKIM domain: This is the value in a valid DKIM signature's d= tag.
- DMARC pass: At least one of SPF or DKIM must pass and have alignment with the Author Domain.
The important trap
Adding the ESP to the customer's SPF record is not enough if the actual SPF-authenticated domain is still the ESP return-path domain. The SPF record can authorize the sending IP, but DMARC still needs the RFC5321.MailFrom domain to align with the visible From domain.
A rejected message can appear with a 550 5.7.26 response, especially when the customer domain publishes p=reject. That result is consistent with the domain owner's requested policy, although each receiver makes its own final handling decision. The failure means neither SPF nor DKIM produced an aligned authenticated identity for the Author Domain.
DMARC checks whether SPF or DKIM matches the visible From domain before passing the message.
What must match for DMARC to pass
DMARC has two routes to a pass. SPF can pass DMARC if the RFC5321.MailFrom domain passes SPF and aligns with the visible From domain. DKIM can pass DMARC if the signature verifies and the DKIM d= domain aligns with the visible From domain.
|
|
|
|
|---|---|---|---|
Customer | ESP domain passes | ESP domain passes | Fail |
Customer | Customer bounce subdomain passes | ESP domain passes | Pass with relaxed SPF alignment |
Customer | ESP domain passes | Customer DKIM passes | Pass |
ESP | ESP domain passes | ESP domain passes | Pass |
Typical on behalf of sending outcomes
The first row is the failure pattern. It feels like it should pass because the ESP authenticated the mail, but DMARC is protecting the customer domain. If the customer domain is in the visible From field, at least one authenticated domain has to align with it.
What passes authentication
- SPF pass: The sending IP is allowed by the SPF record for the RFC5321.MailFrom domain.
- DKIM pass: The cryptographic signature verifies for the domain in the d= value.
What passes DMARC
- SPF route: SPF passes and the RFC5321.MailFrom domain aligns with From.
- DKIM route: DKIM passes and the d= domain aligns with From.
How relaxed and strict alignment change the result
Relaxed alignment is the default when the DMARC record omits adkim or aspf. It allows the authenticated domain and the Author Domain to differ when both have the same Organizational Domain. Strict alignment requires the two domains to be identical.
|
|
|
|
|---|---|---|---|
customer.com | customer.com | Aligned | Aligned |
customer.com | bounce.customer.com | Aligned | Not aligned |
news.customer.com | customer.com | Aligned | Not aligned |
customer.com | esp.example | Not aligned | Not aligned |
Alignment examples for SPF or DKIM authenticated domains
Explicit relaxed alignmentdns
_dmarc.customer.com. TXT "v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc@customer.com"
Relaxed does not mean unrelated
Changing strict alignment to relaxed cannot make esp.example align with customer.com. Relaxed mode helps when the authenticated identity uses a subdomain or parent domain under the same Organizational Domain.
RFC 9989 now defines DMARC and uses the term Author Domain for the RFC5322.From domain. It also uses a DNS Tree Walk to discover the Organizational Domain. The practical pass rule remains the same: one SPF or DKIM authenticated identifier must pass and align with the Author Domain.
How to fix it
The best technical fix is customer-domain DKIM on the ESP. Keep the ESP's own DKIM signature if it helps internal routing or abuse handling, but add a second DKIM signature using an aligned customer domain. Once that customer-domain DKIM signature passes, DMARC can pass even when SPF uses the ESP return-path.
Customer-domain DKIM DNS exampledns
selector1._domainkey.customer.com. CNAME s1.customer.esp.example. selector2._domainkey.customer.com. CNAME s2.customer.esp.example.
If the platform cannot sign with the customer's domain, the next option is SPF alignment through a customer-owned return-path. The envelope sender must use a domain under the customer's Organizational Domain, often a dedicated bounce subdomain.
Matching return-path SPF exampledns
bounce.customer.com. TXT "v=spf1 include:esp.example -all"
Publish SPF for the domain that the ESP actually uses in RFC5321.MailFrom. Adding the sender only to the SPF record at customer.com does not authenticate mail whose return-path is bounce.customer.com, and it cannot align a return-path under an unrelated ESP domain. Some platforms require a CNAME for the custom return-path and publish the SPF record at its target, so follow the platform's exact DNS values.
|
|
|
|---|---|---|
Customer DKIM | Sign with an aligned customer domain | Best operational path |
Customer bounce | Use an aligned return-path | SPF can break on forwarding |
Provider From | Use the ESP visible domain | Less brand control |
Dedicated From subdomain | Stage policy on a child domain | Use only during transition |
Fix options ranked by reliability
A temporary subdomain policy
If the root domain has p=reject, testing can use a dedicated visible From subdomain with its own monitoring policy. The message must use an address such as sender@mail.customer.com in the visible From field. Creating only a bounce subdomain does not move the DMARC policy.
DMARC record for a controlled rolloutdns
_dmarc.mail.customer.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@customer.com"
That child record leaves the root domain at reject while monitoring mail whose visible From domain is mail.customer.com. Once customer-domain DKIM or an aligned return-path is working, move the child policy to enforcement. Use a DMARC record generator when you need a clean starting record without hand-writing every tag.
How to troubleshoot a rejected message
When the receiver rejects the message at SMTP time, the delivered copy is unavailable for header inspection. Send the same message through the same source to a controlled test mailbox that accepts it and exposes full headers. DMARC aggregate reports can also show how receivers evaluated similar traffic from that source.
- Capture headers: Send the exact message through the same source to a mailbox where you can inspect Authentication-Results.
- Find From: Record the Author Domain in the visible From field.
- Check SPF: Find the RFC5321.MailFrom domain that SPF authenticated, not just the pass result.
- Check DKIM: Review every valid DKIM d= value and test whether at least one aligns with the Author Domain.
- Confirm policy: If the Author Domain publishes reject, expect receivers to apply stricter handling to DMARC failures.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The useful header evidence is not merely "spf=pass" or "dkim=pass". Read each authenticated domain beside the DMARC result. If SPF passes for esp.example and DKIM passes for esp.example while the Author Domain is customer.com, the alignment failure is explained.
For a wider diagnostic process, compare the failing source against troubleshooting DMARC failures and then validate the published record with a DMARC checker.
Where Suped fits
Suped's product helps with this workflow because the failure is usually a source-to-domain mapping problem, not a single DNS typo. It shows which sending sources use the Author Domain and which SPF or DKIM identities each source authenticates.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped turns DMARC aggregate data into source-level actions. For an on behalf of failure, the workflow is to identify the ESP source, compare its RFC5321.MailFrom and DKIM d= domains with the Author Domain, apply customer-domain DKIM or an aligned return-path, then watch the same source for a DMARC pass.
- Source mapping: Group aggregate report rows by sender and the customer domain used in From.
- Alignment diagnosis: Compare each SPF and DKIM authenticated domain with the Author Domain.
- Change verification: Track whether the source moves to DMARC pass after DNS and ESP changes.
- Operational alerts: Catch a new or changed sender before reject-policy failures spread.
- Multi-domain review: Repeat the same alignment checks across customer domains in one account.
When policy changes need staging, Hosted DMARC keeps the record changes controlled. After the authentication change, DMARC monitoring shows whether the fix holds across real receiver traffic.
Views from the trenches
Best practices
Authenticate the customer's From domain with DKIM before enforcing reject policies.
Test the same message at a mailbox that exposes headers and accepts DMARC failures.
Keep a second ESP signature if useful, but ensure the customer signature passes DMARC.
Common pitfalls
Assuming an SPF include is enough when the return-path domain belongs to the ESP.
Reading spf=pass as DMARC success without checking which domain actually passed.
Using a relaxed subdomain policy as a permanent workaround instead of fixing auth.
Expert tips
Make customer-domain DKIM the default path for any platform using customer From mail.
Treat SPF alignment as useful, but rely on DKIM for mail that will be forwarded.
Map every source to its From, return-path, and DKIM domains before changing policy.
Marketer from Email Geeks says SPF and DKIM can both pass while DMARC fails when neither authenticated domain matches the visible From domain.
2022-01-14 - Email Geeks
Marketer from Email Geeks says the best fix is to sign with the customer's DKIM domain in addition to the ESP's own signature.
2022-02-03 - Email Geeks
Final recommendation
Fix "on behalf of" DMARC failures by making a customer-controlled domain authenticate the mail, not by hoping the receiver accepts the ESP's domain. The most reliable setup is customer-domain DKIM on the ESP, with an aligned return-path as a useful second layer.
Do not ask the customer to turn off reject on the root domain just to make the campaign work. If testing requires a monitoring policy, use a dedicated visible From subdomain, measure that traffic, then return the subdomain to enforcement after the source is authenticated correctly.
