iCloud Custom Domains Ship with Broken Email Security — Here’s How to Fix It

by Cody Chamberlain

Apple makes it easy to use a custom domain with iCloud Mail. The setup wizard walks you through adding MX records, an SPF record, a DKIM CNAME, and a DMARC policy to your DNS. The defaults are designed to be safe and non-disruptive during initial setup — but if you never go back and tighten them, your domain is left open to spoofing.

I found this out when I received a spoofed email — from myself, to myself — that landed directly in my inbox. Every authentication check failed, and yet it was delivered without being flagged as junk.

Here’s what happened, why it happened, and how to fix it in about two minutes.

The Attack

I received an email that appeared to come from my own address at my custom domain. The subject line was a random string. The body contained a short numeric string and a massive tracking pixel — likely a probe to confirm my email address was active and being read.

Digging into the headers told the full story. The email originated from a Linode IP (173.255.231.177), authenticated to a compromised Bluehost shared hosting account (admin@misamajic.com), and was relayed through Proofpoint's Cloudfilter infrastructure into iCloud. The attacker simply set my email address as both the envelope sender and the From: header. That's it. No sophisticated exploit — just typing someone else's address into the "from" field and hitting send.

iCloud Detected It — But Couldn’t Act on It

Here’s where it gets interesting. iCloud’s mail infrastructure did detect the fraud. The headers showed the full picture:

  • SPF: softfail — the sending server wasn’t authorized for my domain
  • DKIM: none — no signature present at all
  • DMARC: fail — failed alignment on both SPF and DKIM
  • ARC: fail
  • Spam score: 4.42, flagged as X-Spam-Flag: yes and X-Suspected-Spam: true

Every single authentication check failed, and iCloud’s own systems correctly scored this as spam. However, two additional headers appeared that changed the outcome:

X-ICLOUD-MAIL-BWL: 1
X-Apple-Action: WL/INBOX

A whitelist rule — likely triggered because the “from” address matched my own iCloud custom domain — moved the message to my inbox. Because my DMARC policy was set to p=none, iCloud had no authorization from my DNS records to reject or quarantine the message based on the authentication failures alone.

The Root Cause: Apple’s Default DNS Configuration

When you set up a custom domain in iCloud Mail, Apple provides specific DNS records to add. Here’s what they recommend for SPF and DMARC:

Apple’s default SPF:

v=spf1 include:icloud.com ~all

Apple’s default DMARC:

v=DMARC1; p=none; rua=mailto:<your-report-address>

Both of these are intentionally permissive.

The SPF record uses ~all (soft fail), which tells receiving servers: "If the sender isn't authorized, mark it as suspicious but don't reject it." The DMARC policy is set to p=none, which tells receiving servers: "Even if authentication fails, don't take any action — just send me a report."

This is standard practice for initial email setup. The p=none DMARC policy is meant to be a monitoring phase — you collect reports, verify that all your legitimate mail is authenticating properly, and then tighten the policy once you're confident everything is working. The gap is that the setup process doesn't guide you through that second step. There's no follow-up prompt in iCloud settings, no reminder to revisit your DMARC policy after a monitoring period, and no indication that your domain is still operating in monitor-only mode.

If you set it and forget it — which is easy to do when everything appears to be working — your domain remains open to spoofing indefinitely.

How to Fix It

If you’re running a custom domain on iCloud Mail, you need to change two DNS records. If you’re only sending email through iCloud Mail (not using third-party services like Mailchimp, SendGrid, or a CRM), these changes are safe to make immediately.

1. Harden Your SPF Record

Change the ~all to -all:

Before:

v=spf1 include:icloud.com ~all

After:

v=spf1 include:icloud.com -all

The -all (hard fail) tells receiving servers to reject mail from unauthorized senders outright, rather than just flagging it as suspicious.

2. Enforce Your DMARC Policy

Change p=none to p=reject:

Before:

v=DMARC1; p=none; rua=mailto:<your-report-address>

After:

v=DMARC1; p=reject; rua=mailto:<your-report-address>

This is the big one. With p=reject, any email that fails DMARC authentication — meaning it fails both SPF and DKIM alignment — will be rejected by the receiving server. The spoofed email I received would never have made it past the gateway.

If you want to be cautious, you can use p=quarantine first, which sends failures to the spam/junk folder instead of rejecting them outright. Run that for a week or two while monitoring your DMARC reports, then move to p=reject once you're confident nothing legitimate is getting caught.

3. Verify DKIM Is Working

Apple handles DKIM signing automatically when you send through iCloud Mail. You should already have a CNAME record like this:

sig1._domainkey.<yourdomain> → sig1.dkim.<yourdomain>.at.icloudmailadmin.com

You can verify it’s working by sending yourself an email from your custom domain to a Gmail address and checking the headers — you should see dkim=pass in the Authentication-Results.

Why This Matters

Email spoofing isn’t just about spam. A spoofed email from your domain can be used for phishing attacks against your contacts, business email compromise, or simply to confirm that your address is active for future targeting. The tracking pixel in the email I received suggests the latter — someone was building a list of verified, actively-monitored email addresses.

With proper SPF and DMARC enforcement, spoofed mail gets rejected before it ever reaches a recipient’s inbox. Without it, you’re relying entirely on the receiving server’s spam heuristics — and as I discovered, those heuristics can be overridden by well-intentioned but poorly-implemented whitelist rules.

Room for Improvement

This isn’t unique to Apple — most email providers default to permissive settings during initial custom domain setup to avoid breaking legitimate mail flow. It’s a reasonable starting point. The opportunity is in what comes after.

Apple is well-positioned to improve this experience because they control both the setup guidance and the receiving mail infrastructure. A few things that would help:

  • A follow-up prompt after a monitoring period (30–60 days) suggesting users tighten their DMARC policy to p=quarantine or p=reject
  • A security health indicator in iCloud Mail settings showing the current state of SPF, DKIM, and DMARC for your custom domain
  • Stricter handling of self-addressed mail that fails authentication, even when the DMARC policy is permissive

The fix on the user side is simple — two DNS record changes that take less than a minute. But most people using iCloud custom domains aren’t email security specialists. Making the path from monitoring to enforcement more obvious would go a long way.

In the meantime, check your DNS records.