Authentication history · 60 days observed
nytimes.com
Observed from 4 Aug 2026 to 3 Oct 2026. Nothing published in DNS has moved in that window.
Where it stands today
Live lookup, 3 Oct 2026. The same check /check/nytimes.com runs.
- 3fine
- 2context
Looks fine
present, ending ~all
Soft fail. Accepted everywhere, though -all is stronger once your sender list is complete.
v=spf1 include:nytimes.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:_spf.e.sparkpost.com include:amazonses.com ~allLooks fine
present with p=reject
A policy that actually instructs receivers, which is more than most senders publish.
v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email,mailto:dmarc.report@nytimes.com
From DMARC p=none is monitoring, not enforcementSee what this looks like →
Looks fine
keys published on 5 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.
google._domainkey (Google Workspace), k2._domainkey (Mailchimp), s2._domainkey (SendGrid), kl2._domainkey (Klaviyo), kl._domainkey (Klaviyo)
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=nytimes.com in the Authentication-Results header.
Context
Klaviyo signs your mail, and your cannot be read to confirm it
2 of Klaviyo's selectors carry live keys on this domain, so Klaviyo is signing mail as you. Whether your authorises it is not answerable by reading . Your record uses SPF macros (Valimail), so the authorised senders are resolved per message from the connecting IP and are never published as a list. No checker can settle it from DNS, including this one — anyone who tells you this record does or does not list Klaviyo is guessing.
v=spf1 include:nytimes.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:_spf.e.sparkpost.com include:amazonses.com ~allFrom Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →
Good to know — nothing to fix
Send one real campaign through Klaviyo and read the Authentication-Results header on what arrives. That header is the only place this question gets answered, because it is the receiver evaluating the macro against the real .
Context
Receiving mail via Google Workspace
Where you receive mail says nothing about where you send it. Marketing sends usually leave through a different platform entirely.
aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.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 include:nytimes.com._nspf.vali.email include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email include:_spf.e.sparkpost.com include:amazonses.com ~allDMARC published.
v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email,mailto:dmarc.report@nytimes.com
DKIM keys on selectors we probe.
google._domainkey (Google Workspace), k2._domainkey (Mailchimp), kl._domainkey (Klaviyo), kl2._domainkey (Klaviyo), s2._domainkey (SendGrid)
MX records present.
alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com, aspmx.l.google.com