Why Cloudflare sits at the edge

OhRelay needs a place where domain-level email handling and programmable logic can meet. Cloudflare provides both sides of that equation: routing for mail that arrives at the domain and Workers that can execute routing logic close to the edge.

That combination matters because OhRelay is not just trying to forward mail. It needs to recognize which visible address a customer contacted, apply the right routing rule, and carry the right sender context into the reply path.

Why Cloudflare-managed DNS makes onboarding smoother

When a domain is managed through Cloudflare, the DNS and mail-routing layers are already close to the same control plane. That makes setup simpler, faster, and more predictable.

Cloudflare can also import existing DNS records from another provider, which lowers the migration burden for most customers. The result is an onboarding path that feels like one connected product rather than a manual checklist spread across several dashboards.

How route detection works

The key question is straightforward: which managed address did the customer write to, and where should mail for that address go? OhRelay answers that question by reading recipient-related headers and matching them against configured routing rules.

That means route detection is based on message metadata, not on the body of the email. The system looks at the intended recipient address, resolves the configured destination, and carries forward the correct reply context.

  • Read recipient-related headers
  • Match the visible address against configured routes
  • Attach the correct destination and sender context to the conversation

What the Worker layer is responsible for

The Worker layer is where OhRelay applies programmable enforcement. Once the system has enough metadata to identify the intended visible address, it can add the right routing and reply context before the operator ever touches the thread.

It is also the right place to enforce safer failure behavior. If the system cannot establish a strong enough address context, the safer move is to block or defer the risky action instead of guessing.

What OhRelay does not need to read

OhRelay does not need to inspect the message body to decide where a managed address should route. The routing problem is about address recognition and configuration, not about interpreting the content of the conversation.

That creates a clearer privacy boundary. OhRelay relies on headers and routing rules to make delivery decisions, rather than reading private message content in order to decide where mail belongs.