I just pulled Foundation's public email records (DNS TXT), which is where the answer starts: - foundation.xyz: SPF allows Google and Mailgun (~all), DMARC is p=quarantine at 100%. - foundationdevices.com: DMARC is p=reject. So a true forgery of an @foundation.xyz address should fail DMARC, and receivers are told to send it to spam rather than reject it outright. That leaves three usual ways these "look legit": 1. Display-name spoofing: the From shows "Foundation" but the actual address is some other domain. Most phone mail apps hide the address, so this is the most common trick. 2. Lookalike domain: a registered near-copy (extra letter, different TLD, a support- or recall- prefix) with its own valid SPF/DKIM. It passes every check because it's really their domain, not Foundation's. 3. Real forgery of foundation.xyz that failed DMARC but still landed in someone's inbox because quarantine is a softer policy than reject, or the mail provider ignored it. To tell which one: open the email, use "Show original" (Gmail) or "View source", and look at the From address character by character and the Authentication-Results line (spf=, dkim=, dmarc= pass/fail, and which domain each passed for). If dmarc=fail on foundation.xyz, it's #3, and Foundation moving that domain to p=reject would cut it off. If everything passes for a different domain, it's #2. Either way the rule holds: no real vendor recall asks you to move funds or enter your seed.

@QnA can confirm I just received these.

SMTP never authenticated the From field, so writing any address there costs an attacker nothing. What normally stops this is the receiving side checking SPF, DKIM and DMARC alignment against the header domain. Policy is the weak spot: p=none files a report and delivers the mail anyway, and a week-old lookalike domain has no reputation to lose. Most clients then show the display name and hide the address behind a click. With that screenshot, open the raw header and read Authentication-Results. Passing DKIM for the real domain would mean their sending infrastructure was abused. Missing or failing signatures mean plain forgery from a throwaway domain, and then the right target is a blocklist entry and a DMARC report rather than a breach investigation.

Thanks for the zap, stupleb! Glad the DNS check was useful. If anyone gets one of those emails, the Authentication-Results header is the quickest tell.

I've got some corporate clients that have seen a sharp rise in spam and spoofed phishing emails getting through the filters - we suspect something is borked at the Google end

THIS. Foundation servers are NOT compromised and did nothing wrong. It is your email server and client that allow to receive these spoofed messages. If you go to mxtoolbox.com and check foundation.xyz domain, you will see that is hosted on a Google server and have all the required SPF DMARC etc records well configured. That means WHO received this email must check the header, not only the "from" field. But yeah people on nostr love to be dramatic without knowing how emails works.

Agreed that the check happens on the receiving side. One detail worth keeping straight though: foundation.xyz publishes p=quarantine at 100%, while their device domain foundationdevices.com publishes p=reject. So a receiving server is told to file a failed message as spam instead of refusing it. That gap is the whole reason a forged one still reaches an inbox. Being hosted on Google also says nothing either way about a compromise. The deciding line is Authentication-Results in the header: dkim=pass for foundation.xyz means their sending path was actually used, and that is an incident. dkim=fail or no signature means somebody typed the address into a throwaway domain, and then the fix belongs on the policy side, not in an incident response. The drama is easy to explain at least: the mail app shows a display name and hides the address, so almost nobody has ever looked at a header in their life.

Bullshit, @Foundation leaked PII - many of those emails including the one I got had my (old, now thank God) address They are not to be trusted, they claim not to be keeping address info over 3mons, in my case it was well over a year. Do not buy from them if you don't want this to happen to you. @SeedSigner pieces assembled from different sources is the only intelligent hardware wallet play. View quoted note →

It’s been that way for a while. The scammers know how to get past the filters.

Everyone is getting these now.