Users will keep emailing support long after you launch a beautiful portal. Meet them where they are: connect the mailbox to Jira and let every email arrive as a tracked ticket instead of a forgotten thread.
Every service project in Jira Service Management can receive requests by email. The project gets its own address, and later you can connect the mailbox your users already know. Either way, the mechanics are the same: an incoming message becomes a request with the sender as customer, the subject as summary, the body as description and attachments carried across. Agent replies leave as email; customer replies return to the same ticket. This page sets that channel up properly and is honest about its three catches - messy subjects, unknown senders, and the slow training job of moving people to the portal for anything structured.
Each service project comes with a ready-made email address on your Atlassian site domain - it looks like [email protected]. There is nothing to configure on a mail server: turn the email channel on in the project settings, publish the address, and mail starts becoming tickets.
This is the fastest way to test the channel and a perfectly good permanent address for an internal desk. Its one weakness is human, not technical: it is a new address your users must learn, and it looks like Atlassian's domain, not yours. That is why most teams treat it as the starting point and connect their own mailbox next.
Jira can connect to a Google Workspace or Microsoft 365 mailbox - your existing support address - and pull its mail into the project. The connection is authorised by the mailbox owner, and from then on the familiar address behaves like the project address: mail in becomes tickets, replies flow both ways.
Two disciplines for this step. First, dedicate the mailbox to support - connecting a personal inbox imports a person's whole correspondence into a ticket system, which nobody wants. Second, tell your users nothing changes for them: same address, but now with tracking behind it. The best helpdesk upgrades are invisible to the people being helped.
When mail arrives from an address Jira does not know, the sender is created as a customer on the spot (on projects whose settings allow new customers from email) and their message proceeds as a normal ticket. For an internal desk with restricted access, mail from outside the organisation is rejected instead - check which behaviour your project has before you promise the address to anyone.
This is also where the spam question lives. A published support address will eventually attract junk. The portal can be locked down tightly; an inbox cannot. Keep the project's customer permissions deliberate, and review the created-customer list occasionally the way you would review any guest list.
The channel only pays off if the thread stays whole. Agent replies sent from Jira arrive as email in the customer's inbox; when the customer hits reply, that message returns and lands on the ticket - history in one place, visible to the whole team, immune to any one agent's leave or laptop failure.
The failure mode is the side conversation: an agent phones the user, fixes it, and the ticket sits open and timeless. Close that loop with a ten-second habit - a comment on the ticket saying what was done, then resolve. The goal is not bureaucracy; it is that the next person with the same printer problem finds this ticket in search instead of starting from zero.
Email is the lowest-quality intake channel, and the blogs in this series will keep saying so. Subjects arrive as 'Help' or 'Urgent' or a forwarded chain with the real problem in paragraph four. There is no form, so the fields your queues and reports want - request type, location, urgency - are absent or guessed. Attachments can be blocked by your mail security before Jira ever sees them.
So run both channels with clear roles: email for "I just need to tell someone", portal for anything with structure - access requests, hardware, new starters. Then watch the mix monthly. A healthy desk sees email share shrink slowly as users learn the portal gives them tracking. It never reaches zero, and planning for zero is how teams end up secretly running two helpdesks.
See every screen of the Jira helpdesk setup live, from the empty project to the first real ticket.
Watch Full VideoYes. When someone emails the project address, they are created as a customer (if the project allows it) and their message becomes a ticket. They can then follow and reply by email, and optionally use the portal later with the same email identity.
Start with the built-in address to prove the flow, then connect your existing support mailbox (Google or Microsoft) so users keep the address they know. Use a dedicated support mailbox, never a personal one, because everything sent to it becomes helpdesk data.
Normally yes - attachments on the incoming message are added to the created ticket. Very large files or types blocked by your organisation's mail security can be stripped before Jira receives them, which is one reason the portal is the better channel for structured requests.