Apple Branded Mail setup lets eligible businesses show an approved brand name and logo next to qualifying messages in Apple Mail and iCloud Mail. The visible logo is the end result, but the real work is proving control of the organization, sending domain, DNS, and email-authentication policy.

This guide explains how to prepare a production email domain, configure DMARC safely, verify the domain in Apple Business, submit brand assets, and test the messages you actually send through an SMTP relay or REST email API. It also explains where Apple Branded Mail differs from BIMI, because the two are related but are not interchangeable.

What Apple Branded Mail does

Apple Branded Mail is an Apple Business feature that associates an approved business brand name and logo with email sent from a registered domain, subdomain, or specific email address. When supported conditions are met, recipients can see that branding in the Mail app and in iCloud Mail on the web.

The feature is intended to make legitimate commercial mail easier to recognize. It does not turn a message into a guaranteed inbox placement, does not override spam filtering, and does not make a fraudulent message safe merely because it has a familiar-looking display name. Authentication and reputation still determine whether a message is accepted, filtered, or displayed normally.

Apple’s current documentation places Branded Mail in Apple Business. Older guides may call the portal Apple Business Connect; if you see that name in third-party documentation, treat it as the former name or context for the brand-management experience rather than assuming every current menu label will match.

At a practical level, Apple Branded Mail has four moving parts:

A verified organization and brand in Apple Business.
A commercial sending identity, such as example.com, mail.example.com, or a particular address such as receipts@example.com.
A domain-control TXT record that Apple generates for your organization and asks you to publish.
A DMARC policy at enforcement, with the relevant policy set to quarantine or reject and pct=100.

The requirement for enforcement is important. Apple is not asking only whether you have created a DMARC record. It is asking whether your domain has chosen to tell receiving systems what to do when unauthenticated mail claims to come from it.

Apple Branded Mail is not the same as BIMI

It is easy to confuse Apple Branded Mail with Brand Indicators for Message Identification, or BIMI. Both can result in a logo being displayed near an email, both depend on strong authentication, and both are meant to make impersonation harder. They are still separate systems.

Apple Branded Mail

Apple Branded Mail is configured through Apple Business. You submit business and brand information, add a domain, subdomain, or specific address, then publish the unique DNS TXT record Apple gives you. Apple reviews and approves the submitted email names before they can be used.

For this path, Apple explicitly checks your DMARC DNS record. Your organization also needs to own the brand, use a commercial email domain, and have a mail-supporting DNS record for the domain. Apple documents MX, A, or AAAA as the acceptable mail-supporting record types in its Branded Mail overview.

BIMI

BIMI is an email-industry specification. A sender publishes a BIMI DNS record, typically at default._bimi.example.com, pointing to a logo file and, where required by a mailbox provider, evidence such as a Verified Mark Certificate (VMC) or another accepted evidence document.

For example, a BIMI record can resemble this:

Host: default._bimi.example.com
Type: TXT
Value: v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/vmc.pem;

That is not an Apple Branded Mail verification record. Do not paste it into Apple Business when Apple asks for a verification TXT value, and do not replace an existing BIMI record with an Apple verification token.

Apple Mail supports BIMI in supported Apple Mail and iCloud Mail environments, but BIMI display depends on both sender compliance and the recipient’s mail provider meeting the applicable BIMI requirements. Apple Branded Mail is therefore best treated as an Apple-specific branded-mail route, while BIMI is a separate, broader ecosystem implementation.

The practical choice

If your goal is brand presentation in Apple’s email experiences, implement Apple Branded Mail. If you also want coverage at mailbox providers that support BIMI, evaluate a BIMI deployment separately. In either case, build the authentication foundation first; a logo project is a poor reason to rush a risky DMARC rollout.

Prerequisites to check before changing DNS

Do an inventory before opening Apple Business or changing a single record. Most failed implementations are not caused by the final verification token; they are caused by incomplete knowledge of how the company sends email.

Your inventory should include every system that sends mail using your visible From domain:

Your transactional email provider or internal SMTP relay.
Your marketing automation platform.
Customer-support and ticketing tools.
Invoicing, billing, and subscription software.
Product notification services.
Google Workspace, Microsoft 365, or another employee-mail platform.
Security products that send alerts, reports, or quarantine notices.
Any agency, CRM, event platform, or form builder that sends as your domain.

For each sender, document these values:

Item	Why it matters
Visible From domain	This is the domain DMARC evaluates for alignment.
SMTP envelope sender / Return-Path domain	This matters for SPF alignment.
DKIM signing domain (`d=`)	This matters for DKIM alignment.
DKIM selector	You need it to locate and validate the public DNS key.
Sending IPs or provider include mechanism	Necessary for reviewing SPF.
Mail stream	Separating receipts, marketing, support, and alerts makes troubleshooting safer.

A sender may look legitimate to a human because it displays billing@example.com, yet fail DMARC because the service uses an unrelated Return-Path domain and signs DKIM with its own vendor domain. That message can pass SPF or DKIM in isolation but still fail DMARC alignment.

Also confirm that the domain is suitable for Branded Mail. Apple says consumer mailbox domains such as gmail.com, outlook.com, yahoo.com, icloud.com, and mac.com are not permitted as commercial email domains for this use. A business must use a domain it controls.

Build the authentication foundation first

Apple’s Branded Mail domain-verification guidance explicitly focuses on DMARC. In production, however, DMARC only works as intended when SPF and DKIM are correctly implemented for every legitimate mail stream.

SPF: authorize senders, but keep the record small

SPF is a DNS TXT record that identifies which infrastructure is allowed to send mail for a domain. A simplified example looks like this:

Host: example.com
Type: TXT
Value: v=spf1 include:spf.transactional-provider.example include:_spf.google.com -all

The exact include: values must come from each provider’s official documentation. Never copy placeholder domains from an article, and never guess whether your provider uses an include, fixed IP addresses, or a custom return-path domain.

SPF has an important operational limitation: receivers evaluate no more than 10 DNS-query-causing mechanisms and modifiers. Nested include: statements count toward that limit. An SPF record can look valid in a DNS control panel yet return permerror during real evaluation because it exceeds the lookup limit.

Avoid creating multiple SPF TXT records at the root domain. This is invalid and can cause SPF to return a permanent error. Merge authorized mechanisms into one v=spf1 record instead.

DKIM: sign every stream with a domain you control

DKIM adds a cryptographic signature to the message. The receiving server retrieves a public key from DNS and verifies that the message has not been modified in transit and was signed by an authorized key holder.

A DKIM public key record commonly resembles this:

Host: s1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The selector, shown as s1 above, is chosen by the sender. Your message headers reveal the selector and signing domain in a field like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

For DMARC alignment, the DKIM d= domain must align with the visible From domain. Exact alignment means the domains are identical. Relaxed alignment allows an organizational-domain match, such as a From domain of news.example.com and a DKIM signing domain of example.com.

Use provider-managed DKIM where available, but inspect the delivered headers after enabling it. A dashboard may say “authenticated” while the particular stream you care about is still signing with a vendor-owned domain that does not align.

DMARC: the policy Apple evaluates

DMARC is published as a TXT record at _dmarc and tells receiving servers how to handle messages that fail aligned SPF and DKIM authentication. It also enables reporting when you publish report destinations.

Apple’s current Branded Mail requirement is clear:

v must be DMARC1.
p must be quarantine or reject; or, for a registered subdomain using its parent’s record, sp must be quarantine or reject.
pct must be 100.

A minimal compliant record for an organizational domain is:

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=reject; pct=100;

A more operationally useful record adds aggregate reporting:

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-aggregate@example.com; adkim=r; aspf=r;

The second example uses relaxed alignment (adkim=r; aspf=r), which is a common initial policy. It is not automatically correct for every organization. Strict alignment, represented by s, is more restrictive and can be appropriate after you have audited all sending services.

Do not copy a rua mailbox unless you control it. Aggregate DMARC reports are XML files, usually compressed, and the receiving address needs a process or a reporting service that can handle them. A dedicated reporting mailbox or a DMARC analytics platform is usually safer than sending reports to a shared employee inbox.

Roll out DMARC without breaking legitimate mail

A requirement for p=quarantine or p=reject with pct=100 means Apple Branded Mail is not compatible with a long-term monitoring-only record such as:

v=DMARC1; p=none; pct=100;

That does not mean you should change a production domain from p=none to p=reject blindly. The safe sequence is to measure first, correct the failures, and enforce only after every material sender is understood.

A cautious rollout sequence

Publish a DMARC record with p=none and rua= reporting if you do not have one.
Collect reports long enough to capture monthly mail, invoices, alerts, and other less-frequent streams.
Identify every legitimate source failing alignment.
Repair SPF and DKIM alignment, rather than adding broad exceptions.
Move to p=quarantine; pct=100 once legitimate mail is reliably aligned.
Monitor complaints, bounces, delivery events, and DMARC reports.
Move to p=reject; pct=100 when you are confident unauthenticated mail should be refused.

A staged policy can be useful before the Apple submission stage:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-aggregate@example.com;

But this does not meet Apple’s stated pct=100 requirement. Treat it as a temporary risk-reduction step, not the final configuration.

Understand the DMARC pass rule

DMARC passes when either SPF passes and aligns, or DKIM passes and aligns, with the visible From domain. Both do not have to pass, although operating with both aligned is more resilient.

For example:

From: receipts@example.com
Return-Path: bounce@mailer.vendor.example
SPF: pass for mailer.vendor.example
DKIM: pass with d=example.com

SPF is not aligned, but DKIM is aligned, so DMARC can pass.

In a second example:

From: receipts@example.com
Return-Path: bounce@example.com
SPF: pass for example.com
DKIM: fail

SPF is aligned, so DMARC can still pass. This is why either authentication channel can satisfy DMARC, but relying on only one makes a sender more fragile when providers, keys, forwarding behavior, or routing change.

Configure the domain and brand in Apple Business

Once your email authentication is ready, configure the Apple side. The exact appearance of a portal can change, so use Apple’s current guide as the authority for current navigation and roles. The documented workflow is to sign in to Apple Business with a user who has permission to manage Branded Mail, then open Brands > Branded Mail and choose the setup flow.

Register and verify the organization

Apple requires the business to be registered and verified. Make sure the legal business information, contact details, and brand ownership evidence are accurate before submission. A mismatch between your company identity, public website, logo ownership, and claimed sending domain can delay approval.

If an agency, franchisee, or email consultant is doing the technical work, establish responsibilities in writing. The organization should retain ownership of the Apple Business account, DNS zone, logo source files, and sending-domain configuration. A third party can be delegated access, but it should not become the sole owner of your production identity.

Create or select the brand

Apple’s setup flow requires a brand and a logo before Branded Mail can be configured. Use the same core brand identity customers see on your public site, invoices, support pages, and account portal. A radically different logo or a display name unrelated to the sending domain creates a review risk and may confuse recipients even if it is approved.

Use a clean, high-resolution original asset. Avoid adding tiny taglines, telephone numbers, campaign dates, QR codes, or unreadably thin details to a logo intended for inbox display. Email-client avatars are small, so a simplified mark generally performs better than a busy lockup.

Add the correct sending scope

Apple lets you configure branding at more than one scope:

A root domain, such as example.com.
A subdomain, such as mail.example.com or news.example.com.
A specific mailbox, such as receipts@example.com.

Choose the least broad scope that accurately represents your use case. If every message from example.com is sent by the same organization under the same consumer-facing brand, a domain-level setup may be appropriate. If a parent company uses several brands or sends independent product mail from subdomains, configure those identities separately.

This decision has governance implications. A broad root-domain approval may be convenient today but can become confusing after acquisitions, rebrands, franchise arrangements, or the addition of new product lines. The Apple documentation also limits a brand to a combined total of 100 domains, subdomains, and email addresses, so establish a sensible identity model rather than adding entries casually.

Publish Apple’s generated TXT verification record

When you add the identity, Apple provides a unique TXT record. Copy it exactly. It is organization-specific and must be treated as an opaque value, not something you manually recreate from a template.

Apple’s domain-verification documentation describes two related verification patterns:

A top-level domain verification can cover subdomains.
A subdomain-specific verification can be used when you want to verify only that subdomain.

Apple also documents a generated domain-verification value that can look conceptually like this:

Host: example.com
Type: TXT
Value: apple-domain-verification=0RaNdOm1LeTtErS2aNd3NuMbErS4

That sample is illustrative only. The exact host and value shown in your Apple Business account are authoritative. Do not publish the sample value above.

A DNS provider may ask for only the record name rather than the full domain. For example, when editing the example.com zone, entering _dmarc may create _dmarc.example.com. Other providers expect the full hostname. Verify the rendered FQDN before saving, especially for DKIM, DMARC, and verification records.

DNS implementation details that prevent common mistakes

DNS changes often fail because the record is technically present but published at the wrong name, quoted incorrectly, duplicated, or hidden behind the wrong authoritative nameservers.

Use the right record type and hostname

For the Apple verification value, publish a TXT record exactly as Apple instructs. For DMARC, publish one TXT record at _dmarc.your-domain. For DKIM, publish the provider-issued record at selector._domainkey.your-domain.

Do not use a CNAME in place of a required TXT record unless the service specifically tells you to do so. Some email providers use CNAME delegation for DKIM. That is normal when documented by the provider, but it does not mean Apple’s verification TXT record can be substituted with a CNAME.

Avoid duplicate DMARC and SPF records

At a given _dmarc.example.com hostname, publish one DMARC TXT record beginning with v=DMARC1. Multiple DMARC records can cause receivers to treat the policy as invalid.

Likewise, publish only one SPF record beginning with v=spf1 at a domain. If two teams add separate SPF TXT records, SPF may fail even though each individual record looks reasonable.

Check DNS from outside your control panel

A successful save confirmation is not verification. Query public DNS after the change:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short TXT s1._domainkey.example.com
dig +short MX example.com

On Windows PowerShell, you can use:

Resolve-DnsName -Type TXT _dmarc.example.com
Resolve-DnsName -Type MX example.com

You can also use tools such as MXToolbox for a quick DMARC, SPF, DKIM, and MX review. For the final check, inspect live DNS and a delivered message rather than relying only on a score or badge from a third-party scanner.

DNS propagation is not instantaneous. Many changes appear within minutes, but TTL settings, resolver caching, and DNS-provider behavior can make observations inconsistent. Do not repeatedly add and delete records while waiting; that can extend confusion and make it difficult to identify the intended final state.

Send production-like test messages

Branded Mail approval and email authentication are not reasons to test only with a blank “hello world” email. Send messages that resemble the flows your customers receive: receipts, password resets, account verification, notifications, and marketing mail where applicable.

Use a test recipient that can display full headers. Send through the same provider account, API key, SMTP credentials, sending IP pool, and From identity that production uses.

For a transactional platform, test both supported transport paths if your architecture uses both:

REST API: Confirm the API request succeeds and record the provider’s message ID.
SMTP relay: Confirm authentication, TLS, envelope sender, and message submission behavior.

A typical successful SMTP conversation ends with a 250 response after the message data is accepted, such as:

250 2.0.0 Message accepted for delivery

That response means the relay accepted the message for delivery. It does not prove the recipient’s mailbox accepted it, placed it in the inbox, or displayed your branding.

For an HTTP email API, a 202 Accepted commonly means the provider accepted the request for asynchronous processing. A 200 OK or 201 Created may be used by some APIs, while 400 Bad Request, 401 Unauthorized, 403 Forbidden, 422 Unprocessable Content, and 429 Too Many Requests are examples of failures that require different remediation. Consult your provider’s SMTP and REST sending documentation for its exact response model rather than assuming status codes are universal.

What to inspect in the delivered headers

In the delivered message, find Authentication-Results. A healthy result may resemble this:

Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com header.s=s1;
  dmarc=pass header.from=example.com

Check all of the following:

dmarc=pass is present for the visible From domain.
At least one of SPF or DKIM is aligned with that From domain.
The actual From domain is the identity you registered in Apple Business.
DKIM is signed by the intended domain and selector.
The Return-Path is the expected custom bounce domain, if your provider supports one.
No unexpected sender rewrites happened between application, provider, and recipient.

Mail-tester.com can be useful for an additional deliverability and configuration review. Use it as a diagnostic aid, not as proof of Apple Branded Mail eligibility or inbox placement. A passing score cannot compensate for missing Apple approval, incorrect registration scope, a noncompliant DMARC policy, or a recipient environment that does not support a particular display treatment.

Troubleshooting Apple Branded Mail setup

When branding does not appear, separate the issue into four categories: Apple account status, DNS verification, authentication, and recipient display conditions.

Apple says the domain or email address is incomplete

First, confirm that the unique TXT record supplied by Apple is published at the exact requested hostname. Check authoritative DNS with dig, not only the DNS provider’s web interface.

Then check whether the identity was added at the intended scope. A verified root domain does not mean that every unrelated From address automatically maps to the brand configuration you expected. Review whether you added the root domain, a particular subdomain, or an individual address.

Apple rejects the DMARC requirement

Inspect the live record at _dmarc.example.com. Common issues include:

p=none instead of p=quarantine or p=reject.
pct=25, pct=50, or another value below 100.
A malformed tag, invisible character, or duplicate DMARC TXT record.
Registering a subdomain while relying on a parent record that has no suitable sp=quarantine or sp=reject policy.
Publishing the record at dmarc.example.com instead of _dmarc.example.com.

For a subdomain, remember that DMARC discovery can fall back to the organizational domain’s record. If you want the parent policy to enforce subdomain treatment explicitly, use sp. For example:

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-aggregate@example.com;

Your message passes provider checks but fails DMARC at the recipient

This typically indicates an alignment issue, not an absence of SPF or DKIM. Compare the visible From domain with the SMTP envelope sender and DKIM d= domain in the recipient headers.

A common fix is enabling the email provider’s custom return-path domain for SPF alignment, enabling domain-authenticated DKIM, or changing the application’s From address to an approved domain. Do not fix the symptom by weakening DMARC to p=none; that defeats the protection Apple expects and leaves your domain easier to impersonate.

The message is delivered but branding is not visible

Do not treat this as a pure DNS failure. Check whether Apple has approved the email identity, whether the recipient is viewing the message in a supported Apple experience, whether the client language and other feature conditions apply, and whether the message truly came from the registered identity.

Apple notes that Branded Mail display is available on iPhone when one of several supported default languages is selected, and in iCloud Mail on the web. It also notes that brand review can take up to seven business days. Build that review period into launch planning rather than promising an immediate appearance after DNS verification.

Operational practices after approval

Approval is not the end of the work. Treat branded mail as a production identity control with a change-management process.

Keep ownership and records current

Maintain a small record of:

Apple Business account owners and delegated administrators.
The brand name and logo asset version.
Every approved domain, subdomain, and address.
DNS record locations, owners, and TTLs.
Current DMARC policy and report destination.
DKIM selectors and key-rotation dates.
Every provider authorized in SPF.

This record is especially valuable during rebrands, vendor migrations, incidents, and acquisitions. It prevents one team from removing a “mysterious” TXT record that another team needs for Apple verification or email authentication.

Separate streams when the business needs separation

A dedicated transactional subdomain such as notify.example.com can make sender governance easier. It lets you isolate operational mail from marketing campaigns, use independent DKIM selectors, and monitor reputation more clearly.

However, subdomain separation is not a substitute for good authentication. Every stream still needs valid SPF and DKIM, and the relevant DMARC policy must satisfy Apple’s requirements. Plan the Apple identity scope alongside your domain architecture instead of bolting it on later.

Monitor DMARC reports and delivery signals

Aggregate reports reveal attempted use of your domain, valid and invalid authentication outcomes, and sending infrastructure that may not appear in your application inventory. Review them after provider changes, new marketing tools, email-template migrations, and DNS updates.

Also monitor your email provider’s delivery events. A steady rise in 550 5.7.1 policy-related rejections, spam-folder placement, complaints, or DKIM failures can signal a configuration change before customers report missing mail.

A practical launch checklist

Use this checklist before considering an Apple Branded Mail setup complete:

Conclusion

Apple Branded Mail setup is primarily an email-identity project, not a logo-upload task. The most reliable implementation starts by mapping every sender, establishing aligned SPF and DKIM, enforcing DMARC at quarantine or reject with pct=100, and only then completing Apple’s domain and brand verification workflow.

That order protects your domain beyond Apple Mail. It reduces spoofing exposure, makes provider migrations easier to validate, and creates a clearer operational model for every transactional and campaign message your business sends.

FAQ

Do I need BIMI to set up Apple Branded Mail?

No. Apple Branded Mail and BIMI are separate implementations. Apple Branded Mail is configured through Apple Business and uses Apple’s organization, brand, domain, and DMARC verification process. BIMI uses its own DNS record, logo format, and evidence requirements.

What DMARC record does Apple Branded Mail require?

Apple requires v=DMARC1, an enforcement policy of p=quarantine or p=reject—or an appropriate sp=quarantine or sp=reject policy when registering a subdomain through a parent record—and pct=100. A minimal example is v=DMARC1; p=reject; pct=100;.

Can I use Apple Branded Mail with an email API or SMTP provider?

Yes. The email transport is not the key issue. Whether your application sends through a REST API or SMTP relay, the final delivered message must authenticate correctly and align with the From domain or address you registered with Apple.

Why does my email show DMARC pass but no Apple branding?

DMARC pass is necessary authentication evidence, not proof that branding will display. Check Apple’s approval status, the exact registered domain or address, the recipient’s Apple Mail environment, and whether the message was sent from the intended production identity.

How long does Apple Branded Mail approval take?

Apple says the brand review process can take up to seven business days. DNS verification may be faster, but launch plans should account for both DNS propagation and Apple’s approval timeline.

Apple Branded Mail Setup: DNS, DMARC, and Verification Guide