One thing is yours.
19 DNS lookups23 blocklists askedno entriesno score, ever
read from DNS, quoted verbatim
- SPF
- -all
- DMARC
- p=quarantine, no rua
- DKIM
- 5 selectors
- BIMI
- published
- MX
- Google Workspace
- LISTS
- 23 asked
Who sends as you
Mailchimp and SendGrid signs mail as this domain and your SPF has never listed them. Those campaigns fail SPF and pass DMARC on DKIM alignment alone.
4 Aug 2026 · no score, no grade, nothing inferred
Who this domain authorises
Your SPF authorises Zendesk
- include:mail.zendesk.comread from your SPF, verbatim
Mailchimp signs your mail — and your SPF does not list it
- k1._domainkeyDKIM key present
- k2._domainkeyDKIM key present
2 of Mailchimp’s own selectors carry live keys, which is a setup somebody completed — not a selector collision. Your SPF names somebody else, so this mail passes DMARC on DKIM alignment alone.
SendGrid signs your mail — and your SPF does not list it
- s1._domainkeyDKIM key present
- s2._domainkeyDKIM key present
2 of SendGrid’s own selectors carry live keys, which is a setup somebody completed — not a selector collision. Your SPF names somebody else, so this mail passes DMARC on DKIM alignment alone.
include:_spf.google.com is Google Workspace, which is where staff read mail. It says nothing about where campaigns leave from, and a checker that counts it as your sending platform has told you about your inbox, not your list.
This is what your DNS authorises, not proof of what you send. A domain can authorise a platform it stopped paying for two years ago, which is why an include on its own is reported as permission rather than as use, and it can carry live keys for a platform it never authorised, which is the reverse and the more expensive of the two. Only a real message names the address that actually sent your campaign.
Whose job each one is
- 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
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), k1._domainkey (Mailchimp), k2._domainkey (Mailchimp), 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=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.
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.
aspmx3.googlemail.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com
Blocklists
Nothing has an entry for you.
23 lists asked0 with an entry1 could not be asked
figma.com is not on any of the 23 lists that answered us today. That is the whole result — there is no score, and a clean answer is allowed to be short.
Which lists, and which would not answer
- SpamCopanswered
- PSBLanswered
- Mailspikeanswered
- Spam Eating Monkeyanswered
- blocklist.deanswered
- 0SPAManswered
- InterServeranswered
- SPFBLanswered
- GBUdb Truncateanswered
- s5h.netanswered
- ZapBLanswered
- SWINOGanswered
- Kemptanswered
- Anonmailsanswered
- Fabelanswered
- NoSolicitadoanswered
- Schulteanswered
- JIPPGanswered
- UCEPROTECT Level 1answered
- UCEPROTECT Level 2answered
- UCEPROTECT Level 3answered
- Backscattereranswered
- SEM Backscatteranswered
- URIBLdeclined the query
Each of these answered an entry it is required to publish, and one it is required not to, before we believed anything it said about you. A list that fails either is reported as unanswered rather than as clean — because a blocklist that declines to reply looks exactly like one giving you the all-clear. How we choose them.
Putting this in a client report? Embed a live, dated badge that re-checks itself.
Watch this domain
One email if authentication DNS for figma.com actually changes. Same list as rule alerts — one inbox, one promise.