Authentication history · 1 day observed
patagonia.com
Observed from 4 Aug 2026 to 4 Aug 2026. Nothing published in DNS has moved in that window.
Where it stands today
Live lookup, 5 Aug 2026. The same check /check/patagonia.com runs.
- 3worth a look
- 2fine
- 1context
Worth a look
present with p=none
This satisfies Gmail and Outlook, and protects nothing. p=none only asks for reports; it never tells a receiver to act, so anyone can still send as this domain and nothing happens.
v=DMARC1; p=none; rua=mailto:Reports.DMARC@patagonia.com,mailto:dmarc_agg@vali.email
From DMARC p=none is monitoring, not enforcementSee what this looks like →
This one needs you
Move to p=quarantine with pct=5 once a week of shows no unaligned sender you cannot name. No platform can choose your policy. This one has never been anybody else's.
Worth a look
Klaviyo signs your mail, and nothing you publish names it
2 of Klaviyo's selectors carry live keys here, so Klaviyo is signing mail as you. Neither your record nor any of the subdomains bulk mail is normally sent from mentions Klaviyo; your SPF names Microsoft 365 and Salesforce. That is not automatically wrong: if Klaviyo sends with its own return-path domain, which is the default on every major platform, your SPF is never consulted on those messages and they pass on alone. What it does mean is that this channel has no SPF to fall back on — one key rotated, revoked or mis-copied and there is nothing underneath it.
v=spf1 ip4:216.245.185.197/32 ip4:20.66.44.240/30 ip4:98.152.10.66/32 ip4:151.106.133.162/32 include:spf.protection.outlook.com include:smp.ne.jp include:_spf2.patagonia.com include:_spf.salesforce.com a:production.na02.patagonia.demandware.net ~all kl._domainkey, kl2._domainkey
From Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
Part platform, part you
Send one campaign through Klaviyo to yourself and read the Authentication-Results header. If it says =pass, the envelope is on Klaviyo's domain and there is nothing to do. If it says spf=fail or softfail, you are sending with your own domain as the envelope and Klaviyo's include: belongs in your SPF.
Worth a look
SendGrid signs your mail, and nothing you publish names it
2 of SendGrid's selectors carry live keys here, so SendGrid is signing mail as you. Neither your record nor any of the subdomains bulk mail is normally sent from mentions SendGrid; your SPF names Microsoft 365 and Salesforce. That is not automatically wrong: if SendGrid sends with its own return-path domain, which is the default on every major platform, your SPF is never consulted on those messages and they pass on alone. What it does mean is that this channel has no SPF to fall back on — one key rotated, revoked or mis-copied and there is nothing underneath it.
v=spf1 ip4:216.245.185.197/32 ip4:20.66.44.240/30 ip4:98.152.10.66/32 ip4:151.106.133.162/32 include:spf.protection.outlook.com include:smp.ne.jp include:_spf2.patagonia.com include:_spf.salesforce.com a:production.na02.patagonia.demandware.net ~all s1._domainkey, s2._domainkey
From Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
Part platform, part you
Send one campaign through SendGrid to yourself and read the Authentication-Results header. If it says =pass, the envelope is on SendGrid's domain and there is nothing to do. If it says spf=fail or softfail, you are sending with your own domain as the envelope and SendGrid's include: belongs in your SPF.
Looks fine
present, ending ~all
Soft fail. Accepted everywhere, though -all is stronger once your sender list is complete.
v=spf1 ip4:216.245.185.197/32 ip4:20.66.44.240/30 ip4:98.152.10.66/32 ip4:151.106.133.162/32 include:spf.protection.outlook.com include:smp.ne.jp include:_spf2.patagonia.com include:_spf.salesforce.com a:production.na02.patagonia.demandware.net ~all
Looks fine
keys published on 6 selectors
A key existing is not the same as working. Read a real received header and check the d= value matches your before you call this done.
selector2._domainkey (Microsoft 365), kl._domainkey (Klaviyo), selector1._domainkey (Microsoft 365), kl2._domainkey (Klaviyo), s2._domainkey (SendGrid), s1._domainkey (SendGrid)
From DKIM passing is not DKIM alignedSee what this looks like →
Part platform, part you
The key is your platform's to publish and it has. Whether it signs the domain in your is yours to confirm, and cannot show it — send one campaign to yourself and look for =pass header.d=patagonia.com in the Authentication-Results header.
Context
Receiving mail via Microsoft 365
Where you receive mail says nothing about where you send it. Marketing sends usually leave through a different platform entirely.
patagonia-com.mail.protection.outlook.com
What has moved
One entry per day a published record actually changed. Days we looked and found nothing different are counted, not listed.
First observation — what was already published
SPF published.
v=spf1 ip4:216.245.185.197/32 ip4:20.66.44.240/30 ip4:98.152.10.66/32 ip4:151.106.133.162/32 include:spf.protection.outlook.com include:smp.ne.jp include:_spf2.patagonia.com include:_spf.salesforce.com a:production.na02.patagonia.demandware.net ~all
DMARC published.
v=DMARC1; p=none; rua=mailto:Reports.DMARC@patagonia.com,mailto:dmarc_agg@vali.email
DKIM keys on selectors we probe.
kl._domainkey (Klaviyo), kl2._domainkey (Klaviyo), s1._domainkey (SendGrid), s2._domainkey (SendGrid), selector1._domainkey (Microsoft 365), selector2._domainkey (Microsoft 365)
MX records present.
patagonia-com.mail.protection.outlook.com