Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Start with the document delivery route
A branded PandaDoc notification should have an authentication trail that the mail administrator can explain. Begin with a harmless document and establish which workspace sends it, which address appears in From, and which domain signs the received message. Changing a logo or display name is not evidence that your domain authenticates the email. This guide covers PandaDoc’s documented white-label delivery route; it does not supply universal DNS values for every account.
PandaDoc offers white-labeling for an account or a particular workspace. Its support team supplies a DNS instruction PDF, checks the resulting records and completes activation. The feature covers specified document notifications; it does not change the document-link domain. Confirm plan eligibility and commercial conditions before requesting it. See White-label your PandaDoc delivery emails.
The documented white-label trade-off is specific: the “[Recipient name] opened Email message” event will no longer be tracked in Activity, while the “Document Viewed” notification email remains available. Confirm that sales and operations can accept this loss of email-open activity before activation; do not describe it as loss of document-view notifications. See PandaDoc white-label warning.
Define the change before requesting records
Choose an unused subdomain with the domain owner. Record the intended sending address, affected workspaces, business owner and notification types. Avoid reusing a subdomain that already handles another application’s mail without reviewing its existing records. A convenient name can conceal a conflicting MX destination, CNAME or DKIM selector. Keep a zone export or equivalent record of the current values and identify who can authorize recovery.
Make the request through PandaDoc’s supported help or Branding workflow. The issued instructions cover TXT, MX and CNAME updates. The current page notes that the PDF may label MX optional while the provider strongly recommends it; resolve its necessity and exact subdomain with support rather than changing the apex by assumption. Your DNS administrator publishes those records; PandaDoc then verifies and activates the setup after you confirm completion. Retain the instructions and activation notice as separate evidence. The provider’s white-label procedure is the source of the account-specific requirements, not a generic example copied from another organization.
For each issued record, write down the fully qualified owner name, type and value. Compare that full name with the DNS editor’s suffix behavior before saving. A relative label entered into a field that already appends the zone can be correct, while pasting the full name into the wrong interface may duplicate the domain. Check the published answer afterward rather than trusting the editor’s success banner.
Preserve existing mail while publishing
Apply records only at the approved owners. If the instructions contain an MX change, verify its exact subdomain and purpose with the DNS owner; an accidental apex change can redirect ordinary incoming business mail. Do not replace unrelated MX entries or treat an instruction for a delivery subdomain as authorization to redesign the whole domain.
Where SPF is required, merge the necessary authorization into the existing policy at that owner rather than creating a second SPF record. Review the complete policy, including nested lookups, against the restrictions in RFC 7208. Preserve unrelated TXT records. For DKIM, verify the issued selector and public record without handling or requesting the service’s private signing key.
Pause if the issued instructions conflict with existing use. Ask for corrected instructions that resolve the conflict, and keep the workspace on its previously approved route until the change owner has a safe plan. A guessed record might resolve successfully while authorizing the wrong sender.
Test the identity that reaches the recipient
After activation, send a new test document to controlled mailboxes and exercise the relevant follow-up notifications. Do not reuse an old email to judge the new configuration. Capture the UTC time, workspace, notification type, Message-ID, From, Return-Path, DKIM d= and s= values, and the receiving system’s trusted authentication results.
DKIM validation establishes a signature result for its signing domain; DMARC additionally relates a passing SPF or DKIM identity to the visible From domain. See RFC 6376 and RFC 9989. A provider-owned SPF pass can coexist with an aligned DKIM pass, so evaluate each identity instead of requiring every domain string in the header to be identical. Use the receiver’s evidence, not an untrusted authentication header inserted earlier in transit.
PandaDoc acceptance worksheet
Complete a separate row for each workspace and notification type:
- Account and workspace: ____; notification and business owner: ____.
- Approved From address and unused subdomain: ____; existing-record conflicts: ____.
- Support request reference and instruction revision: ____; eligibility confirmed by: ____.
- Issued record owner, type and value reference: ____; DNS publication evidence: ____.
- PandaDoc activation notice and time: ____; pilot sender and receiver: ____.
- Message-ID and timestamp: ____; visible From and Return-Path: ____.
- DKIM d= and s=: ____; trusted SPF, DKIM and DMARC results: ____.
- Expected aligned mechanism: ____; observed alignment: ____; recovery decision: ____.
A blank activation or receiver field means the row is incomplete. Expand the pilot only after the application owner and mail administrator can account for every critical notification in scope.
Fictional diagnosis of a missing signature request
Fictional example only: Bellwether Studio publishes its issued records and assumes a missing signature request is a DKIM failure. The first controlled document arrives with the expected aligned signature. The missing recipient belongs to a later step in a signing sequence. PandaDoc’s delivery troubleshooting guide explains that signing order can delay when a recipient’s email is sent. The team checks workflow state before making another DNS change.
If a message was sent but rejected, collect the actual rejection and receiver evidence. A local allowlist may alter one mailbox’s treatment, but it does not prove global authentication or repair domain alignment. No Bellwether account, document or DNS zone was tested for this article.
Release only the verified workflow
Keep DNS publication, provider activation, receiver authentication and business delivery as distinct acceptance items. Retain redacted headers and the approved configuration revision; exclude document contents and recipient details that the review does not need. Schedule another verification when workspaces, sending addresses or notification behavior change. Live tenant inspection, account-issued records, DNS and received-message tests, rendered review, human SME approval and publication remain pending.