Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Brief points
Key points will appear here once TrustOps condenses this read. Use the source link below if you need the full article immediately.
Yesterday I published an analysis claiming that 26 of 39 AI companies use SPF softfail, implying their email could be spoofed. A reader (@privacyfish) pointed out that this is misleading:
SPF
~allby itself does not always mean "the domain can be spoofed into inboxes" if the domain has DMARC enforcement and DKIM alignment working.
They're right. SPF is only one layer. The actual spoofability of a domain depends on how SPF, DMARC, and DKIM work together — and DMARC only needs one of SPF or DKIM to align for the message to pass. So I re-ran the analysis with a combined scoring model.
| Layer | What it does | On its own |
|---|---|---|
| SPF | Lists authorized sending IPs | Softfail (~all) = "flag but deliver" |
| DMARC | Tells receivers what to do on authentication failure |
p=reject = hard enforcement |
| DKIM | Cryptographic signature proving the email is authentic | Verifies message integrity |
The critical point I missed: DMARC passes if either SPF or DKIM aligns with the From domain. A domain with SPF softfail + DMARC reject + DKIM = well-protected, because even if SPF softfails, aligned DKIM makes the DMARC check pass. And if both fail, DMARC reject tells the receiver to drop the message.
Checking SPF alone — which is what my original analysis did — misses the full picture.
Out of 39 AI/tech companies rescanned with all three layers:
These have DMARC enforcement (reject or quarantine) plus at least one aligned authentication mechanism:
| Company | SPF | DMARC | DKIM |
|---|---|---|---|
| Anthropic | softfail | reject | |
| OpenAI | hardfail | reject | |
| Apple | softfail | quarantine | selector1 |
| Microsoft | hardfail | reject | selector2 |
| Cloudflare | hardfail | reject | k1 |
| Stripe | softfail | reject | |
| DeepSeek | hardfail | quarantine | default |
(+ 23 others including Cohere, Mistral, Midjourney, Perplexity, Databricks, Snowflake, Cursor, Vercel, Replit)
Anthropic — the company I highlighted yesterday as vulnerable — is actually textbook correct. Softfail SPF + reject DMARC + DKIM alignment = spoofed emails get rejected.
| Company | SPF | DMARC | DKIM found? | Note |
|---|---|---|---|---|
| softfail | reject | not on standard selectors | Almost certainly uses custom DKIM selectors — they invented the protocol | |
| Meta | redirect | reject | not on standard selectors | Uses Proofpoint; custom selectors likely |
| Notion | softfail | quarantine | not on standard selectors | DMARC enforcement active via SPF alignment |
Important caveat: DKIM selectors are arbitrary strings chosen by the domain owner. My scanner checks 9 common selectors (google, selector1, selector2, default, k1, s1, s2, dkim, mail). Google and Meta almost certainly sign with DKIM using selectors I didn't check. These companies have strong DMARC enforcement and are not practically at risk.
These have no DMARC enforcement — their DNS policies don't instruct receivers to reject authentication failures:
| Company | SPF | DMARC | DKIM | Gap |
|---|---|---|---|---|
| Nvidia | softfail | missing | yes | No DMARC policy at all despite having DKIM |
| xAI | softfail | p=none |
no | Monitoring-only DMARC, no DKIM, Chinese email infra |
| Stability AI | softfail | p=none |
yes | Has DKIM but DMARC won't enforce on failure |
| Hugging Face | softfail | p=none |
yes | Same — DKIM present but DMARC is monitoring-only |
| Inflection AI | softfail | missing | yes | No DMARC at all |
| Qdrant | softfail | p=none |
no | No enforcement on any layer |
p=none means the domain owner is collecting DMARC failure reports but not asking receivers to act on failures. It's a standard first step when deploying DMARC — you monitor before enforcing — but some companies stay in monitoring mode indefinitely.
This doesn't mean these companies' email is actively being spoofed. It means their DNS configuration doesn't instruct receiving mail servers to reject spoofed messages. Whether spoofing succeeds in practice depends on the receiving server's own policies.
Nvidia is the most notable gap. A $3 trillion company with DKIM set up but zero DMARC policy — they started the process but didn't finish it.
| Metric | SPF-only analysis | Combined analysis |
|---|---|---|
| Companies with gaps | 26 (67%) | 6 (15%) |
| False alarms | — | 20 companies mislabeled as risky |
| Layers checked | SPF only | SPF + DMARC + DKIM |
The original analysis was technically accurate — 26 companies do use SPF softfail — but practically misleading, because most are protected by DMARC enforcement.
I updated the interactive checker to show a combined spoofability risk score that weighs all three layers. Enter any domain and get SPF policy + DMARC enforcement + DKIM presence + an overall assessment.
Data pulled live from public DNS records via DomainIntel. All claims independently verifiable with dig.
Correction prompted by @privacyfish's comment on the original article. Data collected May 21, 2026.
Spot something off?