Skip to main content
Submit a Request

Troubleshooting: SecureAuth CIAM Does Not Send Verification Code or Password Reset Emails

Ben Watts
Updated
    Applies to:
  • CloudEntity
    Deployment model:
  • Cloud

Version Affected: All
 
 

Overview

SecureAuth CIAM does not send emails such as one-time verification codes and password reset links, so users cannot sign in, verify their email address or reset their password. In some cases users receive several copies of the same email before the emails stop.

Start with the workspace's Audit Logs. Each code SecureAuth CIAM tries to send is recorded as an otp event with the action sent or not_sent. For users in an organization, these events are in the organization's own audit logs. SecureAuth Support can find the underlying email error in the SecureAuth CIAM service logs using the trace ID of a failed request. Find the error you see in the list below; each entry links to its cause. The causes are not related, so a fix for one cause will not resolve another.

 

In this article


 

Cause 1: The Custom SMTP Server Rejects SecureAuth CIAM's Credentials

With a custom SMTP message provider, such as your own mail server or Amazon Simple Email Service (SES), SecureAuth CIAM signs in to the SMTP server with the username and password configured for the provider. When the server rejects them, every email fails with:

External error from smtp: 535 Authentication Credentials Invalid

SecureAuth CIAM retries emails that fail, so while the server keeps rejecting them the send queue fills up. Users can receive several copies of the same email and then nothing at all, and the queue may not clear by itself once the credentials are fixed.

A server can also return 535 errors on and off, together with timeouts, while the credentials are unchanged, for example when it limits the number of connections or the sending rate.

 

Resolution 1:

To resolve this:

  1. Go to Tenant Settings > Message Providers > Emails and check the Username and Password of the custom SMTP provider with the owner of the SMTP account. Re-enter them if they have changed, and save.
  2. Under Send test message, enter an email address you can check and click Send. Confirm that the test code arrives.
  3. If the credentials are correct but 535 errors still appear on and off, check the SMTP account's sending quota, maximum send rate and connection limits, and whether other applications share the same account.
  4. If users still receive no emails, or keep receiving duplicates, after the test message succeeds, ask SecureAuth Support to clear the tenant's email send queue.

 

Cause 2: The Custom SMTP Server Does Not Respond in Time

SecureAuth CIAM waits about 10 seconds for the custom SMTP server to accept each email. When the server does not answer in that time, both real emails and test messages fail with an error such as:

failed to send email using smtp.office365.com smtp server from <sender>: timed out

The server is unreachable from the internet on the configured port, is rejecting the sign-in method, or is too slow to respond.

 

Resolution 2:

To resolve this:

  1. Go to Tenant Settings > Message Providers > Emails and confirm the SMTP Host and SMTP Port, for example port 587 for TLS.
  2. Confirm that the SMTP server accepts connections from the internet on that port.
  3. Confirm that the SMTP Auth Mechanism is one the server supports. For Microsoft 365, use LOGIN, and make sure the sending mailbox is allowed to use authenticated SMTP.
  4. Send a test message from Send test message. If the server cannot be fixed quickly, switch the email provider to SecureAuth's built-in email while you investigate. If you do, see Cause 3 first.

 

Cause 3: A Custom Sender Address Is Still Set for SecureAuth's Built-In Email

SecureAuth's built-in email service only sends from sender addresses that SecureAuth has verified. If a provider is switched from a custom SMTP server back to the built-in service and the sender address from the custom configuration is left in the sender identification field, every email is rejected with:

failed to send email using sa smtp server from <sender>: 554 Message rejected: Email address is not verified

 

Resolution 3:

To resolve this:

  1. Go to Tenant Settings > Message Providers > Emails and confirm that SecureAuth's built-in email is selected.
  2. Clear the sender identification field, which is left over from the custom SMTP configuration, and save.
  3. Send a test message from Send test message and confirm that it arrives.

 

Cause 4: The User Signs In on the Wrong Sign-In Page

The sign-in page at /identity/built-in-admin-pool/login is for tenant administrators. A user who signs in there, instead of on their organization's or application's own sign-in page, is not in that identity pool, so SecureAuth CIAM cannot find the user's email address and sends nothing. No sent event is recorded, and the service logs show:

failed to send otp to <email>
Error(404, unable to find the resource, Error(404, unable to find the resource))

 

Resolution 4:

To resolve this:

  1. Ask the user which web address (URL) they used to sign in.
  2. Give the user the sign-in link for their organization or application, and ask them to update any bookmark that points to /identity/built-in-admin-pool/login.
  3. Ask the user to sign in again and confirm that the code arrives.

 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

Comments

0 comments

Please sign in to leave a comment.