DocuSign SPF, DKIM and DMARC setup, step by step

Docusign's Custom Email Domain feature lets eligible organizations send notifications from a branded subdomain. Claim and verify the parent domain, create the dedicated subdomain, publish the DNS records generated by Docusign, verify them, then link the custom email address to the intended accounts. For the current AWS SES migration, DNS validation and switching each linked account to Amazon SES are separate steps. Custom Email Domain overview, current migration procedure.

This guide covers Docusign Organization Administration for eSignature and CLM accounts identified as CLM.DS in the documentation. It does not assume that every Docusign product or subscription has these controls.

Check your entitlement and sending route

The current feature overview, requires the Access Management with SSO add-on. You also need organization-administrator access and someone authorized to change the authoritative DNS zone. A standard account administrator or a branding editor may not have the required organization controls.

Default notifications may use addresses such as dse@docusign.net or dse-demo@docusign.net. Customizing a display name or Reply-To does not itself authenticate a branded From domain. Record the production/demo environment, verified parent domain, dedicated sending subdomain, custom address and linked accounts before planning changes.

Use the current AWS SES migration dates

The migration task updated October 1, 2026 states:

• Production: October 12, 2026 through April 30, 2027.
• Demo: August 10 through October 30, 2026. That documented deadline has already passed as of this review.
• New CEDs created during the corresponding migration periods use AWS SES for enablement and verification.
• Missing the required DNS updates and account migration by the deadline disables the custom email domain, with account messages reverting to the default Docusign From address.

This is a branded-sender continuity issue, not a documented claim that all email sending stops. An earlier August release announcement gives October 1 as the production start. Use the dedicated migration task for this procedure and confirm the actual provider shown for each account rather than inferring migration from either date.

Prepare a new custom email domain

First, claim and verify the organization's parent domain. Docusign's setup requires a new subdomain for custom email and excludes subdomains already used for SSO. For example, sign.example.com could be a proposed dedicated name, but do not reuse a subdomain that already receives business mail or serves another application.

The documented setup path is:

1. In Organization view, open Features, find Custom Email Domain, select Manage, then Actions > Enable.
2. Open Custom Email Domain > Add Subdomain.
3. Enter the new subdomain name and select the verified parent domain.
4. Obtain the DNS records displayed for that configuration.
5. Publish the exact owners, types and values through your authoritative DNS administrator, then select Verify DNS Now. If necessary, save the domain and verify later.

The July 2025 add-subdomain page describes two DKIM CNAMEs, one SPF TXT and one MX record. That older fixed count is not a universal template for the current SES configuration. The newer migration task requires SES-specific records supplied in Docusign Admin. Follow the complete current record set shown for your account, including all generated DKIM entries, SPF owner and MX priority. Never omit a third or otherwise additional generated entry to make the screen match an old tutorial.

Migrate an existing custom domain in two stages

Stage 1: publish and verify the SES DNS records

As organization administrator, open Custom Email Domain and work through each configured subdomain. Under Actions > Edit, choose Export DNS Settings. Give the current export to the DNS administrator, compare it with existing records and publish the required changes. Return to Actions > Edit > Verify DNS Settings and check the resulting Amazon SES status. Official migration steps.

Preserve the export's record owners, values and MX priorities. Before publication, compare each generated MX destination, owner and any routing IP with the separately authorized sending/bounce and inbound-mail routing plan. Obtain approval for those consequences; possessing an export does not authorize redirecting existing mail or other services. Do not delete legacy DKIM keys or replace working records prematurely while linked accounts still depend on the legacy route. If a generated owner conflicts with an existing service, stop and reconcile the conflict with the domain owner and Docusign rather than combining incompatible record types.

Stage 2: move the linked accounts

After the subdomain verifies for SES, edit it, select the intended custom email address and inspect Linked accounts. Change the Provider from Docusign Mail Servers to Amazon SES, then save. Docusign also documents a bulk Selected > Move to Amazon SES provider action. DNS verification does not execute this account switch for you. Linked-account migration.

Approve the exact accounts and timing of each provider switch before applying it; DNS validation is not authorization to migrate other linked accounts. For a controlled rollout, validate one authorized account before extending the change to the rest. Keep a list of every account's actual provider and test result. A domain with ten linked accounts is not fully verified by one account's successful sample.

Link a custom address and keep replies separate

Once the subdomain is verified, use its Actions menu to add a custom email address. Enter the From and Reply-To display names and addresses, select the accounts to link, review, then save the email address. The address-linking guide allows up to 60 minutes for changes to apply.

Reply-To can be an existing monitored address outside the custom subdomain. For example, a From address at sign.example.com could direct replies to contracts@example.com. That does not make example.com the SPF or DKIM identity. Check the actual message rather than using a Reply-To field as evidence of domain alignment.

Docusign says CED email has TLS enforced. Transport encryption is separate from DKIM, SPF and DMARC. None of these mechanisms proves that a particular agreement is expected or that its business terms are safe to accept.

Publish generated DNS values safely

These are owner-format examples only. samplekey and bounce.sign are fictional labels, not promised Docusign selectors or envelope owners.

A separately delegated sign.example.com zone would use different relative labels, such as samplekey._domainkey and bounce. If _domainkey.sign.example.com itself is delegated, the DKIM owner belongs in that authoritative zone at samplekey. Preserve that delegation, its DNSSEC chain and existing selectors. Some DNS editors require the full name instead. Confirm the final public owner to avoid a doubled example.com suffix. CNAME and MX targets are hostnames, not web URLs; use exact exported values and MX priority.

Preserve your root-domain MX records. A generated MX at a dedicated sending/bounce owner must not replace the corporate inbox's MX merely because the records share a parent domain. A CNAME owner cannot also host ordinary TXT, MX, A, AAAA or another CNAME. Keep any issued authentication or bounce CNAME unflattened. In Cloudflare, use DNS only, turn the record's Flatten option off, and check that zone-wide CNAME flattening for all CNAME records is off. DNS-only alone is insufficient. Coordinate shared-setting changes with the DNS owner and review effects on other records first. If NS records legitimately delegate the child zone elsewhere, publish at that authority rather than deleting its delegation to force validation. If mandatory apex or same-zone flattening cannot preserve the required literal CNAME, stop and agree a supported hostname/design with Docusign and the DNS owner. Do not invent an off switch or remove shared delegations. Confirm that public DNS exposes the issued CNAME target. Cloudflare CNAME verification, flattening settings.

For an SPF TXT record, keep exactly one policy beginning v=spf1 at each owner. If the export intersects an existing SPF owner, reconcile it with all legitimate senders rather than adding a second policy. SPF's ten evaluated DNS-dependent-term limit includes nested include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not consume that term budget. Any all mechanism makes redirect ineffective: SPF ignores the redirect when all is present. Preserve the existing qualifiers and redirected authorization design; do not add all while merging without understanding that change. Qualifiers do not guarantee delivery or rejection. SPF redirect rule. Do not flatten changing provider ranges casually or paste allowlisted receiving IPs into SPF as a substitute for the generated instructions. SPF limits and publication.

Understand SPF, DKIM and DMARC alignment

SPF authorizes the connecting sending server for the SMTP MAIL FROM identity, or HELO for a null reverse-path. That identity may differ from the visible From and must be read from the trusted receiver's result. Putting a Docusign or SES include on example.com cannot force a provider-owned return path to align. Use the actual generated envelope configuration and message evidence. SPF MAIL FROM.

DKIM uses a signature's d= domain and s= selector to locate its public key. Docusign generates the DNS requirements and controls the matching signing process. Publish every requested public record; never generate an unrelated key pair or publish private key material. DKIM signature fields.

DMARC passes when at least one of SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment allows the same organizational domain; strict alignment requires identical domains. For example, a passing d=sign.example.com exactly matches From: notices@sign.example.com. A passing SPF identity at bounce.sign.example.com can align in relaxed mode but not under strict aspf=s. A passing d=example.com with that From sign.example.com aligns in relaxed mode but not strict adkim=s. These are illustrative relationships, not predictions of Docusign's emitted headers. For help interpreting results, see EmailAuth's raw DKIM results versus aligned DKIM policy results. DMARC alignment rules.

Retain DMARC policy and reporting

Inspect the applicable policy for the custom subdomain and its parent before activation. Preserve existing p, alignment modes and reporting destinations. Do not weaken enforcement just to conceal a newly introduced authentication problem.

Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring plan, an observation policy can be introduced with a monitored aggregate-report destination while all legitimate senders are evaluated. For example:

Owner: _dmarc.sign.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is an example for a newly planned policy, not a Docusign requirement and not a replacement for an existing policy. Use a real approved mailbox, not the example address. For _dmarc.sign.example.com, use relative _dmarc.sign in the parent example.com zone or _dmarc in a separately delegated sign.example.com zone. A root policy at _dmarc.example.com uses _dmarc in its parent zone. Provision the mailbox first and publish one DMARC record per owner. Compare the Organizational Domain of the domain where the policy was found with the Organizational Domain of the reporting URI host. When they differ, the report-generating receiver must check destination DNS authorization. A destination within the same Organizational Domain is excepted even when the hostnames differ. RFC 9990 section 4. That protocol check is separate from the domain owner's data-sharing/privacy approval for the recipient and report contents. Review reports for both legacy and SES traffic during migration. Move toward enforcement only after legitimate routes pass alignment; reporting does not itself fix authentication.

Validate public DNS and actual notifications

Replace every fictional value with the corresponding exported or observed value. The commands are read-only examples, not results from this review.

dig +short NS example.com
dig +short CNAME samplekey._domainkey.sign.example.com
dig +short TXT samplekey._domainkey.sign.example.com
dig +short TXT bounce.sign.example.com
dig +short MX bounce.sign.example.com
dig +short TXT _dmarc.sign.example.com
dig +short TXT _dmarc.example.com

Query every generated DKIM owner. A CNAME must match its exported target and resolve onward to the provider's public key. SPF must be the correct single policy at the issued envelope owner, and MX must match the issued owner, target and priority. Compare authoritative and recursive DNS answers if caches disagree. NXDOMAIN, SERVFAIL, malformed values and CNAME collisions require diagnosis, not an indefinite propagation wait. The older setup guide mentions 24 hours; do not treat elapsed time as proof that the records are correct.

For delivered-message acceptance, arrange harmless, separately authorized notifications from each linked account and environment. Do not send actual confidential contracts as an authentication test. Inspect the recipient's original headers. Use only Authentication-Results created within its verified mail-system trust boundary. Have the receiving administrator identify the authoritative authentication service and confirm how forged inbound fields are filtered. A matching authserv-id, header position or sender-supplied result alone cannot establish trust. RFC 8601, section 7.1.

For a branded DKIM implementation, require both a passing intended DKIM signature and alignment, even if SPF alone makes DMARC pass. A passing provider-owned DKIM signature does not satisfy this branded-DKIM test. Distinguish SPF pass-but-unaligned from genuine SPF failure. Investigate fail/softfail authorization errors, permerror from malformed/duplicate policies or excessive lookups, and temperror from transient DNS faults. A DKIM-based DMARC pass does not erase an unresolved SPF defect.

Troubleshooting

For escalation, preserve the current export, affected account/environment, DNS owners, provider status, UTC test time and redacted headers. Never include signed agreements or recipient details unless necessary and authorized.