Skip to content
emailrules.today

Authentication history · 57 days observed

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

  • 3fine
  • 1context

  • 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:spf.protection.outlook.com include:mail.zendesk.com include:o365.crossware.co.nz ip4:209.61.151.0/24 ip4:166.78.68.0/22 ip4:198.61.254.0/23 ip4:192.237.158.0/23 ip4:23.253.182.0/23 ip4:104.130.96.0/28 ip4:146.20.113.0/24 ip4:146.20.191.0/24 ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:104.130.122.0/23 ip4:146.20.112.0/26 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ip4:143.55.232.0/22 ip4:159.112.240.0/20 ip4:198.244.48.0/20 ip4:204.220.168.0/21 ip4:204.220.176.0/20 include:spf.mandrillapp.com a:production.lora.loreal.demandware.net -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; rua=mailto:tnoff9hr@ag.eu.dmarcadvisor.com;

    From DMARC p=none is monitoring, not enforcementSee what this looks like →

  • Looks fine

    keys published on 2 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), selector2._domainkey (Microsoft 365)

    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=aesop.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.

    aesop-com.mail.protection.outlook.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:spf.protection.outlook.com include:mail.zendesk.com include:o365.crossware.co.nz ip4:209.61.151.0/24 ip4:166.78.68.0/22 ip4:198.61.254.0/23 ip4:192.237.158.0/23 ip4:23.253.182.0/23 ip4:104.130.96.0/28 ip4:146.20.113.0/24 ip4:146.20.191.0/24 ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:104.130.122.0/23 ip4:146.20.112.0/26 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ip4:143.55.232.0/22 ip4:…

    DMARC published.

    v=DMARC1; p=reject; rua=mailto:tnoff9hr@ag.eu.dmarcadvisor.com;

    DKIM keys on selectors we probe.

    k2._domainkey (Mailchimp), selector2._domainkey (Microsoft 365)

    MX records present.

    aesop-com.mail.protection.outlook.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