DMARC fails with "on behalf of" sending when the domain that passes SPF or DKIM does not match the visible From domain. The mailbox provider does not care that the message says "on behalf of" in the display layer. For DMARC, the key question is simpler: does either SPF or DKIM pass using a domain that matches 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 matches 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 that customer domain. A second workable fix is to use an SPF return-path domain that matches the visible From 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 visible From domain against SPF and DKIM authentication results.
- Visible From: This is the domain the recipient sees, such as customer.com.
- SPF domain: This comes from the envelope sender or return-path, not the visible From address.
- DKIM domain: This is the value in the DKIM signature's d= tag.
- DMARC pass: At least one of SPF or DKIM must pass and match the visible From 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 SPF domain to match the visible From domain.
A rejected message often appears as a 550 5.7.26 error, especially when the customer domain has p=reject. That rejection is the correct receiver behavior. The receiver sees unauthenticated mail for the visible From domain because neither SPF nor DKIM produced a matching authenticated identity.
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 return-path domain passes SPF and matches the visible From domain. DKIM can pass DMARC if the signature verifies and the DKIM d= domain matches the visible From domain.
|
|
|
|
|---|---|---|---|
Customer | ESP domain passes | ESP domain passes | Fail |
Customer | Customer bounce passes | ESP domain passes | Pass |
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, authentication has to tie back to that domain.
What passes authentication
- SPF pass: The sending IP is allowed by the SPF record for the return-path domain.
- DKIM pass: The cryptographic signature verifies for the domain in the d= value.
What passes DMARC
- SPF route: SPF passes and the return-path domain matches From.
- DKIM route: DKIM passes and the d= domain matches From.
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 the customer's 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 domain match through a customer-owned return-path. This means the envelope sender uses a domain under the customer's organizational domain, often a bounce subdomain.
Matching return-path DNS exampledns
bounce.customer.com. CNAME bounces.esp.example. customer.com. TXT "v=spf1 include:esp.example -all"
|
|
|
|---|---|---|
Customer DKIM | Sign with customer domain | Best operational path |
Customer bounce | Use matching return-path | SPF can break on forwarding |
Provider From | Use ESP visible domain | Less brand control |
Subdomain carveout | Set weaker subdomain policy | Use only as transition |
Fix options ranked by reliability
A temporary subdomain policy
If the root domain has p=reject, a customer can route the ESP through a delegated subdomain with a monitoring policy during setup. I treat this as a migration tool, not the end state, because the real goal is authenticated mail that can survive enforcement.
DMARC record during controlled rolloutdns
_dmarc.customer.com. TXT "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@customer.com"
That record keeps the root policy strict while letting subdomain traffic be measured. Once customer-domain DKIM or a matching return-path is working, move the subdomain policy back 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, you do not get the luxury of reading the delivered copy in the inbox. I work around that by sending the same message to a test mailbox that accepts DMARC failures and exposes full headers, or by reviewing aggregate reports from the receiving domains that accepted enough similar traffic to report on it.
- Capture headers: Send the exact message to a mailbox where you can inspect Authentication-Results.
- Find From: Record the visible From domain used for the DMARC check.
- Check SPF: Look at the domain that SPF authenticated, not just whether SPF passed.
- Check DKIM: Look at every DKIM d= value and verify whether one matches the From domain.
- Confirm policy: If the From domain publishes reject, expect receivers to block failures.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The header result I want to see is not merely "spf=pass" or "dkim=pass". I want to see the authenticated domain and the DMARC result together. If SPF passes for esp.example and DKIM passes for esp.example, while the visible From domain is customer.com, the failure is explained.
Also check whether a dynamic SPF service is hiding the real problem. Dynamic SPF can help manage includes and lookup limits, but it does not change which domain SPF authenticated. If the return-path remains under the ESP domain, customer.com still lacks an SPF domain match for DMARC.
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 is useful here because the failure is not a single DNS typo. It is a source-to-domain mapping problem. You need to see which platforms are sending, which domains they authenticate with, and which visible From domains they are using.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall practical fit because it turns DMARC aggregate data into source-level actions. In this specific case, that means seeing the ESP source, checking whether SPF or DKIM has a From-domain match, and getting steps to move the sender toward customer-domain DKIM or a matching return-path.
- Issue detection: Suped flags failing sources and gives concrete steps to fix the authentication path.
- Hosted controls: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce DNS handoffs.
- Operational alerts: Real-Time Alerts help catch a new sender before a reject policy blocks a campaign.
- Broader checks: The platform brings DMARC, SPF, DKIM, blocklist (blacklist), and deliverability insights together.
- MSP scale: The multi-tenancy dashboard works for agencies managing many customer domains.
If you are staging policy changes, Hosted DMARC keeps the rollout controlled. If you need one place to see whether DMARC, SPF, and DKIM are healthy across the domain, run a domain health check. For ongoing enforcement, DMARC monitoring is what shows whether the fix works 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 matching as helpful, 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 the customer 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 a matching 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 softer policy, isolate that work to a controlled subdomain, measure the traffic, then return to enforcement after the source is authenticated correctly.
