1. List existing forwarding domains to avoid a duplicate claim. Confirm the registered-domain reference if linking an owned domain.
2. POST the full domain and choose forwarding_type as http, mail or both. Supply a cluster reference only when that runtime is eligible and assigned to your account.
3. Save the returned forwarding-domain ID. A newly created record starts in a pending DNS state.
4. Open the domain's current setup instructions in DNS Manager and read the detail and conflicts. Copy the issued ownership challenge and the actual runtime DNS destinations.
5. Publish the challenge at the authoritative DNS provider. The current challenge uses _domain-verify and an issued domain-verification=... TXT value. Use the exact value for this domain, not the example or another account's token.
6. Check the authoritative answer, then request verify-dns. Track verification and subsequent deployment separately.

HTTP forwarding needs requests to reach its configured runtime. Mail forwarding needs the appropriate mail routing. Those changes can replace the destination of an existing website or inbox service. Resolve reported hosting, MX or ownership conflicts and agree the intended service before applying them.

The conflicts endpoint shows recorded evidence. If you change hosting or DNS, run the relevant verification again rather than assuming an old clean result remains valid. Creating a forwarding-domain row does not itself create a website, mailbox or complete deployment.

• Create a website redirect with Domain Forwarders
• Create and simulate an HTTP redirect rule before deployment
• Create an email forwarding rule and verify its destination
• Deploy or roll back a forwarding runtime generation