Skip to main content

    707 Ideas

    Email Deliverability in Envelope History + Webhooks for SMTP AcceptanceIdea Submitted

    Product AreaseSignature / API / ConnectProblemHigh-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 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.” 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 / PriorityP1. 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 LinkedIn: https://www.linkedin.com/in/gehengfeng📬 For business inquiries, feel free to connect via :WeChat/微信: +86 1381880287WhatsApp: +65 97796938