Domain mapping
Configuring a domain so requests to it are routed to a different destination at the application layer (e.g. proxied to your SaaS) rather than redirected via HTTP.
Domain mapping is the routing step where you say "requests for hostname X should be served by application Y." It happens at HTTP layer 7, not via DNS-level redirects.
Mapping vs forwarding (the common confusion)
Forwarding is an HTTP 301/302 redirect. Browser hits olddomain.com, gets a response that says "go to newdomain.com." The URL in the address bar changes.
Mapping is a transparent proxy. Browser hits olddomain.com, your edge proxies the request to the actual app, the response is served back as if it came from olddomain.com. The URL in the address bar stays the same.
For custom domains in SaaS, you almost always want mapping, not forwarding. Forwarding bounces the customer's user off the custom domain back to your default URL, which defeats the purpose.
How mapping is configured
At the routing layer (your edge or load balancer), you maintain a table that says:
| Incoming Host header | Route to |
|---|---|
| janesbakery.com | tenant 4218's content |
| shop.acme.com | tenant 9907's content |
A custom-domain API manages this table for you. POST a hostname, the table updates. DELETE a hostname, it's removed.
TLS in the mapping flow
The map is consulted after TLS termination at your edge. Each mapped hostname needs its own certificate (or a SAN cert covering multiple hostnames). This is the heavy part of running custom domains at scale.