# Fix email authentication for apple.com

You are working on the DNS and mail configuration for apple.com.
Measured by MailAuthWatch on 17 Oct 2026 from public DNS. Grade A (90/100).
Report: https://www.mailauthwatch.com/check/apple.com

## What is published right now (do not assume anything else)
- SPF (TXT apple.com): v=spf1 include:_spf.apple.com include:_spf-txn.apple.com ~all   — valid, 2 of 10 lookups
- DMARC (TXT _dmarc.apple.com): v=DMARC1; p=quarantine; sp=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;
- DKIM: selector1._domainkey (1024-bit), selector2._domainkey (1024-bit)
- MX: mx-in.g.apple.com, mx-in-ma.apple.com, mx-in-rn.apple.com, mx-in-sg.apple.com, mx-in-hfd.apple.com, mx-in-vib.apple.com  → iCloud Mail
- Nameservers: a.ns.apple.com, b.ns.apple.com …  → DNS host not recognised

## Tasks, in order of impact
### 1. 2 DKIM keys are 1024-bit.
Why: Selectors selector1._domainkey, selector2._domainkey are under 2048 bits, which some receivers already downgrade. 
Rotate to a 2048-bit key at the sending service.

## Rules
- Publish exactly one SPF record; never add a second v=spf1 TXT.
- Do not remove any include: or ip4: you cannot account for; mail may depend on it.
- Do not set DMARC to p=reject in one step; stage through p=none → quarantine → reject.
- Show the planned DNS changes as a diff (record, old value, new value) before applying them.
- If you cannot access the DNS provider or iCloud Mail, stop and say exactly what access you need.

## Verify
  dig +short TXT apple.com
  dig +short TXT _dmarc.apple.com
Then open https://www.mailauthwatch.com/check/apple.com?fresh=1 and confirm:
  the grade is unchanged and no new issues appear. Target grade: A.

## Report back
List each record you changed (name, type, old value, new value), what you verified, and anything you could not do.