Skip to content
emailrules.today

Authentication history · 60 days observed

decathlon.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/decathlon.com runs.

  • 3fine
  • 4context

  • Looks fine

    present, ending -all

    Hard fail. The strictest setting and the right one once you are confident every sender is listed.

    v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -all

    See what this looks like →

  • Looks 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 9 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.

    k2._domainkey (Mailchimp), mandrill._domainkey (Mandrill), k1._domainkey (Mailchimp), mail._domainkey (generic), s1._domainkey (SendGrid), google._domainkey (Google Workspace), 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=decathlon.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 (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 Klaviyo is guessing.

    v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -all

    From 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

    Mailchimp signs your mail, and your cannot be read to confirm it

    2 of Mailchimp's selectors carry live keys on this domain, so Mailchimp 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 Mailchimp is guessing.

    v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -all

    From 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 Mailchimp 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

    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 -all

    From 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

    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.

    aspmx2.googlemail.com, aspmx3.googlemail.com, aspmx.l.google.com

    See what this looks like →

What has moved

One entry per day a published record actually changed. Days we looked and found nothing different are counted, not listed.

  1. First observation — what was already published

    SPF published.

    v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com -all

    DMARC 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.

    google._domainkey (Google Workspace), k1._domainkey (Mailchimp), k2._domainkey (Mailchimp), kl._domainkey (Klaviyo), kl2._domainkey (Klaviyo), mail._domainkey (generic), mandrill._domainkey (Mandrill), s1._domainkey (SendGrid), s2._domainkey (SendGrid)

    MX records present.

    alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, aspmx.l.google.com, aspmx2.googlemail.com, aspmx3.googlemail.com
Where this comes from. Public DNS, and nothing else. We read the same TXT and MX records any mail server reads before accepting a message, on the days someone looked. There is no scan, no login, no mail, and no score here — only what was published and the date we saw it. Gaps are days we did not get a clean answer from a resolver, and we would rather leave those blank than guess at them.
Run the full checkSee which rules are yours