Skip to main content
Newcomer
September 17, 2026
Question

Demo account — envelope notifications never delivered to either recipient, no bounce, resends produce nothing

  • September 17, 2026
  • 1 reply
  • 27 views

Hi all,

On our developer sandbox account, notification emails for one envelope were never delivered to either recipient. Both recipients have since confirmed directly that nothing arrived — inbox, spam and promotions all checked. Two manual resends produced nothing either. The envelope was eventually completed, but only because we reached the signers outside DocuSign; no notification email ever arrived for it.

Setup: eSignature REST API, JWT Grant, demo environment (demo.docusign.net), two signers at the same routing order, both ordinary emailed signers.

The audit trail records the invitations as sent, and records no bounce. Neither recipient ever moved to autoresponded, and neither carries an autoRespondedReason:

  23:22:23Z  Registered        Envelope created
  23:22:25Z  Sent Invitations  invitation to recipient 1
  23:22:25Z  Sent Invitations  invitation to recipient 2
  23:34:32Z  Resent            resent to recipient 1
  23:35:12Z  Resent            resent to recipient 1

A comparable envelope on the same account 85 minutes earlier was delivered normally. Same sender, same notification settings, same signing location, reminders off, same expiration. Both of its recipients opened and signed within minutes. One address is a recipient on both envelopes — it received the 21:48 one and did not receive the 23:22 one. The other address is not new to this account either; it has 16 completed envelopes on it from the past month.

Ruled out, with evidence:

- Envelope allowance — unlimited on this plan; 53 sent in the current period
- API limits — 2,977 of 3,000 remaining for the hour, burst 199 of 200
- Embedded/captive misclassification — at send time both recipients had no clientUserId, no embeddedRecipientStartURL, no suppressEmails, and deliveryMethod: email
- Account email suppression — inSessionSuppressEmails is on, but we are not using embedded signing for these, so it does not apply
- Recipient-side filtering — two unrelated providers (a university domain and Gmail), both previously receiving DocuSign mail on this same account, both silent for this envelope
- Recipient count — two recipients, within this plan's 5-signer limit, and no "cumulative recipient limit has been exceeded" error was returned at any point
- Configuration drift between the working and failing envelope — compared field by field; they match

One thing to disclose so it is not mistaken for the cause: about 23 minutes after the failures above, to get one signer in another way, we created an embedded recipient view for recipient 1, which set a clientUserId and made that recipient captive. From that point on no email to that recipient would be expected. The failure reported here is the earlier window — the original send and both resends, when both recipients were ordinary emailed signers. It also does not explain recipient 2, who was never made captive and received nothing.

My question: I have read the thread where a moderator explained that the demo environment runs strict fraud-detection checks because of spam and phishing abuse, and that when a send is flagged the notification is held and an internal adjustment is needed to mark the account safe. This looks like exactly that: DocuSign accepts the send, records the invitation, records no bounce, and no mail is produced.

Could a moderator check whether this account's sends are being held by those checks, and if so flag the account as safe? Happy to send the account ID, account name, sender address and the failing envelope ID by private message — I have kept them out of this post since it is an open channel.

Thanks.

1 reply

jnguyenNewcomerAuthor
Newcomer
September 17, 2026

Following up with a result that changes my own diagnosis, in case it helps anyone who finds this thread later.

It is not an account-level hold. It is one recipient address — and an envelope carrying that address delivers to nobody on it, whatever the routing order, not just to the flagged recipient.

I isolated it with two controlled tests.

Test one — is it the address? Two envelopes, same account, same sender, same document, one recipient each, sent three seconds apart. One address received it. The other never did.

Test two — is it the address or the document? The envelope that fails names that person inside its PDF, so the document was a live suspect. I sent that same document to a different recipient, alone, alongside a control document to the same recipient. Both arrived. So the document is innocent: the packet reaches that recipient when sent by itself, and was silent only when the flagged address was a second recipient on the envelope.

One earlier piece of my evidence was wrong and I want to correct it rather than leave it standing. I first read a failing envelope as whole-envelope suppression when it was fully explained by sequential routing — the flagged person was recipient 1, so recipient 2 was never due a notification. That case proves nothing. The one that does is an envelope where the flagged address sat at routing order 2 and the order-1 recipient still received nothing.

Nothing in the API distinguishes any of this. Both log Sent Invitations, neither recipient moves to autoresponded, neither carries an autoRespondedReason, and resending is recorded as though it worked — I resent one envelope four times across two hours and it never produced mail.

I have read "Understanding Docusign's Fraud and Spam Protection" and the notification-suppression behaviour there matches what I am seeing. My questions:

1. Is that address flagged, and can it be cleared? Nothing in the UI, in Admin or in the API exposes a suppression list to an account holder.

2. Is it intended that one flagged recipient suppresses delivery for everyone else on the envelope? This is the part worth documenting if so. The person who reports the missing email is usually not the flagged one, which sends you looking at entirely the wrong thing — it took me two days and six envelopes.

3. Is there any API field that would let an integration detect it? Right now a flagged recipient and a successful send are byte-identical from our side, and we only learn of it from a signer who says nothing arrived.

4. For a workflow where a named approver must sign, "use a different address" is not always available. Is there a supported route other than contacting support each time?

Happy to send the account ID, the address and the envelope IDs by private message.