Skip to content
emailrules.today

Authentication history · 60 days observed

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

  • 2worth a look
  • 4fine
  • 2context

  • Worth a look

    has no address, so nobody is reading the reports

    are the only way to discover a tool that sends as you without . Most agencies stop at p=none and never look again.

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

    This one needs you

    Add =mailto: to the record, pointed at an inbox a person . Reports arrive as daily XML from every major receiver, and this site reads them for free if you would rather not.

  • Worth a look

    Mailchimp signs your mail, and nothing you publish names it

    2 of Mailchimp's selectors carry live keys here, so Mailchimp is signing mail as you. Neither your record nor any of the subdomains bulk mail is normally sent from mentions Mailchimp; your SPF names Google Workspace and Zendesk. That is not automatically wrong: if Mailchimp 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 a include:_spf.google.com ip4:149.72.216.165 ip4:167.89.79.69 ip4:167.89.87.53 ip4:168.245.25.177 ip4:167.89.97.206 include:mail.zendesk.com include:mg-spf.greenhouse.io -all
k1._domainkey, k2._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 Mailchimp to yourself and read the Authentication-Results header. If it says =pass, the envelope is on Mailchimp'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 Mailchimp's include: belongs in your SPF.

  • Looks fine

    present, ending -all

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

    v=spf1 a include:_spf.google.com ip4:149.72.216.165 ip4:167.89.79.69 ip4:167.89.87.53 ip4:168.245.25.177 ip4:167.89.97.206 include:mail.zendesk.com include:mg-spf.greenhouse.io -all

    See what this looks like →

  • Looks fine

    present with p=quarantine

    A policy that actually instructs receivers, which is more than most senders publish.

    v=DMARC1; p=quarantine;

    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), k1._domainkey (Mailchimp), s1._domainkey (SendGrid), s2._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=figma.com in the Authentication-Results header.

  • Looks fine

    SendGrid is authorised on email.figma.com

    SendGrid signs mail as this domain, and the root record does not name it — which on its own looks like a mismatch. It is not: email.figma.com publishes its own SPF naming SendGrid, and SPF is evaluated against the envelope domain rather than the root. This is the normal setup for bulk mail on a subdomain.

    v=spf1 a include:_spf.google.com ip4:149.72.216.165 ip4:167.89.79.69 ip4:167.89.87.53 ip4:168.245.25.177 ip4:167.89.97.206 include:mail.zendesk.com include:mg-spf.greenhouse.io -all

    From Gmail enforces authentication, PTR, TLS and a 0.30 percent spam rateSee what this looks like →

  • Context

    record published

    Your logo can appear in supporting clients, which needs at quarantine or reject.

    See what this looks like →

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

    alt2.aspmx.l.google.com, aspmx.l.google.com, aspmx2.googlemail.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 a include:_spf.google.com ip4:149.72.216.165 ip4:167.89.79.69 ip4:167.89.87.53 ip4:168.245.25.177 ip4:167.89.97.206 include:mail.zendesk.com include:mg-spf.greenhouse.io -all

    DMARC published.

    v=DMARC1; p=quarantine;

    DKIM keys on selectors we probe.

    google._domainkey (Google Workspace), k1._domainkey (Mailchimp), k2._domainkey (Mailchimp), s1._domainkey (SendGrid), s2._domainkey (SendGrid)

    BIMI published.

    v=BIMI1;l=https://figma-static-assets.s3-us-west-2.amazonaws.com/figma_314290589.svg;a=

    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