Guide

How to stop out-of-office replies becoming tickets in Jira Service Management

For Jira Service Management Cloud · Updated November 2026

Short answer: Jira already drops auto-replies that carry the standard "Auto-Submitted" header, but many out-of-office messages and bounces don't carry it. Block the worst senders with the blocklist, then add an automation rule that closes or deletes new requests whose subject starts with "Automatic reply", "Out of office" or "Undeliverable". Make sure closing them doesn't email the sender, or you can start a reply loop.

Why it happens

When your notification reaches a customer who's away, their mail server sends an automatic reply. That reply lands in your support mailbox, and Jira treats it like any other email: a new request, or a comment on the original one.

Jira filters some of it already. Atlassian's email processing skips messages whose Auto-Submitted header says auto-generated, auto-replied or auto-notified. It also skips most delivery failure reports, and the emails Jira sent itself. The rest gets through, typically:

Out-of-office messages from mail systems or settings that don't add the header
"Thanks for your email, we'll get back to you" auto-acknowledgements from other companies' help desks
Bounces that look like normal emails, such as "Undeliverable", "Mail delivery failed" or "Address not found"
Newsletters and marketing emails sent to your support address

Option 1: Block repeat offenders

Go to Channels & self service → Email → More → Manage blocklist and add the address or domain. It's quick, but limited:

Matching is exact. Blocking example.com doesn't block mail.example.com, and wildcards aren't supported.
It works for no-reply addresses and newsletters. It doesn't help when a real customer's out-of-office reply comes from their normal address, because blocking them blocks their real requests too.

Option 2: Close them with an automation rule

This catches auto-replies from anyone, based on the subject. In your service space, go to Space settings → Automation → Create rule:

Trigger: Work item created.
Condition: JQL condition, for example:
summary ~ "Automatic reply" OR summary ~ "Out of office" OR summary ~ "Undeliverable" OR summary ~ "Delivery Status Notification" OR summary ~ "Auto-reply"
Add the phrases your customers' languages use, such as Abwesenheitsnotiz or Réponse automatique.
Action: one of these:
- Transition it to a closed status with a resolution such as Won't do. You keep a record and can spot mistakes.
- Delete work item. Your queue stays clean, but there's no record and no undo.
Name the rule, turn it on, and test it by emailing your support address with one of the subjects.

Start with closing rather than deleting. Look at what got closed after a week, then tighten the phrases if a real request was caught.

Don't start a reply loop

If your rule closes the junk request and Jira emails the sender "your request was resolved", their out-of-office replies again, which creates another request, and so on. Before turning the rule on:

Check your customer notifications (in your space's notification settings). Make sure the transition your rule uses doesn't send a "request resolved" email. One way is a dedicated "Junk" status and transition that customers aren't notified about.
Or use the delete action, which doesn't email anyone.

What about replies on existing tickets?

If the auto-reply keeps the request key in the subject (for example, "Automatic reply: RE: [SUP-123] Printer down"), Jira adds it as a comment on SUP-123 instead of creating a new request. That's mostly noise rather than harm, but it can reset an SLA or move the status if your workflow reacts to customer comments. Review any automation that reopens or transitions requests when a customer comments, and add a condition that ignores comments starting with the same phrases.

Related guides

Want it done for you?

I set up Jira Service Management email, filtering and automation for small and mid-size teams, for a fixed price. See the setup service.