# Fix email authentication for linkedin.com

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

## What is published right now (do not assume anything else)
- SPF (TXT linkedin.com): v=spf1 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip4:108.174.6.0/24 ip4:108.174.0.0/24 ip6:2620:109:c00d:104::/64 ip6:2620:109:c006:104::/64 ip6:2620:109:c003:104::/64 ip6:2620:119:50c0:207::/64 ip4:199.101.161.130 mx mx:docusign.net ~all   — valid, 2 of 10 lookups
- DMARC (TXT _dmarc.linkedin.com): v=DMARC1; p=reject; rua=mailto:d@rua.agari.com,mailto:yfy3q-9359@rua.dmarc.emailanalyst.com; ruf=mailto:d@ruf.agari.com
- DKIM: google._domainkey (1024-bit)
- MX: mail-1.linkedin.com, mail-c.linkedin.com, mail-d.linkedin.com, mail-a.linkedin.com, mail.linkedin.com  → a custom mail host
- Nameservers: dns1.p09.nsone.net, dns2.p09.nsone.net …  → records are managed in Azure DNS

## Tasks, in order of impact
### 1. One DKIM key is 1024-bit.
Why: Selector google._domainkey is 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 Azure DNS, stop and say exactly what access you need.

## Verify
  dig +short TXT linkedin.com
  dig +short TXT _dmarc.linkedin.com
Then open https://www.mailauthwatch.com/check/linkedin.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.