How to Send Automatic Emails in Jira Easily 2026

Jira sends mail two different ways, and picking the wrong one is why so many setups end up half-working. Notification schemes are the built-in system: they map events like Issue Created or Issue Assigned to roles like Reporter, Assignee and Watchers, and they are all-or-nothing per event with no control over wording.

Automation rules are the flexible system: you define the trigger, filter it with conditions, and compose the email yourself with real issue fields in it. If you want "tell the assignee when something lands on them," the notification scheme already does that.

If you want "email the client's address when a bug moves to Done, with the issue key and a link in the subject," you need an automation rule. This guide builds the second kind.

Before building anything, check that your instance can send mail. In Jira's admin settings, the System section has a Mail group containing Global mail settings, Outgoing mail, Incoming mail and Send email.

Outgoing mail is where the sending configuration lives, and there is a Send email page for firing a test message at yourself. The General Settings block above it also holds the Email from value, which controls the display name on outbound mail and is templated by default as the acting user's full name followed by Jira.

Two things commonly bite here: outgoing mail being globally disabled after a migration, and a From name so generic that recipients can't tell which instance a message came from. Fix both now. A rule that runs perfectly and sends nothing is a miserable thing to debug later.

Open the project, go to Project settings, and choose Automation from the left menu. Create a new rule and Jira drops you into the rule builder with a single card waiting for a trigger.

Pick the event that should start the rule. Work item created is the obvious one for a new-ticket alert, and Jira notes on the panel that this trigger needs no configuration at all.

Other common choices are Work item transitioned for status changes, Field value changed for things like priority, and Scheduled if you want a digest at a fixed time instead of a message per event. The rule is created at project level here, which keeps its execution limits and blast radius contained. A Jira admin can create the same thing globally across projects if the need is wider.

Click Add component, choose New action, and pick Send customized email. Atlassian retired the plain Send email action during 2025; any existing rule still using it keeps working and was migrated automatically, but a rule you build today only offers the newer action.

The panel gives you a Recipient(s) field, a From option (your default automation address, or a custom sender address a Jira admin has configured), a required Subject, and a Content field that can be plain text, rich text or HTML. Recipients are the part worth slowing down for: you can address a role instead of a person (Assignee, Reporter, Watchers, a project role, or all customers involved on a service project), which keeps the rule correct as people change, or you can type an external address for someone with no Jira account, which is how you keep a client informed without buying them a licence. Addressing the Assignee, as in the rule shown here, means the message follows whoever the work belongs to at the moment the rule runs, not whoever it belonged to when you wrote it.

A bare subject like "Test" tells nobody anything, and this is where most automation emails fail. Smart values are placeholders in double curly braces that Jira replaces at send time, and the braces button at the corner of each field inserts them.

The useful set is small: {{issue.key}} for the ticket ID, {{issue.summary}} for the title, {{issue.status.name}} for where it now sits, {{issue.assignee.displayName}} for who owns it, and {{issue.url}} for a clickable link straight to the work item. A subject built from {{issue.key}} - {{issue.summary}} makes the inbox scannable on its own, and a body with the status, the assignee and the URL means most recipients never need to open Jira to know what happened.

Keep the body short. An automated email that reads like a report gets skimmed like one.

A trigger on its own fires for every work item in the project, which is how automation earns its reputation for spam. Add a condition between the trigger and the action to narrow it: an issue-type condition so only Bugs qualify, a JQL condition for something specific like priority in (High, Highest), or a user condition so the rule ignores changes made by the automation account itself.

That last one matters more than it sounds: rules that respond to their own edits are the classic cause of loops, and Jira's rule details also carry a checkbox controlling whether a rule may be triggered by other rules. Every condition you add is one fewer email your team learns to ignore.

Give the rule a real name in place of Untitled rule (future you will be grateful when there are fifteen of them), then click Turn on rule. Test it immediately by performing the actual trigger: create a work item, or transition one, and watch what arrives.

If nothing does, open the rule's audit log, which records every execution with its outcome and tells you whether the rule matched but the email failed, or the rule never fired at all. Those are entirely different problems: the first points at mail configuration or an invalid recipient, the second at your trigger or conditions.

Once it works, revisit it after a fortnight and ask whether people are still reading the messages. Automation earns its place by staying rare enough to notice.