Turn a support address into Jira issues with Cloudflare Email Routing

How it fits together

Most email-to-Jira tools ask for a mailbox: a password, an OAuth grant to your inbox, or an address they host. Bastion Helix takes the opposite route. You keep your mail where it is, and your own mail routing forwards each message to a private address that belongs to one email channel. The app never logs in anywhere, never holds a mailbox and never sends email.

Cloudflare Email Routing is the simplest way to do the forwarding if your domain's DNS is already on Cloudflare: it is free, it receives mail for any address on your domain, and a few lines of Email Worker code hand each message on.

What you need

• A domain whose DNS is on Cloudflare, with Email Routing available on it.
• Bastion Helix installed in Jira, and project administrator rights on the project the mail should land in.
• About fifteen minutes.

Step 1 — Create the channel in Jira

1. In Jira, open the project and its Bastion Helix page from the project sidebar.
2. Find Email handling and choose New channel.
3. Give it a name (for example Support), and choose what new mail becomes — the issue type.
4. Optionally fill in Only accept mail from (for example acme.com, *.acme.com) and Never accept mail from. Leave the first blank to accept anyone.
5. Save. The channel shows a private address. Copy it.

Step 2 — Turn on Email Routing

1. In Cloudflare, open your domain, then Email → Email Routing.
2. If it is off, turn it on and let Cloudflare add the DNS records it asks for.

Step 3 — Create the Email Worker

1. In Email Routing, open Email Workers → Create.
2. Name it, for example bastion-helix-support.
3. Replace its code with the script below, paste your channel address between the quotes, and Deploy.

// Cloudflare Email Worker — forwards every mail to Bastion Helix.
const ADDRESS = 'PASTE YOUR CHANNEL ADDRESS HERE';

export default {
  async email(message) {
    const raw = await new Response(message.raw).text();
    const res = await fetch(ADDRESS, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ raw }),
    });
    if (res.status >= 500) message.setReject('Jira could not take this message right now. Please send it again later.');
    else if (!res.ok) message.setReject('This address does not accept mail.');
  },
};

The channel's setup screen shows this same script with your address already filled in, so you can copy it from there instead. The two setReject lines matter: if Jira can't take a message, the worker refuses it, and the sender's mail server returns it to them with that note. Nothing disappears silently.

Step 4 — Route an address to the worker

1. Open Routing rules → Create address.
2. Enter the address people will write to, for example support@.
3. Action: Send to a Worker. Destination: the worker you just deployed. Save.

Step 5 — Send a test and read the mail log

Send an email to the new address from an account the channel accepts. Within a few seconds an issue appears in the project: the subject becomes the summary, the body becomes the description, and the sender is matched to a Jira user when one has that email address.

Reply to that email and the reply lands as a comment on the same issue, with the quoted history stripped. A reply is matched to its issue by the email's own reply headers, or by an issue key such as KAN-10 in the subject. Attach a file and it arrives as an attachment.

Then open the channel's Mail log. Every message that reached the channel is listed, including the ones it ignored, with the reason.

What gets ignored, and why

If nothing arrives

• No line in the mail log: the message never reached the channel. Check the routing rule points at the worker, and that the worker's ADDRESS matches the channel's current address exactly.
• A line saying the sender was refused: the allow-list or block list stopped it. Adjust the channel's sender lists.
• The sender got the message back: the worker refused it because Jira couldn't take it right then, or the address was wrong. The bounce carries the worker's note.

Using Postmark, SendGrid or Mailgun instead

Anything that can make an HTTPS POST can deliver mail to a channel. The channel's setup screen has instructions for each:

• Postmark — paste the channel address as the inbound stream's Webhook URL. Attachments included.
• SendGrid — add it as an Inbound Parse destination and tick POST the raw, full MIME message, or files are left out.
• Mailgun — a route that forwards to the address. Mailgun sends files as form uploads the app can't read, so text arrives and the log notes the missing files.