My self-hosted ad blocker poisoned Apple's push servers and killed iMessage
Description and use
A self-hosted AdGuard Home in Docker inadvertently blocked Apple Push domains, causing iMessage to fail. The fix involved allowlisting push domains, trimming filter lists, and adjusting DoH upstreams.
Problem
AdGuard Home DNS filtering poisoned Apple’s push server domains, causing iMessage to fail after a short period.
Outcome
iMessage functionality restored after allowlisting Apple push domains, trimming aggressive filter lists, and adjusting DoH upstreams.
Workflow
- 1. Run AdGuard Home in Docker and configure as network DNS.
- 2. Observe iMessage failure after ~30 minutes.
- 3. Diagnose DNS resolution: nslookup courier.push.apple.com returns 0.0.0.0 locally, 17.57.144.152 via 8.8.8.8.
- 4. Identify blocking rules: ||mask.icloud.com^ and ||mask-h2.icloud.com^ in privacy filter list.
- 5. Apply allowlist rules with @@ and $important for Apple push domains.
- 6. Reduce filter lists from 18 to 1 (AdGuard’s own).
- 7. Replace Quad9 DoH upstream with Google DoH next to Cloudflare.
- 8. Verify by comparing local and public DNS lookups and checking container logs for exchange failures.
- 9. Restart AdGuard container and wait for DNS proxy readiness.
Evidence
nslookup courier.push.apple.com returned 0.0.0.0.
The rules doing it were explicit, ||mask.icloud.com^ and ||mask-h2.icloud.com^
First, allowlist rules in user_rules, one per domain, ten for Apple's push and identity stack
- Record date: 2026-10-17T23:41:10.364Z