Our customer self-service portal users aren’t receiving password reset emails when they click ‘Forgot Password’ on the subscription management login page. Internal CloudSuite users receive reset emails fine, but external customers get nothing - not even in spam folders.
I’ve verified the SMTP configuration in Infor OS Portal is correct and tested successfully, confirmed the password reset email template is active and assigned to the customer portal context, and validated the sender domain is properly verified in our email service provider. The reset request appears to submit successfully but no email is ever delivered. This is blocking customers from managing their subscriptions. Anyone encountered this?
You’re very close to resolution. Let me systematically address all three focus areas to complete the fix:
SMTP Config Checked: You’ve correctly identified the dual SMTP configuration issue and set up the subscription-specific settings. However, there’s one more critical setting: In Subscription Management > Portal Settings > Email Configuration, verify the ‘Use TLS’ checkbox is enabled and the port is set to 587 (not 25 or 465). Office 365 requires explicit TLS on port 587 for application authentication. If you’re using port 25, emails appear to send successfully in CloudSuite logs but Office 365 silently drops them.
Email Template Active: The password reset template needs specific configuration for customer portal context. Navigate to Infor OS Portal > Messaging > Email Templates > Password Reset Template. You’ll see multiple versions of this template - one for ‘Internal Users’ and one for ‘External Portal Users’. Ensure the External Portal Users version is:
Set to ‘Active’ status
Has ‘Subscription Management Portal’ selected in the ‘Application Context’ field
Uses the ‘portal-noreply@ourcompany.com’ sender address you configured
The issue is likely that your active template is the Internal Users version, which doesn’t apply to customer portal password resets.
Sender Domain Verified: Beyond verifying the domain in your email provider, CloudSuite maintains its own sender domain whitelist. Go to Infor OS Portal > Security > Trusted Domains and add ‘ourcompany.com’ to the allowed sender domains list. Also add the customer portal URL domain if it’s different (like ‘portal.ourcompany.com’). Without this whitelist entry, CloudSuite blocks external-facing emails as a security measure even though the SMTP layer succeeds.
Additional configuration:
// Pseudocode - Verify these subscription module settings:
1. Navigate to Subscription Mgmt > Portal Settings > Security
2. Set 'Allow Password Reset' = true
3. Set 'Reset Token Expiry' = 24 hours (default is 1 hour, too short)
4. Set 'Reset Email From Address' = portal-noreply@ourcompany.com
5. Save and restart the portal application service
After making all these changes, clear the email queue in CloudSuite (Messaging > Email Queue > Clear Failed) and have a test customer request a password reset. They should receive the email within 1-2 minutes. If you still see issues, check Office 365 Message Trace for emails from portal-noreply@ourcompany.com to identify if Office 365 is applying additional filtering rules.
This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
External customer emails often use a different SMTP relay than internal users. Check if you have separate SMTP configurations for ‘Internal’ vs ‘External’ user types in CloudSuite. The external SMTP settings might be pointing to an incorrect server or using outdated credentials that fail silently.
I only see one SMTP configuration in Infor OS Portal under Messaging > SMTP Settings. Is the separate external configuration in a different location? I’m using Office 365 as our email provider and the settings test successfully when I click the test button.
For customer portals in ICS 2022, check the Subscription Management module settings specifically. There’s a separate email configuration under Subscription Management > Portal Settings > Email Configuration. This overrides the global SMTP settings for customer-facing communications. If this is blank or misconfigured, customer emails fail while internal emails work because they use the global SMTP settings.
Found it! The Subscription Management email configuration was completely blank. I’ve filled in the SMTP details matching our global configuration. However, I’m now getting a different issue - the test email from that configuration fails with ‘Authentication failed’. Same credentials work in the global SMTP settings. Why would the same credentials fail in the subscription module?
Office 365 has strict sender restrictions for external-facing applications. Your subscription management module is trying to send emails with customer email addresses in the ‘Reply-To’ field, which Office 365 blocks if the authenticated account doesn’t have permission to send on behalf of arbitrary addresses. You need to configure an application-specific password in Office 365 with ‘Send As’ permissions for your domain, or better yet, use a dedicated mailbox like ‘noreply@yourdomain.com’ for customer portal emails.
Confirmed this resolves the issue — switching Subscription Management Portal Email Config to TLS on port 587 stopped the silent Office 365 failures we saw in CloudSuite logs.
I created a dedicated mailbox ‘portal-noreply@ourcompany.com’ with an app-specific password and updated the subscription email configuration to use it. The test email now works! But when customers try password reset, they still don’t receive emails. The CloudSuite email logs show ‘Sent successfully’ for these reset requests. Where are the emails going?