How to White-Label Your E-Signature Emails and Signing Links

If you're embedding e-signatures into your product, you probably don't want your users getting emails from a vendor they've never heard of. When a customer receives a signing request, it should come from you.

Firma.dev gives you two options here. You can send emails from your own domain so everything looks like it's coming from your company. Or you can turn off Firma.dev's emails entirely and handle notifications yourself through webhooks or your own email system.

This post covers both approaches.

What We Mean by White-Labeling

White-labeling means your users interact with your brand, not ours. When they get an email asking them to sign a document, it comes from your email domain. When they sign, they don't see a screen asking them to accept Firma.dev's terms.

From your user's perspective, the e-signature functionality is just part of your product. They don't know or care that Firma.dev is powering it behind the scenes.

This matters most for SaaS platforms, HR software, legal tech products, and any application where e-signatures are a feature rather than the core product. You want the experience to feel native, not bolted on.

Option 1: Send Emails from Your Own Domain

By default, Firma.dev sends signing request emails from our domain. If you'd rather have them come from your company, you can add your own domain in the dashboard.

Head to your workspace's domain settings, add your domain, and verify it. Once that's done, all the signing-related emails (requests, completions, reminders, cancellations) will come from notifications@yourdomain.com instead of Firma.dev.

This is a workspace-level setting, so if you're running a multi-tenant product, each workspace can have its own custom email domain. Customer A gets emails from notifications@customera.com, Customer B gets emails from notifications@customerb.com. Fully isolated.

The email content stays the same, but the sender is your domain. Your users see a familiar address, which builds trust and keeps the experience consistent with your brand.

Option 2: Turn Off Firma.dev Emails Entirely

If you want full control over your email flow, you can turn off Firma.dev's transactional emails and handle everything yourself.

Four settings control which emails we send:

• send_signing_email – the initial "please sign this document" notification

• send_finish_email – the completion confirmation when all signers finish

• send_expiration_email – the reminder when a request is about to expire

• send_cancellation_email – the notification when a request gets cancelled

All four default to true. Set any of them to false, and we won't send that email. Set all four to false, and we stay completely out of your email flow.

You can configure these settings in a few places:

• Via the API when creating a signing request

• In the template creation screen in the dashboard

• In the signing request creation screen in the dashboard

The typical pattern for teams who want full control is to turn off all Firma.dev emails and use webhooks to trigger their own. When a signing request is sent, you get a webhook event. When someone signs, you get an event. When the document is complete, you get an event. You use those to send your own emails from your own system.

This gives you complete control over the copy, the design, the sender address, and the timing. Your emails, your brand, your rules.

Disable the Firma.dev Terms Acceptance Screen

By default, signers have to accept Firma.dev's terms and conditions before they can sign a document. This is a brief interstitial screen that appears when they open the signing link.

If you want to remove this screen, there's a workspace setting called "Require Terms Acceptance." Turn it off, and signers go straight to the document without seeing our terms.

A note on this: if you disable our terms screen, you're taking on the responsibility of informing signers about the legal implications of their electronic signature. We recommend having your own terms and conditions that cover e-signature consent. This keeps you aligned with frameworks like ESIGN, UETA, and eIDAS without relying on ours.

Workspace-Level Settings for Multi-Tenant Products

If you're building a SaaS product where each of your customers needs their own branded experience, workspaces give you that isolation.

Each workspace can have:

• Its own custom email domain

• Its own terms acceptance setting

• Its own templates and signing requests

• Its own API key

So Customer A can have emails from their domain with the terms screen disabled, while Customer B uses a different domain with the default settings. Each workspace is completely separate.

Check out the customer workspaces feature page for more on multi-tenant architecture.

Putting It Together

Here's a quick rundown of your options:

Want branded emails? Add your domain in workspace settings. Emails come from notifications@yourdomain.com.

Want to send your own emails? Turn off the four email settings and use webhooks to trigger your own notifications.

Want to remove the Firma.dev terms screen? Disable "Require Terms Acceptance" in workspace settings and use your own terms.

You can mix and match. Some teams use custom domains but keep Firma.dev's email templates. Others turn off everything and handle the whole flow themselves. It's flexible.

What's Coming

We're actively building more white-label capabilities. Custom branding in the signing UI, branded completion certificates, and more. This post covers what's available today. When the full suite ships, we'll publish a comprehensive guide in the docs.

Wrapping Up

White-labeling your e-signature emails keeps the experience consistent with your product. Whether you want emails from your domain or complete control over the notification flow, Firma.dev gives you the tools to make it happen.

Get started with Firma.dev for free – no credit card required.