Enroll Yahoo's Complaint Feedback Loop against the DKIM signing domain, specifically the value in the d= tag of the DKIM-Signature header. If the visible From domain is marketing.notcutts.co.uk but the DKIM signature says cd.marketing.notcutts.co.uk, the practical fix is to add, verify, and enroll cd.marketing.notcutts.co.uk in Yahoo CFL. The reporting address can be any mailbox you control, but the enrolled sending domain has to match the DKIM d= domain for Yahoo to send ARF reports.
The BIMI answer is different. BIMI starts from the header From author domain, not the DKIM signing domain. If the visible From domain is marketing.notcutts.co.uk, the BIMI TXT record belongs at default._bimi.marketing.notcutts.co.uk. A logo can still fail to appear because Yahoo controls display, and the Sender Hub FAQs tie display to a valid BIMI SVG, an enforced DMARC policy, bulk mail, reputation, engagement, and propagation.
- CFL domain: Use the DKIM d= domain. Yahoo sends ARF reports when that signed domain is enrolled and a recipient reports the message.
- DNS change: If only the CFL enrollment is wrong, add and verify the DKIM domain in SenderHub. If the DKIM d= value is wrong, change the sender platform signing setup and publish its DKIM key.
- BIMI domain: Use the header From domain. A DKIM subdomain does not control the BIMI lookup unless it is also the visible From domain.
- Policy warning: An sp=none tag on marketing.notcutts.co.uk affects deeper subdomains of marketing.notcutts.co.uk, not marketing.notcutts.co.uk itself when it has p=reject.
Which domain Yahoo CFL uses
I split this problem into three identities because email headers hide a lot of detail. The header From domain is the brand-facing author domain. The envelope From domain is the bounce path used by SPF. The DKIM d= domain is the domain that cryptographically signs the message. Yahoo CFL is tied to the DKIM-signed identity, so enrolling the envelope From or header From domain leaves reporting quiet when the message is signed by a different subdomain.
|
|
|
|---|---|---|
CFL | DKIM d= | ARF follows signing |
BIMI | Header From | Logo starts there |
SPF | Envelope From | Return path check |
DMARC | Header From | Policy domain |
Use the domain that matches the protocol being checked.
Do not infer the envelope domain from the visible sender
A mailbox client shows the visible From address, but that is not proof of the envelope From domain or the DKIM d= value. Open the full headers of a real campaign message and inspect the DKIM-Signature header before changing SenderHub enrollment.
- Header: Find the DKIM-Signature line and read the d= tag.
- SenderHub: Add that domain under Domains, complete verification, then enroll it under Complaint Feedback Loop.
- Reports: Expect ARF reports only when Yahoo users report mail signed by the enrolled DKIM domain.
Yahoo Sender Hub CFL enrollment screen showing a verified DKIM domain.
How to verify the DKIM domain
The cleanest check is to send yourself a real message from the same stream that goes to Yahoo recipients, then view the full headers. Do not rely on a setup screenshot from a campaign tool, because the message can have multiple signatures, a vendor signature, or a custom signing domain that differs from the branded From address.
DKIM signature to inspecttext
DKIM-Signature: v=1; a=rsa-sha256; d=cd.marketing.example.com; s=selector1; c=relaxed/relaxed; h=from:to:subject:date; bh=BODY_HASH; b=SIGNATURE_DATA
In that example, the CFL enrollment domain is cd.marketing.example.com. If that domain is not already verified in SenderHub, add it and publish the verification TXT record Yahoo gives you. If your sender platform is signing with the wrong d= domain, change the sender platform configuration first, then publish the DKIM public key for the new selector.
DKIM public key locationdns
selector1._domainkey.cd.marketing.example.com. TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After publishing the key, use a DKIM checker to confirm the selector resolves and the key is syntactically valid. If Yahoo CFL enrollment is still quiet after that, check whether the enrolled domain and the observed d= value are identical, including every subdomain label.
When a DNS-only change is enough
A DNS-only change is enough when the outbound mail already signs with the correct DKIM domain and SenderHub only needs proof that you control that domain. A sender platform change is required when the outbound mail needs to sign with a different DKIM domain.
Why the BIMI logo is not showing
The common trap is expecting the BIMI lookup to follow the DKIM signing domain. It does not. BIMI uses the header From author domain. If the user sees email from marketing.notcutts.co.uk, the BIMI record belongs under marketing.notcutts.co.uk, even when the message is DKIM-signed by cd.marketing.notcutts.co.uk.
Yahoo CFL
- Domain: Enroll the DKIM d= domain.
- Output: ARF complaint reports for reported mail.
- Failure: No reports when the wrong signed domain is enrolled.
BIMI logo
- Domain: Publish under the header From domain.
- Output: A brand logo when the mailbox provider chooses to show it.
- Failure: No logo despite technically valid DNS, often because reputation or cache gates display.
BIMI and DMARC recordsdns
default._bimi.marketing.example.com. TXT "v=BIMI1; l=BIMI_SVG_URI; " "a=VMC_CERT_URI" _dmarc.marketing.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
BIMI readiness checks
A quick way to separate technical requirements from display conditions.
Ready
show eligible
Valid SVG, enforced DMARC, matching header From domain, and reachable certificate URL when used.
Needs work
not eligible
Record exists, but DMARC, SVG formatting, selector, or certificate details need correction.
Display gated
provider decides
DNS is correct, but mailbox provider reputation, engagement, volume, or cache prevents display.
If the records are correct and the logo still does not show in Yahoo Mail, I stop changing DNS and look at display conditions. Yahoo has to see sufficient reputation and engagement for the sending address, and recently changed BIMI records need time to propagate through its systems. A fresh Yahoo webmail session is a better test than an old cached mailbox tab.
Flowchart showing BIMI lookup and display checks from header From domain to logo display.
The sp=none warning in plain English
The sp= tag is a subdomain policy. Its scope is often misunderstood because DNS is hierarchical. A DMARC record at marketing.example.com applies directly to marketing.example.com through p=. Its sp= value applies to names below it, such as news.marketing.example.com, when those names lack their own DMARC record.
DMARC hierarchy exampledns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com" _dmarc.marketing.example.com. TXT "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com"
|
|
|
|---|---|---|
Org DMARC | example.com | Base policy |
Marketing | marketing | Direct policy |
sp tag | children | Fallback |
Child DMARC | child | Overrides |
The sp tag only controls lower names.
What that means for BIMI
If marketing.example.com has p=reject, then marketing.example.com has the enforced DMARC policy BIMI expects. A warning about sp=none concerns deeper domains below marketing.example.com. It does not mean the marketing.example.com BIMI record is on the wrong domain.
A practical troubleshooting workflow
I use this order because it avoids mixing SenderHub enrollment, DNS verification, and BIMI display into one messy task. First prove which domains the message uses. Then fix the Yahoo CFL enrollment. Then validate BIMI under the visible From domain. Last, review reputation and complaint signals instead of repeatedly changing working DNS records.
- Capture: Send a real message from the same campaign stream and save the full headers.
- Read: Record the header From domain, envelope From domain, DKIM selector, and DKIM d= domain.
- Enroll: Add the DKIM d= domain to SenderHub, verify it, and enroll it in CFL.
- Publish: Keep BIMI at the header From domain and confirm the SVG and certificate URL are reachable.
- Monitor: Watch DMARC, DKIM, complaint reports, and reputation before deciding the setup failed.
For a broad check across DMARC, SPF, and DKIM, run a domain health checker before changing records. It is faster to catch a missing selector, weak DMARC policy, duplicate TXT record, or broken DNS lookup up front than to debug the absence of ARF reports later.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's product is useful here because it keeps the authentication evidence in one place. For most teams, Suped is the best overall DMARC platform for this workflow because it combines DMARC monitoring, SPF and DKIM diagnostics, blocklist (blacklist) monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and issue-level fix steps. That matters when the actual problem is not a single DNS record, but a mismatch between what the message signs with, what SenderHub enrolls, and what the mailbox provider displays.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The same workflow also helps with related Yahoo DKIM problems. If the message passes SPF and DMARC but Yahoo still reports DKIM issues, compare the signed domain, selector, and authentication result in the headers before changing policy. This related Yahoo DKIM errors guide covers that specific failure pattern.
Views from the trenches
Best practices
Enroll the DKIM d= domain in Yahoo CFL, then confirm ARF reports reach a controlled mailbox.
Keep the BIMI TXT record on the visible From domain and test after DNS propagation finishes.
Use enforced DMARC on the author domain before treating BIMI display as a client issue.
Common pitfalls
Enrolling the return-path domain leaves Yahoo CFL quiet when DKIM signs with another domain.
Assuming BIMI inherits downward hides missing records on the real visible From domain used.
Reading sp=none as a parent-domain failure causes unnecessary DNS changes and delays.
Expert tips
Capture full headers first, because the visible From line alone does not show every identity.
Separate enrollment fixes from DKIM signing changes, because they happen in different systems.
Treat logo display as probabilistic after setup; reputation and engagement still affect Yahoo.
Expert from Email Geeks says Yahoo CFL should be enrolled on the DKIM d= domain because Yahoo sends ARF reports when that signed domain is enrolled.
2024-08-19 - Email Geeks
Expert from Email Geeks says BIMI starts with the header From domain, so a separate DKIM signing subdomain does not move the logo lookup.
2024-08-19 - Email Geeks
The practical bottom line
Set up Yahoo SenderHub CFL with the DKIM d= domain, not the envelope From domain and not automatically the visible From domain. If your current mail signs as cd.marketing.notcutts.co.uk, that is the domain to verify and enroll for CFL. Change DNS verification in SenderHub if the signing domain already exists. Change the sender platform's DKIM signing configuration only if the message needs to sign with a different domain.
For BIMI, keep the record on the visible From author domain, such as marketing.notcutts.co.uk. If that domain has p=reject and the BIMI SVG is valid, an sp=none warning on that same domain does not automatically block BIMI for that domain. After the technical setup is correct, Yahoo's display decision still depends on mailbox-side reputation, engagement, bulk sending signals, and cache timing.
