How to set up DMARC/DKIM/SPF for PandaDoc
Published 20 Jul 2026
Updated 20 Jul 2026
15 min read
Summarize with
PandaDoc can send authenticated document emails through a custom sending subdomain. Request email white-labeling, publish the exact SPF, DKIM, MX, and CNAME records PandaDoc supplies, then publish DMARC for the domain in the visible From address. PandaDoc verifies the records and activates the domain before it carries live document mail.
I recommend a dedicated subdomain such as pd.example.com. It keeps PandaDoc authentication separate from employee mail and makes rollback simple. White-labeling is available on Enterprise plans and as a paid add-on for eligible Business Annual plans. The connected business email path is different: PandaDoc sends through the connected mailbox, so that mailbox's existing SPF and DKIM configuration applies.
White-label delivery
- Best for: A branded PandaDoc sending address on a dedicated subdomain.
- DNS owner: Your team publishes PandaDoc's supplied records.
- Authentication: Custom return-path and DKIM signing can match your From domain.
- Activation: PandaDoc support verifies DNS and enables sending.
Connected business email
- Best for: Sending PandaDoc documents through a user's mailbox.
- Availability: A closed beta on Business and Enterprise plans.
- DNS owner: The mailbox administrator maintains its existing records.
- Important: Do not add the white-label DNS package for this path.
Add your domain
PandaDoc white-labeling is a support-assisted setup, not a self-service domain form. An account owner or workspace administrator starts the request, selects the sending scope, and gives PandaDoc a domain and unused subdomain. I use a host such as pd.example.com instead of the organizational domain itself.
- Check eligibility: Confirm Enterprise access or the white-label add-on on an eligible Business Annual plan.
- Open Branding: Select the gear icon, open Branding under the current workspace, find Email white-labeling, and select Send request.
- Use Help instead: Open Help, select Product help, choose Set up white-labeling, complete the form, and select Create ticket.
- Define scope: Choose account-wide or one workspace, then provide the registered domain, sending subdomain, and local part such as docs.
- Wait for records: PandaDoc registers the sending domain and emails a PDF containing the exact TXT, MX, and CNAME values for your account.
- Publish and notify: Add every supplied record at your DNS host, preserve the shown hostnames, then reply to the ticket so PandaDoc can verify and activate the domain.
Do not guess record values or copy another PandaDoc customer's DNS. Verification tokens, DKIM keys, tracking CNAMEs, and routing hosts can differ by account or region. A DNS host might append your zone name automatically, so enter only the label when its interface expects one.
PandaDoc Branding settings with the email white-label request control
Once the request is active, keep the ticket open until PandaDoc confirms activation. Publishing DNS only prepares authentication. PandaDoc must also complete its side before the custom From address is used. Send no production document through the new subdomain until that confirmation arrives.
White-label behavior change
After PandaDoc enables white-labeling, its Activity view no longer tracks the event that says a recipient opened the email message. Document Viewed notifications still work. Record this change before activation so support teams do not mistake it for a delivery failure.
Set up SPF
Publish the SPF record at the exact hostname in PandaDoc's PDF. For a dedicated sending subdomain, that normally means the SPF policy lives on the subdomain used by the envelope sender, while the organizational domain keeps its existing employee-mail SPF record.
- Find the host: Copy the SPF hostname and value directly from the white-label PDF.
- Check for SPF: Query that exact hostname before publishing. A hostname can have only one SPF TXT policy.
- Merge if needed: If an SPF policy already exists at that host, add the supplied mechanism before its final all term. Never publish a second SPF policy.
- Keep one terminator: The merged value must contain one final all mechanism, using the qualifier PandaDoc supplied.
- Count lookups: Keep the evaluated SPF policy within the ten DNS-lookup limit, including nested includes and redirects.
- Publish once: Save the TXT record, wait at least one DNS TTL, and re-query the same hostname.
The following line shows the record shape only. Replace the placeholder with the include domain shown in your PandaDoc instructions. If the PDF provides a different qualifier or additional mechanism, the PDF wins.
SPF structure for the PandaDoc sending host
v=spf1 include:PANDADOC-SUPPLIED-SPF-DOMAIN ~all
PandaDoc white-label delivery supports a custom return-path, so SPF can pass DMARC alignment when the return-path and visible From domains share the same organizational domain. I still verify this in a received message because a valid SPF record alone does not prove PandaDoc used that domain.
Enter the precise PandaDoc envelope-sender host below. The check should return one policy, no syntax errors, and fewer than eleven evaluated lookups.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If the checker reports multiple SPF records, combine them before continuing. If it reports a lookup-limit error, remove unused senders or use managed SPF processing. Do not replace live employee-mail authorization just to add PandaDoc.
When the connected business email beta is used instead of white-label delivery, the connected mailbox sends the message. Do not add PandaDoc's white-label SPF mechanism for that route. If a sending route cannot provide a custom return-path, SPF alignment can fail without breaking DMARC, provided an aligned DKIM signature passes.
SPF completion check
- One policy: The envelope-sender hostname returns exactly one SPF record.
- Valid result: The policy parses without void-lookup or recursion errors.
- Header proof: A live PandaDoc message reports SPF pass against your custom return-path.
- DMARC match: The return-path shares the visible From organizational domain.
Set up DKIM
PandaDoc supplies the DKIM selector, record type, hostname, and target or public key. Publish them exactly. Do not invent a selector, change a CNAME into TXT, or reuse a DKIM key from another domain.
- Copy the selector: Use the host PandaDoc gives you, including the _domainkey label and custom sending subdomain.
- Preserve the type: Create TXT when the PDF says TXT and CNAME when it says CNAME.
- Avoid doubled zones: If your DNS host appends example.com, enter only the relative record name.
- Keep key text intact: Remove no characters from a TXT public key. DNS interfaces can split quoted strings without changing the resolved value.
- Resolve publicly: After one TTL, query the full selector hostname and compare its result character for character with the PDF.
- Request verification: Tell PandaDoc the records resolve and wait for activation before sending a live document.
The white-label PDF can contain more than one DKIM-related record. Publish every row. Multiple selectors can support key rotation, and tracking CNAMEs are separate from the DKIM selector even when they appear in the same DNS table.
PandaDoc white-label DNS instructions with the DKIM row highlighted
These placeholders show where the selector and supplied value go. They are not publishable values. The selector in a received DKIM-Signature header must resolve to the public record PandaDoc supplied.
DKIM record structure only
Host: <selector>._domainkey.pd.example.com Type: TXT or CNAME, exactly as supplied Value: <PANDADOC-SUPPLIED-DKIM-VALUE>
A DNS lookup proves publication, but only a signed test message proves that PandaDoc uses the selector. Check the d= domain in DKIM-Signature and the header.d result in Authentication-Results. Under relaxed DMARC, the DKIM domain can be a subdomain of the visible From organizational domain.
Do not publish a guessed key
A copied key can resolve cleanly while every PandaDoc signature fails. If the PDF and public DNS differ, correct DNS first. If they match but live mail has no matching signature, keep the DMARC policy unchanged and ask PandaDoc to confirm activation.
Set up DMARC
DMARC belongs at _dmarc under the domain in the visible From address. If PandaDoc sends from docs@pd.example.com, publish a subdomain policy at _dmarc.pd.example.com when you want separate control. Otherwise, the organizational-domain DMARC policy can govern the subdomain through normal DMARC discovery.
- Read the From domain: Use the actual white-label sender on a delivered PandaDoc message, not the Reply-To address.
- Check the parent: Find the policy already governing that From domain before creating another record.
- Keep enforcement: If the governing policy is quarantine or reject, do not downgrade it to none. Fix PandaDoc authentication under the existing policy.
- Start monitoring: For a domain with no DMARC policy, publish the record below and make sure the rua mailbox accepts reports.
- Use one record: A DMARC hostname must return one complete TXT policy, not separate TXT records for separate tags.
- Collect normal traffic: Keep monitoring through document sends, reminders, completion notices, and expiration notices before enforcing.
For a new policy, I start with p=none so reporting begins without asking receivers to quarantine or reject failures. Use the DMARC record generator if you need to change the report address or add subdomain handling.
Initial DMARC record
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Do not weaken an existing policy
If your domain already uses p=quarantine or p=reject, keep that policy. A new p=none record on the PandaDoc subdomain can override stronger parent handling for that subdomain. Verify SPF or DKIM alignment before sending production documents.
After publishing, query the exact _dmarc hostname. The result should contain the version first, one policy tag, and a valid aggregate-report address. DNS validity still does not prove that PandaDoc mail passes, so keep the activation ticket and a live test in the workflow.
Use the checker below against the visible From domain. If a parent policy applies, confirm the result explains that inheritance instead of assuming a missing subdomain record means no protection.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A valid result should show the policy you intended and the correct report destination. If the checker finds two DMARC records, consolidate the tags into one TXT value. If it finds no record, confirm whether your DNS host doubled the zone name.
Aggregate reports usually arrive after receivers finish a reporting interval, so the first useful PandaDoc data is not immediate. Keep p=none until normal notification types appear and the report data identifies the custom sending domain as authorized.
Verify and troubleshoot
Verification needs a real PandaDoc document notification, not only DNS checks. Send a low-risk test document to a mailbox where you can inspect raw headers, then trigger at least one reminder and completion message because notification paths can differ.
- Confirm activation: Wait for PandaDoc to say the white-label domain is active.
- Send a document: Create a test document, add a controlled recipient, select Send, and preserve the received message.
- Check visible From: It should use the custom address and subdomain agreed in the ticket.
- Inspect return-path: The organizational domain should match the visible From domain for relaxed SPF alignment.
- Inspect DKIM: The signature selector must resolve, and its d= domain must match the From organizational domain under relaxed mode.
- Read DMARC: Authentication-Results should show dmarc=pass, with SPF or DKIM providing an aligned pass.
- Repeat events: Test delivery, reminder, completion, and expiration notifications that your workspace uses.
Expected authentication results
spf=pass smtp.mailfrom=pd.example.com dkim=pass header.d=pd.example.com dmarc=pass header.from=pd.example.com
A message can pass DMARC with only one aligned method. With PandaDoc white-labeling configured fully, I expect both SPF and DKIM to pass and match the From domain. If SPF alignment fails but aligned DKIM passes, DMARC can still pass. Fix SPF, but do not treat that single failure as a DMARC outage.
PandaDoc send step used to generate an authentication test email
The fastest end-to-end check is a test mailbox that reads the received message, DNS state, and authentication headers together. It catches cases where DNS is correct but the active sending route still uses a default domain.
Send a PandaDoc notification to the unique address shown below, then open the resulting diagnosis. Use a real notification generated after white-label activation, not a forwarded copy, because forwarding can change authentication results.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Compare the report with raw headers. The key fields are visible From, return-path, DKIM d=, selector, and DMARC disposition. Save one passing sample as your baseline so later incidents can be compared against a known-good message.
|
|
|
|---|---|---|
SPF permerror | Duplicate policy or lookup limit | Merge records and recount lookups |
DKIM neutral | Selector does not resolve | Correct host or CNAME target |
DKIM fail | Wrong key or altered message | Compare DNS with the supplied key |
DMARC fail | Neither pass matches From | Check return-path and DKIM domain |
Default From | White-labeling is not active | Reopen the PandaDoc ticket |
No recipient mail | Address, signing order, or filtering | Check activity and resend |
Common PandaDoc authentication faults and the next check
When a recipient gets no message, verify the address and signing order before changing DNS. Then check PandaDoc Activity, resend the notification, and inspect the recipient gateway response. Authentication problems and workflow delays can look identical to the sender.
Get alerted when it breaks
DNS checks show current records, while aggregate reports show what receivers saw in production. Suped, our DMARC platform, turns those reports into source-level results and alerts. For this PandaDoc workflow, Suped is the best overall fit for most teams because it identifies authentication changes and gives concrete repair steps without requiring manual XML review.
Connect the rua address to DMARC monitoring, label PandaDoc as an authorized source after confirming its identifiers, and set alerts before changing policy. The useful trigger is a change in pass rate or a newly seen source, not a one-off forwarded message.
- Route reports: Use the Suped reporting address in rua and confirm report receipt.
- Verify PandaDoc: Match source IPs, return-path domains, DKIM domains, and known test headers before marking the source authorized.
- Set thresholds: Alert on rising DMARC failures, disappearing DKIM passes, new unverified sources, and policy changes.
- Add recipients: Send alerts to the DNS owner and the PandaDoc workspace administrator.
- Review weekly: Check authorized volume, failures, unknown traffic, and policy status.
- Correlate reputation: Use unified blocklist (blacklist) and deliverability signals when authentication passes but delivery drops.
Notification settings page with DMARC alerts, weekly summary, toggles, and preview buttons
Enable DMARC alerts and the weekly summary, then preview both messages so recipients know what they will receive. Keep a human owner on the alert list. Automated detection helps only when someone can change DNS or reopen the PandaDoc activation ticket.
What Suped should detect
- SPF regression: The PandaDoc return-path stops passing or no longer matches From.
- DKIM regression: A selector disappears, the key changes, or signing stops.
- Source change: New infrastructure begins sending with your PandaDoc From domain.
- Policy drift: The DMARC record becomes invalid or enforcement weakens.
When an alert fires, use the affected source, failing method, first-seen time, and DNS state to decide who owns the repair. PandaDoc signing failures usually go back to the PandaDoc ticket; duplicate SPF or DMARC records go to the DNS owner.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's issue view keeps the failure evidence and repair sequence together. That is useful when PandaDoc rotates a key, changes a source, or stops using the custom return-path, because the team can compare the current message path with the known-good baseline before editing DNS.
Secure your domain with p=reject
Move to p=reject only after every legitimate sender has a stable aligned SPF or DKIM pass. PandaDoc should appear as authorized across ordinary document delivery and the automated notifications your workspace uses. A quiet test day is not enough if some messages run weekly or monthly.
- Inventory sources: Classify every source using the From domain, including PandaDoc reminders and completion notices.
- Cover normal cycles: Observe at least seven days, and longer when legitimate mail runs less often.
- Fix both methods: Aim for aligned SPF and DKIM on PandaDoc even though DMARC requires only one.
- Stage quarantine: Apply p=quarantine to a small percentage, watch failures, then expand to all traffic.
- Pause on impact: Stop the rollout when authorized PandaDoc mail fails both aligned methods.
- Enforce reject: Move to p=reject after quarantine is stable at full coverage and unknown traffic is understood.
- Keep monitoring: Continue alerts after enforcement so a key rotation does not turn into rejected document mail.
I treat p=none as discovery and p=reject as an operating state. The difference is ongoing ownership. Reject is safe when someone watches source changes, approves new senders, and responds to authentication failures before recipients notice.
Before enforcement
- PandaDoc status: Authorized with stable SPF and DKIM results.
- Coverage: Normal notification types appear in reports.
- Unknown mail: Investigated and either authorized or unwanted.
- Ownership: DNS and PandaDoc escalation contacts are recorded.
After enforcement
- Policy state: p=reject applies to all intended mail.
- Alerting: Failures and policy changes reach named owners.
- Change control: New senders are tested before production use.
- Evidence: A known-good PandaDoc message remains available.
Use staged records only when your receivers honor percentage sampling. Some handling can vary, so watch real results at every step and be ready to restore the last stable policy. Keep each record as one TXT value.
Staged DMARC enforcement records
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Publish one line at a time, never all lines together. Suped's hosted DMARC workflow can stage policy changes without repeated hand edits, while its source view checks whether PandaDoc remains authenticated during the rollout.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
For teams with several domains or frequent sender changes, Suped keeps hosted policy staging, PandaDoc source verification, SPF and DKIM monitoring, real-time alerts, and repair guidance in the same workflow. That makes p=reject maintainable after the initial project ends.
- Final PandaDoc check: Delivery, reminder, completion, and expiration mail all pass DMARC.
- Final DNS check: SPF has one policy, DKIM selectors resolve, and DMARC has one record.
- Final report check: Authorized volume is stable and unknown sources are understood.
- Final ownership check: Alert recipients can edit DNS or contact PandaDoc support.
Once these checks remain stable at full quarantine, publish p=reject and continue monitoring. Do not remove the rua destination after enforcement. Reports are the signal that catches later PandaDoc infrastructure or DNS changes.
FAQ
PandaDoc authentication depends on the sending path, the domain visible to recipients, and whether white-label activation has finished. These answers cover the checks that most often block a clean rollout.
Keep the PandaDoc support ticket, DNS change record, one passing raw message, and the current DMARC policy together. Those items give the DNS owner enough evidence to diagnose a later failure without guessing.
