What are Apple's requirements for email authentication and domain registration?
Updated on 19 Oct 2026: We clarified Apple's domain verification requirements and why Branded Mail still lists pct=100.
Apple applies different rules to Private Email Relay and Branded Mail. Bulk mail sent to iCloud Mail has another set of requirements. For Sign in with Apple Private Email Relay, register each outbound domain, subdomain, or individual source address in Apple Developer. Registered domains need an SPF record, and each message must pass SPF or DKIM. For Apple Business Branded Mail, verify domain ownership with Apple's TXT record and publish an enforced DMARC policy. Bulk senders to iCloud Mail must use SPF and DKIM, publish a DMARC policy, and follow Apple's sender requirements.
The confusing part is that Apple uses similar words across different services. In the relay case, registration means Apple has an allow-list of the sources allowed to send to private relay addresses. Authentication means Apple can prove that the message came through a domain you registered. In the Branded Mail case, Apple checks DMARC because the brand display depends on domain ownership and abuse resistance. Normal iCloud Mail delivery uses authentication together with sender reputation and mailing practices.
- Relay: Register each outbound domain, subdomain, or source address, publish SPF for registered domains, then pass SPF or DKIM.
- SPF path: The exact envelope sender domain must be registered and must pass SPF.
- DKIM path: The DKIM d= domain must exactly match the registered visible From domain, and the valid signature must cover the From header.
- Branded Mail: Publish DMARC with quarantine or reject. Apple's Branded Mail checklist also lists pct=100.
Apple requirements by service
For Private Email Relay, Apple's own relay documentation says you need to register outbound email domains so Apple will accept messages to users' private relay addresses. Registered domains need SPF records, and Apple authenticates each message with SPF or DKIM. If the MAIL FROM domain is yours, SPF can satisfy the message check. If your provider uses its own MAIL FROM domain, DKIM on your registered visible From domain is required for the relay check.
The relay requirement splits into two questions. First, did Apple know this domain, subdomain, or source address was going to send? Second, did the message prove control of that source through SPF or DKIM? A pass on only one of those questions still leaves the message at risk of a relay bounce. Apple lists source limits too: individual developer accounts can register up to 32 email sources, and organization accounts can register up to 100. An Account Holder or Admin manages the relay configuration.
|
|
|
|
|---|---|---|---|
Sources | SPF or DKIM | SPF record for registered domains | |
Branded Mail | Domain ownership TXT record | DMARC | quarantine or reject |
Bulk mail to iCloud Mail | None | SPF, DKIM, and DMARC policy | Bulk sender rules and reputation |
Apple requirements by service
Apple Developer Private Email Relay email source registration and authentication status.
Do not assume the organizational root domain covers every sending path. If mail uses newsletter.example.com in the From header, bounces.example.com in the MAIL FROM, and support.example.com for helpdesk replies, each path needs to be evaluated. Apple specifically calls out domains, subdomains, and individual email addresses as separate sources.
Private Email Relay and Branded Mail
Most confusion starts when teams read Apple's relay rules and Apple's Branded Mail rules as one requirement. They are related because both depend on DNS authentication, but they answer different product questions. Relay is about whether Apple will forward your app's email to a user's private relay address. Branded Mail is about whether Apple will display your verified brand in Apple Mail.
Private Email Relay
This applies when users choose Sign in with Apple and hide their real email address. Your app sends to an Apple relay address, then Apple forwards the message to the user's real inbox if the sender source is registered and authenticated.
- Register: Add the domain, subdomain, or source address in Apple Developer.
- Authenticate: Publish SPF for registered domains, then pass SPF for the exact MAIL FROM domain or DKIM for the From domain.
- Bounce risk: Unregistered or mismatched sources can fail even when normal inbox mail works.
Apple Business Branded Mail
This applies when an organization wants brand identity to appear in Apple Mail. Apple's Branded Mail guide checks DMARC on the sending domain.
- Register: Verify the email domain in Apple Business.
- Authenticate: Publish DMARC with p=quarantine or p=reject, or use sp for subdomains.
- Coverage: Include pct=100 to match Apple's published Branded Mail checklist; this is a legacy tag.
A domain can be ready for one workflow and not the other. A sender with solid DKIM can pass relay authentication, yet still fail Branded Mail because DMARC is still at p=none. An enforced DMARC policy can satisfy Branded Mail's authentication requirement, yet relay mail can bounce if the exact sending subdomain was never registered in Apple Developer.
What iCloud Mail requires from bulk senders
Sending bulk mail to iCloud Mail addresses does not require Apple Developer source registration. Apple's postmaster rules say bulk senders must meet all listed requirements or messages can be rejected. iCloud Mail authenticates inbound email with SPF and DKIM, and it honors the DMARC policy published by the sending domain.
- Authentication: Use SPF and DKIM for bulk mail, and publish a DMARC policy for the sending domain.
- Sending identity: Publish reverse DNS (PTR records), keep sending domains and IP addresses consistent, and use a recognizable From name and address.
- Consent: Send only to explicit subscribers and provide an unsubscribe link that works immediately.
- List hygiene: Remove inactive recipients, suppress repeated bounces, and do not reactivate unsubscribed addresses.
- Forwarding and errors: Add ARC headers to forwarded mail, track temporary and permanent SMTP errors, and act on each error class.
- Message format: Follow RFC 5321 for SMTP and RFC 5322 for email message formatting.
Apple's published bulk sender requirements do not state a 5,000-message daily threshold or a numerical spam complaint limit. They require an immediate unsubscribe link without specifying RFC 8058 one-click unsubscribe. They also do not require a quarantine or reject DMARC policy for ordinary bulk delivery.
iCloud Mail has no allow-list or feedback loop for bulk senders. Its filters use IP and domain reputation, content checks, and user feedback. Keep marketing and transactional mail on consistent but separate streams, and use the SMTP response from iCloud Mail as the starting point for delivery troubleshooting.
Custom Email Domain is a separate setup
iCloud+ Custom Email Domain lets a domain owner host personalized addresses with iCloud Mail. Apple requires the MX records, a personal TXT verification value, SPF authorization for iCloud, and a DKIM CNAME shown during setup. These records route and authenticate mail hosted by iCloud. They do not register an app's senders for Private Email Relay or verify a domain for Branded Mail.
Your domain's DMARC policy applies to messages using that domain in the visible From address. It does not determine how iCloud filters unrelated incoming senders. This scope is defined in RFC 9989.
SPF, DKIM, and DMARC DNS records
Do not treat SPF or DKIM as a single route for the whole domain. Use both when possible. SPF proves the sending infrastructure is allowed for the envelope sender domain. DKIM verifies the signature and integrity of the signed message content using the signing domain's public key. DMARC passes when SPF or DKIM passes and the authenticated domain matches the visible From domain under the configured matching rules. In the default relaxed mode, the domains can share an organizational domain; strict mode requires an exact match. The relay DKIM check requires an exact match regardless of the DMARC mode.
If your team needs the conceptual refresher, the SPF, DKIM, and DMARC breakdown explains how the standards work together. For Apple, the main point is more specific: Apple cares about the exact domain used in the sending path, not only the parent brand domain.
Illustrative DNS records for relay and Branded Maildns
example.com. 3600 IN TXT "v=spf1 include:esp.example -all" bounces.example.com. 3600 IN TXT "v=spf1 include:esp.example -all" s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIB..." _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com"
Replace the example provider domain and abbreviated DKIM key with your sender's actual values, and use a reporting address you control. Publish only one SPF record at each domain name. The pct=100 tag is included for Apple's documented Branded Mail requirement.
The DNS can look right while the live email path is wrong. Apple checks the message it receives, so the actual MAIL FROM, From header, and DKIM signature matter more than the record you expected your provider to use.
- MAIL FROM: Register this exact domain if you expect SPF to satisfy the relay check.
- From header: Make sure the visible sender domain is registered if DKIM is the main path.
- DKIM d=: Use a signing domain that exactly matches the visible From domain for relay checks.
- DMARC pct: Apple's Branded Mail documentation still lists pct=100; it is no longer a current DMARC sampling control.
How to meet the relay requirement
Start with an inventory of every application, marketing system, helpdesk, product notification service, and billing system that sends mail to users who can choose Sign in with Apple. The person who added the Apple sign-in button is not always the person who owns email DNS, so this step prevents silent gaps.
- List sources: Collect every From domain, MAIL FROM domain, and DKIM signing domain used by the app.
- Register sources: In Apple Developer, open Certificates, Identifiers & Profiles > Services > Sign in with Apple for Email Communication > Configure, then add each required source under Email Sources.
- Fix SPF: Authorize the sending provider on the exact MAIL FROM domain, not only the root domain.
- Fix DKIM: Sign with the same domain users see in the From address whenever your provider allows it.
- Monitor DMARC: Use reports to confirm legitimate sources before enforcement. DMARC is optional for Private Email Relay.
- Send tests: Trigger real app messages to private relay addresses and inspect the resulting headers.
Keep Apple's private relay delivery notifications enabled for the Account Holder and team admins. Apple sends these notices when it detects messages that the relay could not deliver, which gives the team an early signal before users report missing mail.
Before changing policy, run Suped's domain health check to catch obvious DNS mistakes across SPF, DKIM, and DMARC. That will not replace a real message test, but it quickly finds missing records, multiple SPF records, and DMARC syntax errors.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the DNS check, send a real message through the same application path Apple users will trigger. Look at the Authentication-Results header, the Return-Path domain, the From domain, and the DKIM d= value. If those domains do not match what you registered with Apple, fix the sending configuration before assuming Apple is blocking a valid message.
Suped's DMARC reporting platform groups authentication results by source so you can review legitimate senders before changing policy. It does not check which sources are registered in Apple Developer.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
That source-level view matters once more teams send mail. A new helpdesk subdomain or billing provider can pass ordinary inbox delivery while still failing Apple's exact registration requirement. Compare sources identified in DMARC reports with Apple Developer registrations, then test delivery through the relay.
DMARC requirements for Apple Business Branded Mail
For Apple Business Branded Mail, the requirement is strict because Apple checks DMARC on the domain. The record needs v=DMARC1, and either p=quarantine or p=reject. If the DMARC record sits on the parent domain and you are registering subdomains, sp=quarantine or sp=reject can satisfy the subdomain policy condition. Apple's published checklist also lists pct=100.
Apple's pct requirement and current DMARC
RFC 9989 removed pct and marked the tag historic. Do not rely on pct to limit enforcement during a rollout. Apple's Branded Mail verification guide still explicitly lists pct=100, so retain it when following that published setup. It is a legacy compatibility setting.
Apple Business DMARC readiness
Use this as a quick policy benchmark before registering a domain for Branded Mail.
Not ready
p=none
DMARC is missing, has syntax errors, or uses p=none only.
Staging
monitoring
DMARC reports are active and sources are being fixed before enforcement.
Authentication ready
p=quarantine or p=reject
Enforced DMARC plus Apple's documented pct=100 setting; domain ownership verification is separate.
Do not enforce DMARC on a domain that has unknown senders. Use DMARC monitoring to map legitimate sources first, then move toward enforcement when the failure pattern is understood. Suped's DMARC reports group results by source, while alerts expose unexpected authentication changes during the rollout.
If DNS access is slow or split across teams, Suped's Hosted DMARC helps stage policy changes with less DNS churn. A focused DMARC checker is useful when you only need to validate syntax, tags, and the published policy before submitting the domain to Apple.
How to verify domain ownership for Branded Mail
Branded Mail needs a separate ownership check alongside DMARC. Apple's domain verification instructions require a unique TXT record. Verifying the root domain covers its subdomains for ownership; verifying one subdomain covers only that subdomain. Private Email Relay still requires separate source registration.
- Sign in to Apple Business with permission to manage Branded Mail and organization domains, then open Brands > Branded Mail.
- Select Add and enter the domain or email address. For initial setup, select Set Up Branded Mail and choose the brand.
- Copy Apple's unique TXT record into DNS at the requested name. Keep the ownership token separate from the SPF and DMARC TXT records.
- After the record is publicly available, select Verify, then Done. Confirm that the applicable DMARC policy also meets the Branded Mail requirements.
Complete organization verification and the brand setup too. Apple's Branded Mail setup instructions require approval of email names before use; a valid DMARC record alone does not complete that approval.
Common relay and Branded Mail failures
The most common mistake is registering the brand domain while the live message uses a different technical domain. Apple does exact checks in the relay workflow. If the Return-Path is bounce.mail.example.com but Apple only has example.com registered, SPF cannot satisfy the relay's registered-domain check. A correctly configured DKIM path can still succeed.
Check these issues first when Apple relay mail bounces or when Branded Mail verification fails.
- Wrong source: The registered domain is example.com, but the message uses mail.example.com.
- Provider bounce: The email provider owns the MAIL FROM domain, so SPF cannot prove your domain.
- DKIM mismatch: The DKIM d= domain is a provider domain instead of the visible From domain.
- Soft DMARC: The policy applicable to the registered domain is p=none or sp=none instead of quarantine or reject.
- Legacy pct setting: A pct value below 100 conflicts with Apple's published Branded Mail checklist, even though the tag is historic in current DMARC.
When testing, use the exact production route. A test sent from an admin console often uses a different sender identity than password resets, receipts, or app notifications. If only production traffic fails, compare headers between the working test and the failing message.
Views from the trenches
Best practices
Register the exact bounce domain and visible From domain before relay testing with Apple.
Keep DKIM on the visible From domain even when SPF passes through a custom bounce path.
Use DMARC reports to check source failures before enforcing policy for Apple Business.
Common pitfalls
Assuming the root domain covers every subdomain causes relay bounces for split senders.
Publishing SPF for the wrong MAIL FROM domain leaves Apple with no exact source match.
Treating Branded Mail rules as relay rules sends teams toward the wrong DNS fix.
Expert tips
Test a real message because DNS can look correct while the sending path uses another domain.
Apple Business still documents pct=100; do not use pct to stage a DMARC policy rollout.
Centralize source ownership so web and lifecycle teams do not register scattered fragments.
Marketer view
Marketer from Email Geeks says the Apple relay setup is easy to misread because registration and authentication are described in one workflow.
2020-03-06 - Email Geeks
Marketer view
Marketer from Email Geeks says either the MAIL FROM domain or the visible From domain needs to be registered before relay delivery works.
2020-03-06 - Email Geeks
Frequently asked questions
No. Apple's relay check requires a registered source, an SPF record for registered domains, and each message to pass SPF or DKIM. DMARC is not required by this relay check, but it helps you monitor authentication and protect the visible From domain.
Yes. Apple Business Branded Mail requires v=DMARC1 and a quarantine or reject policy. Subdomains can use an enforced sp policy on the parent domain. Apple's checklist also lists pct=100, although RFC 9989 marks pct historic. Domain ownership verification is a separate requirement.
For Private Email Relay, register every source domain or subdomain that your app uses for email communication. If another subdomain sends later, register and authenticate that source before relying on it. Branded Mail ownership verification differs: a root-domain TXT verification can cover its subdomains.
Yes, when the exact MAIL FROM domain is registered and passes SPF. If your email provider uses its own MAIL FROM domain, use DKIM with your visible From domain instead. Apple recommends using both SPF and DKIM when possible.
Apple requires bulk senders to use SPF and DKIM and publish a DMARC policy. It also requires explicit subscriber consent, working unsubscribe handling, reverse DNS, consistent sender identity, bounce processing, and ARC headers on forwarded mail.
Normal inbox delivery and Apple relay delivery are not the same check. Relay delivery can bounce when the message uses an unregistered source, the MAIL FROM domain does not match, or DKIM signs with the wrong domain.
