Jira Service Management customers don't receive password reset emails when using Proofpoint email filtering

Summary

Problem statement

When Jira Service Management (JSM) customers request a password reset for their Atlassian account or portal‑only account, the UI confirms that a reset email has been sent, but the email never arrives in the recipient’s mailbox (including spam/junk).

Atlassian’s mail logs show that:

• The email was successfully handed off to the customer’s mail server with SMTP code 250 2.0.0 ... Message accepted for delivery, and

• There are no blocks or errors on Atlassian’s side.

For affected domains, DNS MX records often point to Proofpoint (or a similar email security gateway). In these cases, Proofpoint (or another secure email gateway) is accepting the connection and then filtering or dropping the email before it reaches the user’s mailbox. This results in some customers (for example, ~2–2.5% of reporting domains) not receiving password reset emails.

Diagnosis

Steps to reproduce / confirm this is the root cause

1. User requests a password reset

   • From a JSM portal or Atlassian login screen, the user:

     • Clicks Forgot password / Reset password, and

     • Enters an email address such as user@example.com.

   • The UI indicates that a reset email has been sent.

2. No email is received by the user

   The user confirms:

   • The email is not in Inbox, Spam/Junk, Trash, Other tabs, or any custom folders.

   • No mail client rules moved the message to another folder.

   The user may have received Atlassian emails in the past from the same address, but no longer receives password reset emails.

3. Atlassian logs show successful delivery

   When you contact Atlassian Support, they check internal mail logs (Mail Tracker) for the affected email address and confirm:

   • Event type: delivery

   • SMTP response: similar to 250 2.0.0 <message-id> Message accepted for delivery

   There are no recent bounce or block events for the same address at the time of the password reset attempt.

4. Domain uses Proofpoint or another email security gateway

   Check the domain’s MX records (your mail/IT admin can do this, or you can use a public DNS lookup):

   • Run: nslookup -type=mx example.com or an equivalent DNS lookup.

   • Confirm that the MX record points to Proofpoint or another secure email gateway, for example:

     • Hosts containing pphosted.com (Proofpoint), or

     • Other third‑party filtering services sitting in front of your actual mail host (such as Microsoft 365, Google Workspace, etc.).

   In previous investigations, a majority of affected domains had MX records pointing to Proofpoint.

5. No Atlassian-side suppression / block

   Atlassian Support confirms that:

   • The recipient address/domain has been removed from Atlassian’s suppression lists (if needed), and

   • Subsequent password reset attempts still show delivery with a 250 SMTP code, but users continue to not receive the email.

Cause

If all of the above are true, the most likely root cause is that Proofpoint (or another email security gateway) is filtering or dropping Atlassian password reset emails after accepting them.

Solution

Workaround (short‑term access options)

If you need to restore access for users while your email/security team investigates filtering in Proofpoint (or other gateways), you can use one or more of the workarounds below.

1. Ask users to use the direct Atlassian reset URL

Ask affected users to trigger a password reset directly from Atlassian’s identity site:

1. Go to: https://id.atlassian.com/login/resetpassword

2. Enter the same email address used in Jira Service Management.

3. Wait a few minutes and check:

   • Inbox

   • Spam/Junk

   • Any quarantine/review folder managed by your email security gateway or mail provider

Steps to resolve (recommended long‑term fix)

The long‑term resolution is to prevent your email security gateway from filtering Atlassian password reset emails, especially when using Proofpoint.

These steps are primarily for your IT / email administrators.

1. Allowlist Atlassian email IP ranges and domains

1. Review the public Atlassian documentation and ensure all outbound email IPs and sender domains used by Atlassian are allowlisted in your email infrastructure / gateway:

   • Documentation: IP addresses and domains for Atlassian cloud apps | Atlassian Support

2. In your email security solution (e.g., Proofpoint, Microsoft 365, Google Workspace, or another secure email gateway), configure rules to:

   • Allow mail from Atlassian’s sending IP ranges and sender domains (for example noreply@id.atlassian.com, atlassian-support@id.atlassian.com, and other documented senders).

   • Ensure these messages are not:

     • Subject to overly aggressive spam/bulk filtering,

     • Quarantined by default policy, or

     • Dropped silently.

3. At the time of the original investigation, reset‑password traffic was confirmed to be sent from ranges that must be allowlisted, including (non‑exhaustive, subject to change):

   76.223.147.128/25 216.221.175.128/25

   Always rely on the latest values from the official documentation above, as IP ranges can change over time.

2. Check Proofpoint (or equivalent) message logs and policies

In Proofpoint (or a similar gateway):

1. Search message logs for:

   • Sender addresses like noreply@id.atlassian.com, atlassian-support@id.atlassian.com, or other Atlassian senders documented in the IP/domains article.

   • Recipient addresses that reported missing password reset emails (for example, user@example.com).

2. Confirm whether messages:

   • Were quarantined, or

   • Were scored as spam/bulk and dropped based on your security policies.

3. If you find such events:

   • Adjust spam/virus/bulk policies so that Atlassian messages are not treated as malicious or bulk spam.

   • Mark them as safe / not spam where your solution supports this.

   • Release quarantined messages as appropriate.

3. Verify there are no local blocks or suppression rules

In your own mail system (downstream from Proofpoint or other gateways), verify that:

1. Atlassian sender domains or IPs are not blocked or blacklisted.

2. There are no transport rules that discard or redirect these messages.

If your organization uses additional layers (for example, Proofpoint in front of Microsoft 365), make sure that allowlisting and anti‑spam exceptions are configured at all layers.

4. Ask Atlassian Support to verify suppressions and delivery per user/domain

If users still report missing password reset emails after allowlisting:

1. Collect the following for a few representative affected users:

   • Email address

   • Approximate time and timezone when they triggered the password reset

   • Their email domain and mail provider/gateway (if known)

2. Contact Atlassian Support and ask them to:

   • Verify whether the email addresses or domains are on Atlassian’s suppression lists (and remove them if necessary).

   • Confirm the latest delivery status for the reset password messages (including the SMTP response and any bounce events).

3. Once suppressions are cleared (if any) and Atlassian confirms delivery with SMTP 250 again, re‑test after you’ve completed allowlisting in Proofpoint or your email gateway.