When a signer receives a document from your company and the signing experience is branded with a competitor's logo, the implicit message is clear: your product is built on someone else's infrastructure. For most B2C use cases, signers don't care. For enterprise clients, regulated industries, and SaaS products where brand consistency signals product maturity, it matters more than most people expect. Completion rates for signing flows have been shown to decrease when signers encounter unexpected brand switches mid-workflow.
White-label e-signatures solve this problem. Done correctly, the entire signing experience — the invitation email, the signing page, the completed document delivery, the audit certificate — carries your brand, your domain, and your visual identity. The signer never sees the underlying platform. This guide covers what full white-labeling actually involves, where most implementations fall short, and how to build it properly.
What "White-Label" Actually Means (and Doesn't Mean)
White-label is a spectrum, not a binary. Most e-signature platforms offer some level of branding — typically a logo upload and a color accent. What they mean by "white-label" and what clients usually expect by "white-label" are often different things. The levels, from surface to deep:
Level 1: Logo and Color (Most Common)
The platform shows your logo at the top of the signing page and applies your brand color to buttons. The domain is still the platform's domain (docusign.com, zignature.io). The email comes from the platform's email infrastructure. This is the minimum viable branding available on most platforms at any tier.
Level 2: Custom Email Domain
Signing invitation and completion emails come from your email domain — notifications@yourdomain.com rather than noreply@platform.com. This requires DNS configuration (SPF, DKIM records) on your domain and is available on business/professional tiers of most platforms. It significantly improves email deliverability and eliminates the most visible brand inconsistency (the "from" address).
Level 3: Custom Signing Domain
The signing page itself loads at a subdomain of your choosing — sign.yourdomain.com rather than platform.com/s/documentid. This requires SSL certificate provisioning for your subdomain and is a more complex DNS and infrastructure change. Relatively few platforms support this, and those that do often require Enterprise-tier or custom agreements.
Level 4: Embedded Signing (True White-Label)
The signing experience is embedded directly into your application via an iFrame or full SDK integration. The signer never navigates to a separate URL at all — they complete the signing workflow within your product, in your UI, with your navigation and chrome around it. This is the highest level of white-labeling and requires API access and developer implementation. From the signer's perspective, there is no "e-signature platform" — there is just your product.
What Full White-Label Requires: The Technical Checklist
For a truly white-labeled e-signature experience, verify that the platform supports:
Email Infrastructure
- Outbound email from your domain (not the platform's domain)
- Custom email templates with your HTML branding, not just a logo inserted into a platform template
- Support for configuring SPF and DKIM on your domain
- DMARC alignment (the from domain matches the signing domain)
Signing Page
- Custom subdomain (sign.yourdomain.com or similar)
- Full custom branding — logo, colors, fonts — not just a logo placement
- Option to remove all platform branding, including footer text
- Mobile-responsive branding (logos and colors that render correctly at all screen sizes)
Completed Document Delivery
- Completion confirmation emails from your domain with your branding
- Audit certificate branded with your company, not the platform's
- Document stored in your environment or accessible via your branded portal
API and Embedding
- iFrame embedding with domain allowlisting for your app's domain
- JavaScript SDK for custom signing page rendering
- Webhook events that trigger your application when signing events occur
- OAuth or API key authentication scoped to your application
The Embedded Editor: White-Labeling Template Creation Too
Most businesses think about white-labeling the signing experience — what signers see when completing a document. Fewer think about white-labeling the template creation experience — what their customers see when building or customizing document templates. For SaaS platforms that want to offer document workflows as a native feature, allowing customers to build their own templates in a white-labeled builder is equally important. An embedded template editor that loads at your domain, with your branding, and sends events to your application makes document creation part of your product rather than a redirect to another tool.
Common Implementation Mistakes
Missing the Email Domain
Teams that implement Level 3 (custom signing domain) without Level 2 (custom email domain) end up with a signing page at their domain but invitation emails from the platform's domain. This is the most common gap. Signers see "noreply@platform.com" in their inbox and a branded URL when they click — a jarring inconsistency that undermines the entire branding effort.
Using the Platform's SSL Certificate
Some platforms support custom domains but serve SSL certificates from their own infrastructure. The browser's security indicator (the padlock) then shows the platform's SSL certificate rather than your domain's certificate. Security-conscious enterprise clients notice this. Proper custom domain implementation requires your own SSL certificate (or the platform provisioning one for your subdomain).
Forgetting the Audit Certificate
The completed document package typically includes an audit certificate — a timestamped record of all signing events. If the audit certificate is branded with the platform's logo and name, it creates a visible inconsistency even for clients who never saw the signing page itself. Check that your platform supports custom audit certificate branding.
Zignature White-Label Configuration
Zignature's white-label features are included on the Pro plan ($29/month) and above — no Enterprise tier required. Configuration includes: custom email domain with SPF/DKIM setup, custom signing subdomain with SSL provisioning, custom logo and brand colors on all signer-facing surfaces, removal of Zignature branding from all emails and pages, and branded audit certificates. The embedded editor (for SaaS teams that want to give customers a template builder) is available as part of the Embedded API product with its own developer documentation.
Setup typically takes under an hour for DNS configuration plus the branding options within the platform. Learn more about Zignature white-labeling or start a free trial to test the configuration in your environment.