A technically clean domain, flagged as a malicious URL.
Transactional emails containing links to a client's own domain were being filtered by mail security gateways, not because of the mail infrastructure, but because the URL itself had acquired a malicious reputation. Initial evidence suggested a compromised domain. The apex domain passed every authentication, DNS, reputation, and infrastructure check available. The investigation had to expand well past mail authentication, into HTTP headers, Content Security Policy, wildcard DNS architecture, and certificate transparency logs, to find out why.
This engagement is covered by a signed NDA, so client identity, domain names, and hosting namespace in this write-up have been altered. The diagnostic path, tooling, and findings are unchanged.
Users reported that transactional emails containing links to the client's domain were landing in spam folders.
Hamcut identified the embedded URL as a confirmed malicious URL, even though the sender infrastructure appeared legitimate. That contradiction is what opened the investigation.
Phase 3 · Authentication review
Every mechanism a mailbox provider could plausibly be reacting to was checked directly, not inferred.
Conclusion: authentication was not responsible for the reputation issue.
Phase 4 · Infrastructure review
DNSPulse evaluated the apex domain directly.
11 of 11 checks passed
No blocklists
No abuse history
Clean sender reputation
At this stage, there was no technical evidence explaining the malicious URL verdict.
Phase 5 · Header forensics
Rather than continuing down the DNS path, the investigation turned to the domain's HTTP response headers. A Content Security Policy header contained a line that changed the direction of the entire investigation:
frame-src https://*.builtwithforge.new
This was the first indication that the domain's trusted surface extended well beyond the apex domain itself.
Phase 6 · Trust relationship analysis
The wildcard namespace referenced in that header, *.builtwithforge.new, was examined directly. It resolved to shared Netlify deployments and shared Vercel preview environments hosting thousands of customer-created applications. At this point the investigation stopped being a mail problem and became a shared-hosting trust analysis.
2,842 deployment slugs catalogued
949 unique DNS names identified
92 domains audited
3 wildcard environments: .public · .app · .preview
The complete deployment inventory was reconstructed from certificate transparency logs and DNS enumeration, not from anything the client provided.
Among the enumerated deployment slugs, the investigation identified multiple phishing and brand-impersonation sites, including names mimicking banking, government, and authentication services, all hosted inside the same trusted wildcard namespace.
Phase 9 · Root cause
The apex domain itself remained technically healthy throughout. The malicious reputation originated from abuse hosted inside the trusted wildcard deployment namespace, and because the primary domain explicitly trusted that namespace through its own CSP configuration, reputation engines associated the malicious activity in the wildcard environment with the parent domain. This architectural trust relationship, not an authentication failure or mail infrastructure fault, is what caused the client's own link to be classified as malicious.
Outcome
- Mail authentication was functioning correctly throughout
- DNS configuration met best practices
- Sender reputation was clean on the apex domain
- Infrastructure health was never the actual issue
What this case shows
The reputation problem here didn't come from anything broken. It came from an architectural trust decision, a CSP header vouching for a wildcard namespace, that exposed the primary domain to abuse happening inside a shared deployment ecosystem it didn't directly control. Each phase of the investigation eliminated one class of cause until the architecture itself was the only explanation left.
Something in your stack trusting more than it should?
Shared hosting, wildcard subdomains, and third-party embeds can all quietly expand what a mailbox provider associates with your domain. If a link of yours is getting flagged and nothing on your side explains it, that's exactly what we investigate.