iCloud “554 5.7.1 rejected due to DMARC policy” — how to fix

Mail you send to @icloud.com or @me.com addresses bounces with “554 5.7.1 … rejected due to DMARC policy” (some servers show 550 instead of 554).

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

iCloud returns 5.7.1 when the visible From domain fails DMARC and that domain publishes an enforcing policy (quarantine or reject) — meaning neither SPF nor DKIM aligned with your From domain for that message. A frequent trap appears right after someone “sets up DMARC”: the Return-Path (MAIL FROM) subdomain their sending service uses doesn't resolve — an NXDOMAIN — which makes SPF fail, and with no aligned DKIM to fall back on, DMARC fails at iCloud specifically because iCloud enforces alignment strictly. Source: Apple Support — If your email is marked as spam or bounced (102322) · verified 2026-07-18.

What to do about it

Step 1. Confirm SPF or DKIM actually aligns with your visible From domain — iCloud needs at least one aligned, not merely “present”.
Step 2. Check that your sending service's Return-Path / bounce subdomain resolves (no NXDOMAIN) — a dead MAIL FROM domain silently fails SPF.
Step 3. If you recently tightened DMARC to quarantine/reject before senders were clean, temporarily drop to p=none, fix alignment, then re-tighten.
Step 4. Run the free check below to see exactly which of SPF/DKIM/DMARC is failing for your domain.

Frequently asked

Is a DMARC-policy bounce my fault or the recipient's?

It's about your domain's authentication, not the recipient's mailbox. A “5.7.1 rejected due to DMARC policy” message means your own From domain failed DMARC and publishes an enforcing policy — so the fix is on your DNS and sending configuration, not the recipient's side.

Do I need special software to read DMARC aggregate reports?

You can open one by hand — they're just XML — but they're designed to be machine-read. A monitoring tool that names each source IP in plain English and tracks pass rates over time is what makes them useful week to week, instead of decoding gzip XML every day.

How long after a fix before a bounce or report clears?

DNS changes propagate within a few hours (up to 48h). For anything you diagnose from aggregate reports, new reports arrive daily, so allow a day or two to confirm a source now passes and aligns.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →