Customer email replies captured, not lost

A signed inbound route captures replies to platform-sent email, strips the quoted history, resolves the tenant, and stores the message idempotently.

What it is

A receiver that verifies Mailgun's HMAC-SHA256 signature with a freshness window, identifies the real sender from the From header (falling back to the envelope), resolves the recipient domain to an account, prefers the stripped reply text over the full body, and deduplicates on the Message-Id.

Also called: reply to estimate email · inbound email · email came back · reply capture

See it
Customer email replies captured, not lost
Area
Integrations
Group
Email delivery
System
Mailgun
Solves
3 named problems
01Signature and timestamp are verified in constant time within a 15-minute window.
02The sender is taken from the From header, unwrapped from the display-name form, with the envelope as fallback.
03The recipient is resolved to a tenant, or held under a sentinel when ambiguous.
An inbound email rendering in the thread as a clean reply with the quoted chain collapsed away. Sample data — no customer information appears here.
How it works
  1. 1Signature and timestamp are verified in constant time within a 15-minute window.
  2. 2The sender is taken from the From header, unwrapped from the display-name form, with the envelope as fallback.
  3. 3The recipient is resolved to a tenant, or held under a sentinel when ambiguous.
  4. 4stripped-text is preferred so the stored body is what the person actually wrote.
  5. 5Storage is idempotent on the Message-Id; a genuine write failure returns 500 so Mailgun retries.
Why we built it

The route explains that this leak does not wait for a provider switch: 'It matters even while every tenant is GHL-primary, because email has a FALLBACK CHAIN: the moment a GoHighLevel send fails, Mailgun carries the message instead, and the reply comes back to the Mailgun domain rather than the GHL inbox. So this leak does not wait for A2P — it opens on any GHL hiccup, silently, mid-conversation.' The sender-identification rule was found in testing: a message whose From header named a person 'arrived with sender=postmaster@... matched nothing, and stopped there.' The identity choice is also explained: 'Message-Id is the stable identity across retries; the token is per-delivery and would defeat deduplication.'

The problem
  • Replies arriving on the fallback provider's domain were lost.
  • Envelope-based sender matching failed for forwarders and relays.
  • Retried deliveries would have created duplicate messages.
Sound familiar?
What you get
Replies land in the thread with the quoted history removed.
Forwarded and relayed mail still matches the right person.
Retries never duplicate a message.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →