Set your SAML Mode settings in Acrobat Sign to SAML Allowed
- Verify that you know your native Acrobat Sign password
- This is a precaution to avoid being accidentally locked out of your account after you change the IdP
What's New
Get Started
Administer
Send, Sign, and Manage Agreements
Advanced Agreement Capabilities and Workflows
Integrate with other products
Acrobat Sign Developer
Support and Troubleshooting
Adobe Acrobat Sign has deployed a new domain: adobesign.com.
Customers can identify their domain by logging in to Acrobat Sign and checking the URL:
If your URL reads documents.adobe.com, your domain is not changing. However, customers will need to explicitly allow email from adobesign@adobesign.com
To ensure continuity of service, customers should prepare for the domain migration by reviewing the below list of actions and addressing the issues that are germane for their account.
All impacted accounts will have the ability to switch to the new domain once their account has successfully resolved any concerns/tasks that the below list prompts.
Changing your SAML configuration requires that you opt-in to the new domain immediately after saving the new IdP settings in Acrobat Sign.
SSO to the account will be broken until the domain switch is completed.
If you are a SAML using customer, be sure to set your SAML Mode settings in Acrobat Sign to SAML Allowed
Admins that have users leveraging the Acrobat Sign for iOS mobile app should alert their users to upgrade their app version to 3.22 or later.
The Acrobat Sign for Android app is not impacted by the domain change.
Updating custom email templates must be done by your success manager or the support team.
As the templates can be updated at any time prior to changing to the new domain., it is recommended that you request this update as early as possible.
If your account uses any custom email templates, the template must be updated to allow for a reference to adobesign@adobesign.com as the email alias for users to add to their safe list..
Customers that actively restrict email should explicitly allow email from adobesign@adobesign.com
Failure to do so could result in inbound (email) agreement notifications being filtered out to spam/junk folders.
Customers with restrictive network security should explicitly allow traffic from the new domain's production endpoints.
If your current network permissions are configured to allow echosign.com traffic through, the adobesign.com endpoints should be added as well.
Environment | 'echosign' domain | 'adobesign' domain equivalent |
---|---|---|
Production | echosign.com | adobesign.com |
echocdn.com | adobesigncdn.com | |
echosignforsalesforce.com | adobesignforsalesforce.com | |
-- | documentcloud.adobe.com |
|
Demo | echosigndemo.com | adobesigndemo.com |
echocdndemo.com | adobesigncdndemo.com | |
echosignforsalesforcedemo.com | adobesignforsalesforcedemo.com |
An expanded list of Adobe Acrobat Sign endpoints can be found here, but only those listed above are relevant to this domain migration.
No edits to IP ranges are required.
Accounts that leverage the API service should review their code to ensure that it also supports the adobesign.com domain.
Refresh tokens (used to get new access tokens) are not tied to the domain, so they are not impacted by the domain change.
Customers/Partners/Integrators may have code that has a hardcoded check for the URI returned. This may be done as a security measure to prevent an exploit which attempts to redirect the domain incorrectly.
Changing your SAML configuration requires that you opt-in to the new domain immediately after saving the new IdP settings in Acrobat Sign.
SSO to the account will be broken until the domain switch is completed.
Set your SAML Mode settings in Acrobat Sign to SAML Allowed
Create a new client with your IdP (MSADFS, Okta, etc)
When migrating to a new domain, the Acrobat Sign Service Provider content on the Acrobat Sign SAML page will show the existing domain configuration.
You need to manually edit the three URLs to reflect the new domain you are migrating to.
Do not edit the:
Manually edit the:
Update the Identity Provider configurations using the values from the newly created IdP client
Log in to Acrobat Sign as an account-level admin and navigate to Account > Account Settings > Account Setup
Bookmarks to the old domain (echosign.com) can prompt multiple Cookie enablement requests when the login process shifts the user to the new domain (adobesign.com).
Users can mitigate this by updating their bookmarks.
Test your SSO connection
Adobe Acrobat Sign for Salesforce customers must relink the OAuth connection between Acrobat Sign and Salesforce (as soon as possible) after the domain has been changed.
Changing the domain breaks the trusted connection between Acrobat Sign and Salesforce. Until the OAuth link is reconnected:
Organizations that have configured Remote Site Settings for Acrobat Sign must also update the remote site URL to reflect adobesign.com (in place of echosign.com).
Navigate to Setup > Settings > Security > Remote Site Settings
Repeat steps 3-5 for all remote sites that use echosign.com as the domain for the URL.
Note that it is possible for the site URL to contain the string "echosign" in a location of the string that is not the domain. Do NOT edit these values:
Existing web forms will continue to work as expected after changing the domain.
When a web form is created, it is identified by a unique webformId (wid).
Changing the domain changes the URL of the web form, but not the webformId.
Example:
The echosign.com webform URL:
The same web form after the domain change:
Because Acrobat Sign continues to accept inbound traffic on the echosign.com domain, the URL resolves and the correct webformId is delivered.
It is recommended that customers update their content to use the URLs with the new domain when possible.
All accounts are strongly encouraged to "opt-in" to the new domain as early as possible to allow time for troubleshooting if problems arise.
Accounts can switch back to the legacy domain if problems do occur.
When you are satisfied that your account is ready to migrate:
Log in to Acrobat Sign as an account-level administrator
Navigate to Account > Account Settings > Account Setup
Click the Update now button
A check list of the important actions is presented in an overlay.
Review each point and check them off when you are confident the concern is properly addressed for your account.
Click OK when all of the boxes are checked, and then click Save:
Bookmarks to the old domain (echosign.com) can prompt multiple Cookie enablement requests when the login process shifts the user to the new domain (adobesign.com).
It is recommended that users be notified to update their bookmarks to target the new login domain.
If you have to revert back to the legacy domain for any reason, the process is the same as the initial switch.
Log in to Acrobat Sign as an account-level administrator
Navigate to Account > Account Settings > Account Setup
Click the Update now button, and then click Save
Below you will find a list of common questions about the domain migration.
If you can not find an answer for your question here, please contact your success manager or customer support.
The domain in the sample response, points to adobesign.com even if the request was made from echosign.com.
Case: Account migrated to adobesign.com domain - API call made using adobesign.com domain
1 2 3 4 |
{ "apiAccessPoint": "https://api.na2.adobesign.com/", "webAccessPoint": "https://secure.na2.adobesign.com/" } |
No.
Accounts on any *.documents.adobe.com URL are not being migrated.
Only accounts on the *.echosign.com domain are being migrated to the adobesign.com domain.
No.
The same IP ranges (listed on the system requirements page) are being used for the adobesign.com domain.
Nothing new is being added; nothing is being removed.