# Corporate Email Safeguard (/docs/learn/whats-new/corporate-email-safeguard)


**2026-05-11** | Profile

**Summary:** Verdocs now applies the same corporate-email requirement to both self-service signup and organization invitation resend flows. If the email address belongs to a major consumer webmail provider, the request is rejected with guidance to use a work-owned email address instead.

**Who this affects:** Developers testing signup flows, admins resending organization invitations, growth teams linking self-service onboarding pages, and integrators automating organization onboarding workflows.

***

## Why we added this safeguard [#why-we-added-this-safeguard]

Self-service onboarding works best when organizations are tied to identifiable business contacts. Using generic consumer inboxes makes it harder to:

* associate accounts with real companies
* support customers effectively
* reduce throwaway or mistyped registrations
* maintain clean B2B onboarding flows

This safeguard only applies to specific account and organization entry points. It does not affect document recipients or signing participants.

***

## Where it applies [#where-it-applies]

### 1. Self-service signup (Create profile) [#1-self-service-signup-create-profile]

The validation runs when:

* a user registers through the unauthenticated Create Profile signup flow
* the request is creating a brand-new organization/account
* the submitted email passes normal formatting validation

This does not affect adding members while already authenticated inside an existing organization. If self-service signup is disabled in your environment, this flow may not be publicly exposed.

#### Affected APIs [#affected-apis]

The signup flow is exposed through:

* the REST API Profiles endpoints
* the JS/TS SDK signup/profile helpers

Exact endpoint naming may vary slightly by release.

***

### 2. Resend organization invitation [#2-resend-organization-invitation]

When an administrator resends a pending organization invitation, the invitee email address is validated against the same corporate-email rules before Verdocs sends the invitation again. This prevents teams from bypassing the safeguard by switching to personal inboxes during invitation resend flows.

#### Affected API [#affected-api]

The resend flow is handled through the organization invitation resend endpoint. Always confirm the exact route and request shape against the live API reference for your environment and API version.

***

## What “corporate email” means [#what-corporate-email-means]

The email address must:

1. be syntactically valid
2. use a domain that is not on Verdocs’ maintained consumer-webmail blocklist

***

### Commonly rejected domains [#commonly-rejected-domains]

Examples typically rejected include domains associated with:

| Gmail   | Yahoo      |
| ------- | ---------- |
| Outlook | Hotmail    |
| iCloud  | ProtonMail |
| AOL     |            |

The exact blocklist can evolve over time.

***

### Commonly accepted domains [#commonly-accepted-domains]

Examples typically accepted include:

* `you@acmecorp.com`
* `you@yourbrand.com`
* `you@lawfirm.co.uk`
* `you@partner-company.io`

Custom domains hosted through Google Workspace or Microsoft 365 are treated as corporate domains because the domain belongs to the organization.

***

### Subdomains [#subdomains]

Subdomains are evaluated normally.

For example: `you@mail.yourcompany.com` is treated as a corporate domain if the full domain is not on the consumer-provider blocklist.

***

## What users see when validation fails [#what-users-see-when-validation-fails]

The API returns an error message directing the user to use a corporate email address.

Typical messaging:

> Please use your corporate email address

Your application should surface this message clearly or present equivalent wording with the same meaning. There is no override flag for these protected flows.

***

## What this does not change [#what-this-does-not-change]

This safeguard does **not** affect:

* envelope recipients
* document signers
* external participants invited to sign documents

People signing documents can still use personal email addresses. This validation specifically applies to:

* unauthenticated self-service profile creation
* organization invitation resend operations

Other organization and member-management APIs may use different validation behavior depending on the operation.

***

## Guidance for integrators and QA [#guidance-for-integrators-and-qa]

| Situation                           | Recommendation                                                                                       |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Automated signup tests              | Use a domain your organization controls instead of personal Gmail accounts.                          |
| CI or staging environments          | Use dedicated test domains or subdomains.                                                            |
| “Sign up with Google” discussions   | Treat social login as a separate product capability from raw email/password signup.                  |
| Customers using only personal email | Route through sales, support, or organization-admin invitation flows instead of self-service signup. |
| QA for invitation resend            | Expect the same corporate-email validation behavior during resend testing.                           |

***

## Multi-tenant SaaS note [#multi-tenant-saas-note]

If you build a multi-tenant SaaS product on top of Verdocs, you should still use dedicated organization-scoped service identities and API credentials for each customer organization.

This safeguard does not replace normal tenant-isolation or organization-management practices.