Brand addresses customers write to
- support@brand-a.com
- founder@brand-a.com
- billing@brand-a.com
- hello@brand-b.com
- sales@brand-c.com
It is not just forwarding. It is identity-aware inbox routing.
OhRelay keeps the front-stage brand identity stable while letting the real work happen in the inboxes your team already uses. That is the business difference, and it is also the technical difference.
Unified inbox
- Unified receiving
- Reply directly
- No manual sender switching
Replies still go out as
- Reply as support@brand-a.com
- Reply as founder@brand-a.com
- Reply as billing@brand-a.com
- Reply as hello@brand-b.com
- Reply as sales@brand-c.com
Business-first walkthrough
What is happening across one real conversation
The easiest way to understand the product is to follow one branded conversation from inbound email to outbound reply.
Customer writes to a branded address
The outside world still interacts with support@, billing@, sales@, or another brand address instead of learning anything about your internal inbox structure.
OhRelay matches the visible identity
The system resolves which branded identity the customer contacted, rather than treating the message like generic forwarding with no reply context.
Mail lands in the mapped working inbox
That identity is routed into the inbox that should actually process the work, whether it belongs to an owner, one operator, or a small remote team.
The operator replies from the usual workflow
The operator continues inside Gmail, Outlook, or Apple Mail instead of switching into another mailbox stack or logging across multiple brand accounts.
The branded sender is restored on the way out
The reply returns with the same visible sender identity the customer originally wrote to, which is the part ordinary forwarding usually cannot guarantee.
Technical trust
The implementation model underneath the business story
Technical readers do not need setup-guide depth here, but they do need to see that the product behavior comes from explicit routing and identity handling rather than hand-wavy forwarding tricks.
Domain connection and ownership
A brand domain has to be connected before branded identities on that domain can be managed. Cloudflare is the lightest onboarding path, but the model is not limited to Cloudflare-only teams.
Identity-to-inbox mapping
The owner or admin defines which visible addresses flow into which working inboxes. Several identities can point to the same destination when that matches the real operator structure.
Inbound resolution
Inbound mail is matched against explicitly managed routes so the system knows which identity and destination inbox belong to the conversation.
Reply sender restoration
The reply path keeps enough identity context to restore the branded sender rather than leaking the operator's default mailbox.
Fail closed when identity is unclear
If the system cannot prove which branded identity should be used, it should stop instead of guessing. The design goal is to avoid brand mistakes, not to mask ambiguity.
Next step
Understand the fit, then decide whether the setup is worth it.
If the operating model looks right, the next question is whether your team structure and brand setup match the kinds of users OhRelay is actually built for.