# Fix email authentication for salesforce.com

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

## What is published right now (do not assume anything else)
- SPF (TXT salesforce.com): v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all   — valid, 4 of 10 lookups
- DMARC (TXT _dmarc.salesforce.com): v=DMARC1;p=reject;fo=1:d:s;pct=100;rua=mailto:dmarc_agg@vali.email,mailto:0e5a5c34@inbox.ondmarc.com;ruf=mailto:0e5a5c34@inbox.ondmarc.com
- DKIM: google._domainkey (1024-bit), s1._domainkey (2048-bit), s2._domainkey (1024-bit), mandrill._domainkey (1024-bit), m1._domainkey (1024-bit)
- MX: mxa-00177002.gslb.pphosted.com, mxb-00177002.gslb.pphosted.com  → Proofpoint
- Nameservers: pch1.salesforce-dns.com, pch2.salesforce-dns.com …  → DNS host not recognised

## Tasks, in order of impact
### 1. 4 DKIM keys are 1024-bit.
Why: Selectors google._domainkey, s2._domainkey, mandrill._domainkey, m1._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 Proofpoint, stop and say exactly what access you need.

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