Apple Branded Mail Not Showing: Work Through It In This Order

Do these four things first

Before you touch DNS again, rule out the four things that make a working setup look broken.

One. Test on an iPhone. Apple's Branded Mail guide names two places the logo appears: iPhone, and iCloud Mail on the web. Mac and iPad are not on that list. If you have been checking Mail on a MacBook, you have not tested Branded Mail yet.

Two. Send a fresh message. Apple's brand data can take up to five business days to appear in Apple services after approval. An email that landed in your inbox last Tuesday will not retroactively grow a logo.

Three. Send it to an address that does not have you saved in Contacts. A saved contact photo can render instead of the brand logo, and you will spend a day chasing a DNS problem that does not exist.

Four. Open Apple Business and read the status. Not your DNS checker. Apple's own status field is the only thing that tells you whether Apple has approved you.

Step 1: Read the status, and read it exactly

Sign in to Apple Business with a user who has permission to manage Branded Mail. Go to Brands, then Branded Mail. Each domain, subdomain or address you registered has a status of In review, Approved, Not approved, or Incomplete.

Only Approved means Apple will brand your mail. In review means wait. Apple says the review can take up to seven business days, and separately that brand names and logos can take up to five business days to appear in Apple services once approved. Those windows stack. Twelve business days after you hit submit is not a fault condition.

Incomplete usually means domain ownership was never proven. Ownership is a TXT record starting with apple-domain-verification= that Apple generates for you and you paste into your zone file. You have 14 calendar days to get it in place or the whole verification restarts.

One trap that catches people who have already tried to fix this: if you deleted a domain and added it back, treat the old TXT record as dead. Copy the current string from Apple Business, not the old one.

Step 2: The DMARC record has to match Apple's spec, not just be present

DMARC is a DNS record that tells receiving mail servers what to do with mail that claims to be from your domain but fails authentication. It lives at _dmarc.yourdomain.com as a TXT record.

Apple checks for specific values. The v value must be DMARC1. The p value must be quarantine or reject. The pct value must be 100. Apple's own example record is v=DMARC1;p=reject;pct=100;

Two things go wrong here. First, p=none. A monitoring-only policy is where every DMARC rollout starts, and it is where a lot of them quietly stop. Apple will not brand mail from a domain at p=none. If that is your record, this is your answer, and moving to enforcement is a project, not a text edit.

Second, subdomains. If you registered a subdomain such as mail.yourcompany.com but the DMARC record lives on the parent domain, Apple's documentation says the sp value also needs to be quarantine or reject. DMARC already inherits p to subdomains when sp is absent, so this looks redundant. Write it in anyway. Apple lists it as a requirement, and an explicit sp costs you nothing.

Also write pct=100 explicitly rather than leaving it out. RFC 7489 treated a missing pct as 100, and RFC 9989 removed the tag from the standard entirely in May 2026, but Apple's requirements still name it.

Step 3: DKIM, not SPF. This is the one people miss

Apple's requirement is blunt: every email sent to customers needs to be authenticated by DKIM, and authentication by SPF alone is not supported.

This matters because DMARC passes if either SPF or DKIM lines up with your From address. A message can pass DMARC cleanly, land in the inbox, look perfect in every DMARC report you own, and still be ineligible for Branded Mail because the only thing that aligned was SPF.

The specific failure is your sending platform signing with its own domain. Many email services sign outbound mail with a DKIM signature belonging to them, not you, unless you complete their custom or branded DKIM setup and publish the CNAMEs they give you. Your DMARC still passes on SPF. Apple still will not brand it.

How to check. Send a test to a Gmail address, open the message, choose Show original, and look at the DKIM-Signature header and read the d= value. Gmail's Authentication-Results header reports the same signing domain as header.i=, so either line answers the question. If d= is your domain or a subdomain of it, you are aligned. If d= is your email platform's domain, you are not, and no amount of waiting will fix it.

Do this for every sending stream separately. Your marketing platform, your transactional mail, your helpdesk and your own mailbox are four different senders with four different DKIM configurations.

Step 4: Check the domain on the message you actually tested

Branded Mail is scoped to what you registered. Apple lets you register a domain and its subdomains, a single subdomain on its own, or one specific email address such as sales@yourcompany.com.

So the visible From address on your test message has to fall inside that scope. If you registered yourcompany.com but your newsletter goes out as news@mail.yourcompany.com and the parent domain was never verified in a way that covers subdomains, that stream is not registered.

Look at the From address in the message header, not the Return-Path and not the friendly display name. The friendly name is decoration. The domain after the @ is what is checked.

A brand can hold up to 100 domains, subdomains and email addresses in total, so registering each real sending stream is usually the cleaner answer than hoping one entry covers everything.

Step 5: Understand which Apple surfaces render this

Apple's Branded Mail documentation lists iPhone, and iCloud Mail on the web. That is the documented set.

There is also a language condition on iPhone. The device's default language has to be English, Portuguese, French, Italian, German, Spanish or Simplified Chinese. A phone set to Japanese or Dutch will not show it no matter how correct your DNS is.

Apple does not publish a minimum iOS version in the Branded Mail guide. As of August 2026 the current release is iOS 26.6.1, so a reasonably updated iPhone is not your problem. A phone parked several major versions back might be.

Now the part that causes the most confusion. Apple Mail also supports BIMI, which is a separate, older, industry-standard route to the same visual outcome. Apple's BIMI page lists iOS 16, iPadOS 16, macOS Ventura 13 or later, and iCloud.com. BIMI needs a BIMI DNS record and a Verified Mark Certificate or Common Mark Certificate, which are paid. Branded Mail needs neither and is free.

So if a logo shows on your Mac, that is BIMI, not Branded Mail. If your logo shows in Gmail but not on your iPhone, that is also BIMI, and it tells you nothing about your Apple Business status. They are two programs with two registries and two sets of requirements. Passing one does not pass the other.

Step 6: The logo file

If Apple returned Not approved, the image is a likely cause. Apple's image requirements for brand logos are specific.

Accepted formats are HEIF, JPEG, PNG and SVG. Dimensions must be at least 1024 x 1024 pixels and no more than 4864 x 4864 pixels, at a 1:1 aspect ratio. SVG files carry extra rules: valid XML, correct namespace, 15 MB maximum, and no scripts, animation or embedded content.

The requirement people trip over is background. Apple's guidance is to upload an image with a solid background and not to place the logo on a transparent one. Exporting a transparent PNG is the natural instinct for a logo and it is the wrong instinct here.

Apple also asks you to fill the frame sensibly. Do not crop the mark tiny inside a large canvas, and do not push it hard against the edges. This renders at a small size next to a subject line, so legibility beats detail.

Changing the logo means Apple reviews it again. Budget another five business days before you conclude the new file failed.

The checklist

Work down this list. Stop at the first no.

• Status in Apple Business under Brands, then Branded Mail, reads Approved, not In review or Incomplete
• At least seven business days since submission, plus up to five more for the brand to propagate
• The ownership TXT record starting apple-domain-verification= is live, and it is the current one, not a string from a previous attempt
• _dmarc.yourdomain.com exists with v=DMARC1, p=quarantine or p=reject, and pct=100
• If you registered a subdomain and the DMARC record sits on the parent, sp is set to quarantine or reject
• The test message carries a DKIM signature whose d= value is your own domain, read from the DKIM-Signature header or as header.i= in Authentication-Results
• The From domain on that message is one you actually registered, for that specific sending stream
• You tested on an iPhone with a supported default language, or in iCloud Mail on the web, and not on a Mac or iPad
• The recipient does not have the sender saved in Contacts with a photo
• The message is new, sent after approval, not one already sitting in the inbox
• The logo is 1:1, between 1024 and 4864 pixels square, in an accepted format, on a solid background

When it is not your fault

You can pass every item above and still see nothing. Apple approval is Apple's decision, the published timelines are ranges rather than commitments, and there is no dashboard that explains a rejection in detail. Public Apple Support threads from businesses in exactly this position have gone months without a resolution. We cannot promise you a different outcome, and neither can anyone else.

Here is the honest read. If your status says Approved, your DMARC is at enforcement, your DKIM d= is aligned, and you have tested correctly on an iPhone with a fresh message, you do not have a problem to solve. You have a wait. Do not pay anyone to re-do work that is already right.

The time to get help is when you find something in that checklist you cannot fix on your own. That is generally DMARC. Moving a live domain from p=none to p=reject without breaking your invoices, your booking confirmations or your Shopify notifications is the actual work, and doing it carelessly means legitimate mail starts landing in spam.

Working with us

We are Verified Everywhere, part of JWC Apps in San Diego. We ran this whole stack on our own business first, a hockey apparel store called Bench Clearers: DMARC to enforcement, a Verified Mark Certificate through GlobalSign, BIMI live in Gmail, and Meta Verified on a 52,000-follower Instagram account. Every step goes through the platform's official channel. We never ask for your passwords, your government ID documents or your card numbers. If we look at your setup and do not believe we can get you a result, we tell you that and decline the work rather than take the fee.