Authentication history · 1 day observed
gymshark.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/gymshark.com runs.
- 3fine
- 3context
Looks fine
present, ending ~all
Soft fail. Accepted everywhere, though -all is stronger once your sender list is complete.
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~allLooks fine
present with p=reject
A policy that actually instructs receivers, which is more than most senders publish.
v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.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.
k1._domainkey (Mailchimp), mandrill._domainkey (Mandrill), selector1._domainkey (Microsoft 365), 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=gymshark.com in the Authentication-Results header.
Context
SendGrid signs your mail, and your cannot be read to confirm it
2 of SendGrid's selectors carry live keys on this domain, so SendGrid is signing mail as you. Whether your authorises it is not answerable by reading . Your record uses SPF macros (Proofpoint), 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 SendGrid is guessing.
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.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 SendGrid 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
record published
Your logo can appear in supporting clients, which needs at quarantine or reject.
Context
MX records present
Where you receive mail says nothing about where you send it. Marketing sends usually leave through a different platform entirely.
mx08-005a6901.pphosted.com, mx07-005a6901.pphosted.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:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~allDMARC published.
v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com
DKIM keys on selectors we probe.
k1._domainkey (Mailchimp), mandrill._domainkey (Mandrill), s1._domainkey (SendGrid), s2._domainkey (SendGrid), selector1._domainkey (Microsoft 365)
BIMI published.
v=BIMI1;l=https://bimi.entrust.net/gymshark.com/logo.svg;a=https://bimi.entrust.net/gymshark.com/certchain.pem
MX records present.
mx07-005a6901.pphosted.com, mx08-005a6901.pphosted.com