How to set up DMARC/DKIM/SPF for Docusign
Published 6 Aug 2026
Updated 6 Aug 2026
11 min read
Summarize with
Docusign supports SPF return-path alignment and DKIM signing through Custom Email Domain. The working setup uses a dedicated subdomain, the DNS values generated inside Docusign Admin, and a DMARC policy covering the visible From domain. I recommend configuring both SPF and DKIM, then confirming that at least one passes with DMARC identifier alignment on a real envelope notification.
Configuration at a glance
Claim the parent domain, create a new Docusign sending subdomain, publish the generated SPF, DKIM, and MX records, verify the subdomain, then test DMARC before increasing enforcement.
Add your domain
Start in Docusign Admin with an Organization Administrator account. Custom Email Domain must be available for the organization, and the parent domain must be claimed before Docusign can create the sending subdomain.
- Claim the parent: Open Docusign Admin, go to Domains, select Claim Domain, enter example.com, and copy the generated TXT verification token.
- Publish the token: Add the TXT record at the exact host shown by Docusign. Return to Domains and select Actions, then Validate after DNS resolves.
- Enable the feature: Go to Features, find Custom Email Domain, select Manage, then Actions and Enable.
- Create a subdomain: Open Custom Email Domain, select Add Domain, enter an unused label such as docusign, choose the verified parent domain, and select Next.
- Keep environments separate: Use different subdomains for demo and production so their DNS records, test traffic, and policies remain independent.
The subdomain becomes the domain used by custom Docusign sender addresses, such as notifications@docusign.example.com. It should not already be assigned to SSO or another mail service. Docusign's domain setup steps are the source of record values for the account.
Docusign Admin domain claim and custom subdomain setup
If the menu is missing
Custom Email Domain is not enabled on every Docusign plan. Confirm the Organization Administrator role and the required Access Management entitlement. Contact Docusign support when Features does not show the option.
Set up SPF
Docusign generates the SPF TXT record and an MX record for the new Custom Email Domain. Publish both exactly as displayed. This gives Docusign a custom return path under your subdomain, so SPF can pass and match the visible From domain under relaxed DMARC alignment.
- Copy the host: Use the SPF TXT hostname shown on the Docusign DNS setup screen, without adding the parent domain twice.
- Copy the value: Paste the complete Docusign-generated SPF value. Do not substitute an observed Docusign include or copy the SPF record from docusign.net.
- Keep one record: If the subdomain already has SPF, merge authorized mechanisms into one TXT record. Two SPF records return PermError.
- Add the MX record: Publish the generated MX host, target, and priority so Docusign can handle the custom return-path workflow.
- Check the lookup budget: Confirm the evaluated SPF path stays within ten DNS-querying mechanisms.
Do not add Docusign to the parent domain's SPF merely because the visible address belongs to your organization. SPF is checked against the SMTP return-path domain, which is the dedicated subdomain in this setup.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the check against the exact return-path domain shown in a delivered Docusign message. A valid SPF record at example.com does not prove that docusign.example.com has the required record.
Use generated values only
Docusign can change its sending infrastructure. The DNS values displayed for your account are authoritative. IP allowlists documented for inbound network controls are not a substitute for the generated SPF record.
Set up DKIM
Docusign supplies two DKIM CNAME records for key rotation. Publish both records even when the first selector verifies immediately. Docusign retains the private keys and signs outgoing notifications; your DNS delegates each public-key lookup to its target.
- Copy selector one: Create the first CNAME with the host and target shown in Docusign Admin.
- Copy selector two: Create the second CNAME as a separate record so Docusign can rotate signing keys without a DNS change.
- Disable proxying: Set both CNAMEs to DNS-only when the DNS provider offers HTTP proxying. DKIM lookups require ordinary DNS answers.
- Remove conflicts: A selector hostname cannot hold both a CNAME and another record type. Delete stale TXT keys only after confirming they belong to this unused subdomain.
- Verify both selectors: Resolve each full selector hostname, confirm the expected CNAME target, then use Verify DNS Now in Docusign.
Some DNS control panels append the zone name automatically. Enter only the relative host when required, or the result becomes selector._domainkey.docusign.example.com.example.com and verification fails.
Docusign Custom Email Domain DNS records for DKIM, SPF, and MX
Expected DKIM result in a received messagetext
dkim=pass header.d=docusign.example.com
What success looks like
The Authentication-Results header shows dkim=pass, and the DKIM d= domain is the same as, or a subdomain of, the visible From domain's organizational domain. That gives DMARC a passing DKIM path.
Set up DMARC
DMARC checks the domain in the visible From address against the authenticated SPF return path and DKIM signing domain. A message passes DMARC when either SPF or DKIM passes and its domain matches under the chosen alignment mode. With Docusign Custom Email Domain, configure both paths and let DMARC report on the result.
- Check the parent policy: Look up _dmarc.example.com. Its policy covers docusign.example.com unless an sp tag or a more specific subdomain record changes that behavior.
- Keep enforcement: If the existing applicable policy is p=quarantine or p=reject, keep it. Fix Docusign authentication instead of weakening the policy.
- Start new domains safely: When no DMARC record exists, publish the monitoring record below at _dmarc.example.com and use a mailbox that accepts aggregate XML reports.
- Avoid duplicate records: Publish one DMARC TXT record at each policy hostname. Multiple records make DMARC processing fail.
Initial DMARC TXT valuedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace example.com in the reporting address with a mailbox you control. The DMARC record generator can produce the TXT value while preserving an existing enforcement policy.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Check the organizational domain first, then check the Docusign subdomain when it has its own DMARC record. Confirm that the parser returns one valid policy, a working aggregate-report destination, and the enforcement level you intended.
SPF path
The Docusign-generated TXT record authorizes the connecting sender, and the custom return-path domain matches the visible From domain under relaxed alignment.
- Required result: spf=pass with matching domains.
- Common failure: The TXT record was placed at the parent domain.
DKIM path
Docusign signs the message with a delegated key, and the d= signing domain matches the visible From domain under relaxed alignment.
- Required result: dkim=pass with a matching d= domain.
- Common failure: A selector CNAME has the wrong host or is proxied.
Verify and troubleshoot
After DNS resolves, select Verify DNS Now in Docusign. If verification succeeds, add the custom sender address, link it to the correct account, and send a real envelope notification to a mailbox where you can inspect the full message headers.
Verified Docusign custom email domain and sender setup
DNS verification proves that the expected records resolve. It does not prove that a real message used the custom return path, carried the new DKIM signature, or passed DMARC at the recipient.
Send a Docusign notification to the email tester below. It evaluates the received headers and exposes the exact SPF domain, DKIM selector, signing domain, and DMARC result in one test.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Use the final Authentication-Results header produced by the recipient, not a message preview. Forwarding can break SPF, while DKIM can survive if the signed content remains unchanged, so compare results on a direct delivery first.
- Docusign still says pending: Query each exact hostname publicly, check for automatic zone-name duplication, and wait for the record's TTL before retrying.
- SPF returns none: Read the Return-Path header and check that domain, not the visible From domain.
- SPF returns PermError: Remove duplicate SPF records, validate syntax, and reduce DNS-querying mechanisms to ten or fewer.
- DKIM returns none: Confirm the custom sender address is linked to the account and that the test came through the configured Custom Email Domain.
- DMARC fails: Compare smtp.mailfrom and header.d with the visible From domain. A raw SPF or DKIM pass does not count when its identifier does not match.
|
|
|
|
|---|---|---|---|
SPF | TXT | spf=pass | Return path |
DKIM | CNAME | dkim=pass | Signing domain |
DMARC | TXT | dmarc=pass | Policy result |
Compact checks for a delivered Docusign notification
Get alerted when it breaks
DNS checks taken during setup become stale. Docusign can rotate infrastructure, an administrator can overwrite a selector, and a DNS migration can drop records. Continuous DMARC monitoring catches authentication changes in production traffic.
Suped is our product and the best overall practical choice for this workflow. It identifies Docusign as a sending source, separates verified and unverified traffic, detects SPF or DKIM regressions, and provides specific repair steps. Real-time alerts reduce the gap between a DNS break and remediation.
- Alert on failure rate: Trigger an alert when Docusign's DMARC pass rate drops instead of waiting for recipient complaints.
- Watch source identity: Review new IPs, return-path domains, DKIM selectors, and rDNS names before marking changed traffic as authorized.
- Monitor DNS state: Detect removed records, duplicate SPF policies, lookup-limit errors, and changes to the active DMARC policy.
- Keep one operational view: Use Suped for DMARC, hosted SPF, DKIM monitoring, blocklist (blacklist) status, and deliverability diagnostics across every domain.
Manual checks
Periodic DNS lookups show current records but miss intermittent failures and do not connect a change to Docusign message volume.
- Coverage: Only when someone runs a test.
- Diagnosis: Header and XML analysis stays manual.
Suped monitoring
Aggregate reports and DNS state are analyzed continuously, with alerts tied to the affected source and practical repair steps.
- Coverage: Ongoing source and policy monitoring.
- Diagnosis: Automated detection with steps to fix.
Secure your domain with p=reject
Move to p=reject only after Docusign and every other legitimate sender consistently pass DMARC. If the applicable policy already uses p=reject, keep it and repair any failing source. Do not return to p=none for a single Docusign configuration error.
- Inventory senders: Classify every source in DMARC aggregate data, including low-volume systems and delegated subdomains.
- Fix Docusign first: Require stable DKIM alignment, SPF alignment, and clean direct-delivery tests for production envelope notifications.
- Quarantine failures: Use p=quarantine as an operational checkpoint and inspect report data for legitimate mail still failing DMARC.
- Reject unauthenticated mail: Publish p=reject after all known sources pass and owners have approved the source inventory.
- Continue monitoring: Keep alerts active after enforcement because selector changes, DNS migrations, and newly added senders can create fresh failures.
DMARC enforcement stages
Use observed authentication results to move the applicable policy forward without weakening an existing enforcement policy.
Monitor
p=none
Collect reports and identify every legitimate source.
Contain
p=quarantine
Divert failing mail while confirming no authorized traffic is affected.
Enforce
p=reject
Reject messages that fail DMARC after source validation is complete.
Suped makes this rollout operational by grouping traffic by source, identifying unverified senders, showing exact remediation steps, and alerting on changes after enforcement. Its Hosted DMARC policy staging is useful when several domains or client organizations must move through the same approval process.
Reject readiness gate
- Source status: Every legitimate sender has an owner and a passing DMARC path.
- Docusign status: Production notifications pass DKIM and SPF with the intended identifiers.
- Report status: No unexplained legitimate volume remains in the failing population.
- Alert status: Authentication and DNS-change alerts reach an accountable operator.
