Among the four major consumer mailbox providers, Apple iCloud applies the strictest filtering on reverse DNS. Gmail tolerates generic PTRs from cloud hosting providers in many contexts. Microsoft weights PTR more heavily than Gmail but with publicly documented criteria. iCloud treats PTR as a hard signal: a missing or generic PTR produces aggressive filtering or outright rejection, with no diagnostic message clearer than a generic 550. The result is a category of unexplained iCloud deliverability gaps that operators chase for days when the root cause is a five-minute DNS fix.
This note covers what makes a PTR record acceptable to Apple's mail systems, why FCrDNS (forward-confirmed reverse DNS) is the actual check rather than just the PTR record on its own, and the practical sequence for getting a branded PTR in place when starting from a generic one. The material applies equally to Apple Mail on macOS and iOS clients, which inherit the iCloud filtering posture for inbound mail. For senders running dedicated infrastructure with control over reverse DNS, the work is straightforward. For senders on shared infrastructure where the PTR is set by the upstream provider, the gap is structural and may not be closable without changing infrastructure.
What iCloud is actually checking
Apple's published guidance on the iCloud Mail Postmaster page lists "valid reverse DNS" as a requirement. The wording is vague but the operational reality is precise. iCloud's inbound filtering runs three checks on every connecting IP. The first is whether a PTR record exists at all for the IP. The second is whether that PTR resolves to a hostname that the forward A record points back to (the FCrDNS check). The third is whether the hostname looks like a mail server hostname rather than a generic ISP-assigned label.
The third check is where most senders fall behind. A connecting IP like 185.123.45.67 might have a PTR that resolves to 185-123-45-67.host.cloudprovider.com. The forward lookup of that hostname returns the same IP, so FCrDNS technically passes. But iCloud reads the pattern of the hostname and treats it as not-a-mail-server, because real production mail servers tend to have intentional hostnames like mta01.example.com, not auto-generated ones with the IP embedded. The penalty for this pattern is heavy filtering but not always rejection, which is why the symptom is unexplained inbox-placement drops rather than outright bounces.
The FCrDNS requirement, in concrete terms
Forward-Confirmed Reverse DNS is a circular check. A sending IP must have a PTR record pointing to a hostname. That hostname must have an A record (or AAAA for IPv6) pointing back to the same sending IP. Both directions must resolve consistently. Either direction missing or pointing elsewhere breaks the check.
The diagnostic is a two-step DNS lookup. From any shell with the dig utility:
# Step 1: get the PTR for the sending IP $ dig -x 185.123.45.67 +short mta01.example.com. # Step 2: get the forward record for that hostname $ dig mta01.example.com A +short 185.123.45.67
If step 1 returns nothing, the PTR is missing. If step 2 returns a different IP from the one in step 1, the FCrDNS is broken. If step 2 returns the same IP and step 1 returned a sensible hostname (not a generic ISP-assigned one), the check passes. The third condition is where iCloud differs from the other major providers: a sensible hostname is required, not just any hostname that round-trips.
What "sensible hostname" means at iCloud
Apple's filtering models look for specific patterns in the hostname returned by reverse DNS. The exact criteria are not published, but observed behaviour across managed PowerMTA traffic during 2025 and 2026 produces a consistent picture.
| PTR pattern | Likely iCloud handling | Example |
|---|---|---|
| Branded mail hostname | Accepted, filtered on other signals | mta01.example.com |
| Subdomain matching sending domain | Accepted | mx.example.com, mail-out.example.com |
| Generic but provider-branded | Heavy filtering | vps123.bigcloudhost.net |
| IP embedded in hostname | Heavy filtering or rejection | 185-123-45-67.host.example.net |
| No PTR record | Likely rejection | NXDOMAIN on the reverse lookup |
| FCrDNS broken | Likely rejection | PTR says X, forward of X says Y |
The bottom three rows of the table are the failure modes. The top two are the goal. The middle row is the gray zone where most shared ESP infrastructure sits: a generic PTR that exists and round-trips but does not look like a mail server in the way iCloud expects. The penalty is degraded placement, sometimes by 10-20 percentage points relative to Gmail or Microsoft for the same sending stream.
Setting a branded PTR on dedicated infrastructure
For dedicated infrastructure operators, setting a branded PTR is a routine task with three sub-steps. The work is done at the registrar or hosting provider that controls the IP block's reverse DNS zone. The exact UI varies by provider but the underlying DNS operations are identical.
First, choose the hostname. Convention is one of mta01.example.com, mx01.example.com, mail.example.com, or a numbered variant if there are multiple sending IPs. Each sending IP gets its own PTR pointing to its own hostname; do not reuse one hostname across multiple IPs.
Second, publish the forward A record for the chosen hostname. This is a normal DNS record in the sending domain's zone, pointing the hostname at the sending IP. Allow propagation time (usually 5-30 minutes for most resolvers).
Third, set the PTR record at the IP block's reverse DNS zone. This is the request that goes to the hosting provider or registrar. Some providers expose this in a web UI; others require a support ticket. The PTR should resolve the IP to the chosen hostname.
Once both records are in place, verify with the two-step dig sequence above. If both queries return consistently, FCrDNS works. Send a test message to a personal iCloud or Apple Mail account and verify it lands in the inbox. The change typically takes effect at iCloud within minutes of DNS propagation; there is no warming period for PTR fixes.
A SaaS sender migrated from shared ESP infrastructure to a dedicated PowerMTA setup in February 2026. SPF, DKIM, and DMARC were configured correctly. Gmail inbox placement settled at 92% within two weeks of warming. iCloud placement stayed at 74% despite identical sending behaviour. The root cause turned out to be a generic PTR set by the cloud provider during VM provisioning, never replaced with a branded one. The fix was a support ticket to the provider asking for the PTR change; total elapsed time was 36 hours, of which 34 were waiting for the provider. After propagation, iCloud placement climbed to 91% over the following week. No other variables changed.
What to do when you do not control the PTR
Shared ESP infrastructure typically does not give the sender control over PTR records. The IP is assigned by the ESP, the PTR is set by the ESP (often generically), and the sender has no path to change it. This is one of the categories of failure modes that dedicated infrastructure removes structurally.
Three intermediate paths exist for senders not yet ready to migrate fully. The first is requesting from the ESP that the PTR be set to a sender-branded hostname rather than a generic one; some premium ESP tiers offer this on dedicated IPs. The second is segmenting iCloud-heavy traffic to a dedicated IP add-on (most ESPs offer dedicated IPs at additional cost) and setting the PTR on that specific IP. The third is accepting the iCloud penalty and treating it as a known cost of the shared-pool decision.
None of these is fully satisfactory. The structural framing is that the PTR control problem is one of the strongest arguments for moving to dedicated infrastructure earlier than the strictly economic break-even might suggest. The qualitative cost of unexplained iCloud deliverability gaps is high; the technical fix when you control the PTR is trivial; the absence of that control on shared infrastructure compounds over time.
The interaction with IPv6
For senders sending over IPv6 (less common in bulk-email contexts but increasing), the PTR requirements double. The IP needs a PTR. The PTR needs to forward-confirm. Plus the hostname needs both A (for IPv4 fallback) and AAAA (for IPv6 self-confirmation) records that match. Apple's mail systems handle IPv6 PTR with the same strictness as IPv4 and in some cases more strictly because the IPv6 record-keeping is younger and providers have less polished defaults.
The practical advice for IPv6 bulk sending in 2026 is to either configure full FCrDNS on both protocols, or to disable IPv6 outbound and send only on IPv4. The middle ground (IPv6 enabled but without proper PTR) is the worst of both worlds: messages from IPv6 sources reach iCloud with broken FCrDNS and get filtered, while IPv4 sources reach iCloud normally. The split signal makes diagnosis harder, not easier.
Closing observation
The PTR record is one of the cheapest pieces of email infrastructure to get right and one of the most expensive to get wrong. A correctly configured branded PTR with working FCrDNS takes between fifteen minutes and four hours to set up depending on the provider's responsiveness. A generic PTR produces a recurring 10-20 percentage point deliverability tax at iCloud that accumulates over every campaign. Senders running dedicated infrastructure should treat PTR configuration as a day-one task, alongside SPF and DKIM. Senders on shared infrastructure should treat the absence of PTR control as a meaningful argument for migration, separate from the volume-based break-even calculation.