Envelope shows "Sent" but recipient never receives the signing invitation email — identical account, identical payload, only the sending server's network differs

Hi all — I found a couple of similar threads here (linking below) but no resolution, and I've now isolated this about as far as I can from the outside. Hoping someone from DocuSign or with deeper API experience can help.

Setup: Integrating via the eSignature REST API (JWT Grant / impersonation) from our own Laravel backend. Envelopes are created successfully and show status: sent (correct recipient, correct document, correct routing order), but the recipient's signing-invitation email never arrives — not in inbox, not in spam.

What's been ruled out, with evidence:

• Payload correctness — verified the exact JSON sent to POST /v2.1/accounts/{accountId}/envelopes is well-formed and never sets clientUserId (so the recipient isn't misclassified as an embedded signer, which I know can silently suppress email).
• "Suppress emails to embedded signers" — checked and disabled on the account; not applicable anyway since clientUserId is never sent.
• Recipient-side filtering — tested with multiple previously-unused recipient addresses across Gmail, a business domain, and an Italian ISP webmail. All fail identically from one origin, all succeed from another (see below).
• Consent — confirmed via successful JWT token exchange immediately before each send.
• Recipient's own account notification prefs (My Preferences → Notifications → Recipient Notifications → "I have an envelope to sign") — checked, enabled.
• Reproduced on two independent developer/demo accounts, ruling out one flaky account.
• Reproduced with a completely fresh queue worker process, ruling out any client-side caching/stale-code explanation.

The one variable that correlates with success/failure: the exact same code, exact same payload shape, exact same DocuSign account — sending from two different networks:

Direct API comparison of a successful vs. a failing envelope, pulled via GET /v2.1/accounts/{accountId}/envelopes/{envelopeId} and .../recipients right after each send:

• Both resolve to the same real account (sender.accountId identical on both — interestingly, not the account_id we thought we'd configured for API calls, but that's a separate quirk, not the cause here since it's identical either way).
• Both show recipient status: "sent", deliveryMethod: "email", recipientType: "signer" — byte-for-byte identical in every field except sender.ipAddress and the timestamps.
• No delivery-failure flag, no different status, nothing DocuSign's own API surfaces to distinguish the two.

So from where I'm standing: DocuSign accepts the API request identically in both cases and records an identical envelope/recipient state, but only one of the two actually results in an email reaching the recipient. Since the only outstanding difference is the originating IP/network (a well-known hosting-provider ASN vs. a widely-shared, high-reputation range), I'm wondering if there's some account/organization/IP-based trust or anti-abuse mechanism on DocuSign's side that holds back the notification email specifically, without ever surfacing an error via the API.

Envelope ID example (failing): [removed] Envelope ID example (succeeding): [removed] Account ID: [removed]

Has anyone seen this before, or know what to check/request from support to get past it?