HN Debrief

Thanks FedEx, This Is Why We Keep Getting Phished (2024)

  • Security
  • Privacy
  • Infrastructure
  • Regulation

The post walks through a real FedEx Australia customs payment email that asks the recipient to follow a link to pay import charges on a domain with no obvious FedEx branding. It is exactly the kind of message security teams tell people to distrust, yet it was legitimate. That is the core complaint. Large companies keep creating scam-shaped experiences, then wonder why phishing works.

Treat your own domain as a trust anchor and stop outsourcing user-facing payment, login, and verification flows to random-looking links. If your legitimate communications trigger the same doubt as a phishing email, your process is already broken.

Discussion mood

Strongly frustrated. People see this as self-inflicted insecurity by large companies that outsource or fragment customer messaging, use random domains and redirects, and then expect users to maintain a clean mental model of what is safe.

Key insights

  1. 01

    Domain discipline is the missing control

    Using your primary domain consistently is the simplest trust signal most users can actually apply. The problem is not the sheer number of top level domains. It is that companies and agencies routinely bypass their own namespace for payment collection, regional workflows, and vendor tools. That turns the clean rule users could have followed into mush, especially when the weird-looking site is real.

    Audit every customer-facing flow that asks for money, login, or personal data. If it leaves your main domain or lands on a vendor-branded property, treat that as a security defect and redesign it.

      Attribution:
    • ddtaylor #1
    • walrus01 #1
    • SoftTalker #1
  2. 02

    Security training often sabotages itself

    A lot of anti-phishing training now teaches users to distrust exactly the patterns the employer later uses for real work. External training domains, sanctioned phishing simulations that bypass warning banners, and official emails that look sketchy all collapse the distinction between safe and unsafe. That is why employees start flagging legitimate mail or learn to ignore the rules entirely.

    Review your phishing simulations and mandatory training as part of product and IT governance, not just compliance. If your own exercises require exceptions to the rules users are supposed to follow, rewrite the program.

      Attribution:
    • jhbadger #1
    • LgWoodenBadger #1
    • voakbasda #1
    • starky #1
  3. 03

    Mobile and document UX hide obvious red flags

    Even careful users lose basic verification tools when the message arrives on mobile or as an attachment. You cannot hover to inspect links, and sketchy PDFs can still be part of a real process. That shifts more burden onto sender design, because the recipient often cannot safely validate what they are seeing from the interface alone.

    Assume most recipients will first see your message on a phone. Put the full destination domain in plain text, avoid attachments for identity or payment steps, and test whether a cautious user can verify legitimacy without a desktop.

      Attribution:
    • ern #1
    • lemursage #1
  4. 04

    This is not a FedEx-only failure

    FedEx was just one familiar logo in a much wider pile of examples. People cited customs notices from random staff addresses, facebookmail.com, allstate.yem.bo, and bank fraud teams that call customers back only to demand verification. The common problem is institutional behavior that looks scammy even when it is legitimate, which steadily trains users to suppress their own alarm bells.

    Do not assume your brand reputation compensates for confusing delivery channels. Map the exact sender names, domains, subdomains, callback flows, and SMS links customers encounter, then remove the ones that would fail your own phishing awareness test.

      Attribution:
    • lemursage #1
    • handedness #1
    • charlieyu1 #1
    • agency #1
    • monksy #1

Against the grain

  1. 01

    More TLDs are not the main culprit

    Blaming the explosion of top level domains misses the more basic problem. Phishers can do plenty of damage with ordinary .com names, and businesses can build on unusual or even numeric domains if they choose. The confusion comes from inconsistent branding and weak trust signals, not from the existence of new suffixes by itself.

    Do not spend energy arguing that domain policy will save users. Fix the sender and destination patterns you control first, because those are what recipients actually use to make decisions.

      Attribution:
    • cosmic_cheese #1
    • nubinetwork #1
    • tialaramex #1
    • linkregister #1
    • walrus01 #1
  2. 02

    Phone KYC will not stop scam messaging

    Requiring government identification for every phone line sounds like a fix, but commenters argued it targets the wrong layer. The Australian scam spike cited in the post was tied to sender impersonation through SMS gateways, not anonymous SIM cards. Tightening identity collection for phone accounts would add privacy risk and still leave spoofed messaging channels in place.

    When evaluating anti-fraud proposals, separate identity collection from message authentication. Push for controls on sender verification and gateway abuse before adding more customer KYC requirements.

      Attribution:
    • Cider9986 #1
    • ern #1
    • J-Kuhn #1

In plain english

SIM ↩
Subscriber Identity Module, the chip or embedded credential that identifies a mobile phone line on a carrier network.
SMS ↩
Short Message Service, the standard text messaging system used on mobile phones.

Reference links

Story and related discussion

Domain and naming references

Policy and anti-fraud proposals