Short answer: point a customer subdomain at your asset host with a CNAME, then keep authorization in signed URLs. DNS decides where a request goes; it never decides who may make it.
For a logistics product, this distinction matters when a shipper wants labels, proof-of-delivery photos, or tracking assets to appear under assets.customer.example. The hostname can look customer-owned while the storage and delivery path remain platform-operated. That is a routing choice, not an isolation boundary.
How should customer domains, DNS records, and signed URLs handle asset access?
Treat onboarding as two separate flows. First, ask the customer to publish a CNAME from the chosen subdomain to your asset host. Second, generate a signed URL whenever an application grants access to an object. The browser sees the customer hostname, but the signature still carries the actual permission and expiry rules.
This is the part I put in the design review in plain language: a vanity hostname is cosmetic. It does not isolate one customer's objects from another customer's objects. Your object keys, bucket policy, and signing service still need tenant-aware checks before a URL is issued.
