Skip to main content
Idea Submitted

Email Deliverability in Envelope History + Webhooks for SMTP Acceptance

Categories:eSignature
  • September 1, 2025
  • 1 reply
  • 28 views

Hengfeng Ge
Hero
Forum|alt.badge.img+18

Product Areas
eSignature / API / Connect

Problem
High-volume senders (e.g., >1,000 envelopes/day) frequently face “recipient didn’t receive email.” Today we must open Support cases to confirm whether the recipient’s mail server returned SMTP 250 (accepted). This creates a compliance loop (customer consent), long MTTR, and heavy manual workload (~1% delivery exceptions already strain teams). Delays impact our customers’ business and increase complaint risk.

Proposal

  1. Envelope History: Email Delivery pane
    Show per-recipient metadata only:

  • accepted (Y/N), smtpCode (e.g., 250), masked smtpMessage snippet, acceptedAt timestamp

  • masked mxHost, tls (Y/N), retryCount, bounceCategory (soft/hard/other)
    Controls: admin-toggle, configurable retention (30–90 days), CSV export. Default OFF to respect privacy by default. This gives frontline users immediate, self-serve evidence for “accepted by recipient server vs. blocked/quarantined later.”

  1. Connect: Deliverability events
    Add webhooks to enable automation:

  • EmailDeliveryAccepted (fire when recipient MX returns 250)

  • EmailDeliveryFailed (fire when explicit rejection or retries exhaust)
    Payload includes minimal, masked metadata (e.g., smtpCode, timestamp, hashed MX) so customers can trigger automatic fallbacks (e.g., SMS notification, re-send from alternate channel, or internal admin review) without opening Support cases.

Security & Compliance

  • Metadata-only (no email content or PII beyond standard recipient identifiers).

  • Feature is opt-in (admin-controlled) and fully audited (access and events).

  • Data minimization: masked MX/message details; configurable, short retention.

  • Behavior is backward-compatible: when disabled, nothing new is exposed.

Acceptance Criteria (examples)

  • When the recipient server returns 250, Envelope History shows accepted=true with timestamp; if enabled, an EmailDeliveryAccepted event is emitted.

  • When delivery is rejected or retries exhaust, UI shows non-250 details (masked) and an EmailDeliveryFailed event is emitted.

  • CSV export reflects exactly the on-screen metadata fields.

  • With the feature disabled, neither UI elements nor events appear.

Impact / Priority
P1. Dramatically reduces Support cases and MTTR, removes compliance friction, enables at-scale automation for exception handling, and protects customer NPS as send volumes grow. This solution focuses on what operators need most: clear, self-serve deliverability evidence inside the envelope and machine-readable webhooks to close the loop automatically.

 

FreeLink/甫连信息
🌍 DocuSign Partner | Partner Profile
🌟The only DocuSign Partner globally with two Certified eSignature Technical Consultants

🏆 DocuSign 2025 APAC Growth  Engine Partner of the Year
💡 Ranked #1 in the OG All Star category in DocuSign Community Wrapped 2024
📊 DocuSign Community Leaderboard Top 5 contributor
🚀 Expertise in DocuSign integrations with on-premises systems for leading enterprises across various industries
🔗 Connect with me on LinkedInhttps://www.linkedin.com/in/gehengfeng

📬 For business inquiries, feel free to connect via :

WeChat/微信: +86 1381880287

WhatsApp: +65 97796938

1 reply

Forum|alt.badge.img+14
  • Community Moderator
  • February 26, 2026

Thanks for submitting this idea, ​@Hengfeng Ge. We appreciate you taking the time to share it with us.

Our team is actively working through all submitted Ideas, and while there’s no update to share just yet on this one, we’ll follow up if there’s a status change. Thanks for your patience and input.