Clarity SMTP Email Failures: Sender address rejected: Access denied

Products

• Clarity PPM On Premise

Issue/Introduction

Clarity users are not receiving system-generated email notifications (e.g., Job schedules, Action Items, Timesheet approvals). While custom GEL processes successfully send emails, standard Clarity application notifications fail with SMTP errors.

Background (BG) logs with com.niku.union.notification set to DEBUG (Enable email notification debug logging) shows the following errors:

• javax.mail.SendFailedException: Invalid Addresses
• com.sun.mail.smtp.SMTPAddressFailedException: 554 5.7.1 <[e-mail]>: Sender address rejected: Access denied
• CMN-05006: Unable to send mail message.

Environment

Clarity 16.4.2

Cause

This failure typically occurs when the SMTP relay server is configured to only allow emails from a specific authorized mailbox. Standard Clarity notifications often attempt to use the individual initiator's email address or the specific recipient's address as the FROM header. If the SMTP server does not recognize these addresses as authorized senders, it rejects the relay request with an Access Denied (554 5.7.1) error.

GEL scripts usually bypass this by manually constructing the session using the defaultSenderAddress defined in properties.xml, which is why they continue to work while system notifications fail.

Resolution

To resolve this, configure Clarity to force all outgoing system emails to use the authorized default sender address defined in the Clarity System Administration (CSA).

1. Edit properties.xml, add alwaysUseDefaultSenderAddress="true" within the <mailServer> tag.
2. Save the changes.
3. Restart the Clarity Background (BG) service for the changes to take effect.

Additional Information

Clarity Notification Emails from One Mailbox