Step 1
White-Label Email Forwarding Solution
Your Brand. Our Email Forwarding Infrastructure.
Bring email forwarding to customers under your own brand. Build against the current proxy-binding API or discuss the planned embedded management experience, partner authentication, and branding capabilities with ProxiedMail.
The embedded interface shown here is a product direction for partnership discussion. It is not a claim that a public iframe endpoint or complete white-label system is currently available.How white-label integration is intended to work
Choose between a partner-built experience and a planned embedded interface on the same forwarding foundation.
Step 2
Customize the customer experience
Step 3
Offer forwarding under your brand
Integration comparison
Two ways to integrate. One email forwarding infrastructure.
The API foundation exists today. The embedded experience is a planned partner product whose interface, authentication, and branding scope must be agreed.
REST API integration
Build a customer experience that matches your product and workflow.
- Your own frontend and design system.
- Programmatic list, create, and update operations for proxy bindings.
- Control over how forwarding destinations and addresses appear to customers.
- Best for customized workflows and teams prepared to build the product layer.
Embedded management interface
Discuss a ProxiedMail-powered frontend designed to sit inside a hosting or domain dashboard.
- Intended to reduce frontend development effort.
- Planned partner branding options.
- Intended customer sessions scoped to authorized domains.
- No iframe URL, SSO protocol, or production authentication contract is promised here.
Conceptual white-label walkthrough
Email forwarding built into your customer dashboard
A customer purchases mybusiness.com from a fictional hosting provider. They open “Email Forwarding” in that provider's dashboard and create a route without visiting a separate consumer product.
contact@mybusiness.com→mybusiness@gmail.comThis walkthrough illustrates the intended partner experience. It does not state that an iframe product, no-login customer session, or partner-branded interface is already deployed.
Make forwarding part of your product—not another destination for customers
Your branding
Design the API-driven experience yourself today, and discuss planned logo, color, and branded customer touchpoints for an embedded model.
API and embedded direction
Choose the documented API foundation or help scope the planned embedded partner experience.
Customer domain management
ProxiedMail supports verified custom domains; multi-tenant partner provisioning and customer isolation require a defined integration.
Forwarding and catch-all routing
Use established forwarding concepts, including catch-all behavior, while confirming which controls will be exposed to partner customers.
Reduced infrastructure maintenance
Avoid building the complete inbound mail and forwarding layer as part of your own product.
Partner-oriented design
Define customer lifecycle, branding, authentication, domain scope, support, and commercial packaging around your platform.
Who it is for
Platforms that want forwarding to feel native
White-label forwarding is intended for businesses that already manage domains or customer accounts and want to keep that relationship under their own brand.
Hosting companies
Add forwarding to a control panel as a branded hosting feature.
Domain registrars
Extend domain management with a useful email product.
SaaS platforms
Connect customer domains to forwarding as part of a broader software workflow.
Website builders
Offer a branded email address alongside a site and domain.
Domain management services
Manage forwarding destinations within the same operational interface as DNS and renewals.
Reseller platforms
Package forwarding for downstream customers without presenting a separate consumer brand.
Technical integration
Built for integration into your platform
The current REST API uses JSON API conventions and documents token-based operations for listing, creating, and updating proxy bindings. Those resources can support a partner-built frontend. The planned embedded model would add a ProxiedMail-powered management UI, domain-scoped customer sessions, and partner branding on top of the same forwarding infrastructure.
Read ProxiedMail API documentation →- Public proxy-binding list, create, and update operations
- Proxy address and forwarding-destination fields
- API token documented in the OpenAPI schema
- Existing custom-domain and catch-all product behavior
- Partner-scoped customer and domain separation
- Embedded management UI and session flow
- Supported logo, color, and other branding controls
- Branded MX hostnames where technically and operationally supported
No iframe snippet, partner SSO method, tenant contract, or branded MX hostname is published because those capabilities are not confirmed as implemented.
White-label pricing
Partner pricing for your business
Pricing is scoped around usage volume, customer domains, forwarding traffic, integration work, infrastructure, branding requirements, and support responsibilities. No consumer pricing or invented partner tier is applied to this offering.
Discuss White-Label PricingPartnership questions
Frequently asked questions
What is white-label email forwarding?
It is an arrangement where a partner offers email forwarding as part of its own product and brand while another provider supplies the agreed forwarding infrastructure.
Can I offer email forwarding under my own brand?
You can build a fully partner-branded frontend against confirmed API resources. Additional embedded branding capabilities are planned and require partnership scoping.
What is the difference between API and iframe integration?
With the API, your team builds and owns the frontend. The planned embedded option would provide a ProxiedMail-powered management UI inside your platform to reduce frontend work. No production iframe endpoint is claimed today.
Can customers manage forwarding without accessing ProxiedMail directly?
That is the intended partner experience. It can be built in your own frontend using the API. A ready-made domain-scoped embedded session without a separate ProxiedMail login is planned, not confirmed as currently available.
Can the embedded interface match my branding?
Partner-controlled logos, colors, and related presentation are intended capabilities. The supported controls and limits have not yet been published and must be agreed during product scoping.
Can I use branded MX records?
Branded MX hostnames may be considered where technically and operationally supported, but they are not advertised as an available standard feature. DNS architecture must be reviewed for each deployment.
Can I manage multiple customer domains?
ProxiedMail already supports multiple custom domains in its product. A partner-facing multi-tenant domain provisioning and separation model is a subject for integration design rather than a confirmed public API capability.
Does white-label forwarding require running mail servers?
The intended model uses ProxiedMail for the agreed receiving and forwarding infrastructure. The partner still operates its own customer platform and any systems outside that scope.
Can my company resell the service?
Reseller packaging is an intended commercial model. Branding, billing, support responsibilities, usage, and contract terms are defined through a partner agreement.
How do I start a white-label integration?
Share your platform, expected domains and traffic, customer journey, branding goals, and preferred API or embedded approach with ProxiedMail. The team can separate available API capabilities from planned development and propose an integration scope.
Offer Email Forwarding Under Your Own Brand
Discuss your integration requirements with ProxiedMail and explore how email forwarding can become part of your existing product.
Book a call
Discuss your partner integration with ProxiedMail
Choose a convenient time for a 30-minute conversation about your platform, forwarding workflow, integration, and infrastructure requirements.
Partner inquiry
Tell us about your white-label product
Describe the customer journey, branding, authentication, domain scope, and launch requirements you have in mind.
- Your platform and customer dashboard
- API or planned embedded integration preference
- Domain volume, branding, authentication, and support needs


