"Forgot Password" Messages are not Delivered to Gmail or Gsuite Email Addresses =============================================================================== .. contents:: How the Issue Manifests ----------------------- After clicking the Forgot Password link on the login page for NodeWorx or SiteWorx, if the address submitted to the form is a Gmail or GSuite-related email address, the automated password reset message is not delivered to the user's inbox. Cause of the Issue ------------------ The most common cause of this issue is that the Default Sender in NodeWorx is an email address that does not have a valid SPF or DKIM record that matches the server. Password reset messages, like all automated notifications from InterWorx, are sent as the Default Sender. This setting can be found in NodeWorx, under **Server > Settings**. It is located in the **Mail Options** section: .. image:: /images/nw-default-sender.png :alt: default sender setting While this setting can be modified, the default is the email address of the master NodeWorx user. Gmail is notoriously strict when it comes to spam prevention. As such, messages sent to Gmail or Gsuite-related email addresses will be rejected if there is not a valid SPF or DKIM record matching the sender address to the sending server. If the Default Sender is set as an email address for a mail service outside of the server (gmail, outlook, etc), or domain that does not have an SPF or DKIM record matching the server, Gmail will automatically reject the password reset message. Troubleshooting Steps --------------------- Check ~iworx/var/log/iworx.log for Relay Errors ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For security reasons, password reset messages are sent directly from the server, instead of being directed through the mail service. This means that there will not be any logging related to the message in ``/var/log/send/current``. However, if the receiving server rejects the lost password message, this will often be logged in ``~iworx/var/log/iworx.log``. #. Log in to the server at the CLI as root, either via SSH or from the terminal #. Run the following to tail ``~iworx/var/log/iworx.log``. This will show all activity happening related to InterWorx, in real time: .. code-block:: tail -f ~iworx/var/log/iworx.log #. If the password should be reset for a NodeWorx user, navigate to the NodeWorx login page, in the browser. If the password should be reset for a SiteWorx user, navigate to the SiteWorx login page, in the browser #. Click **Forgot your password?** .. image:: /images/nw-forgot-password.png :alt: forgot password link #. Fill in the required information #. Click **Reset Password** #. Check the logging output. Logging similar to the following indicates that Gmail has rejected the message: .. code-block:: 2025-11-04 11:11:22.62698 [nosess-79on-n1wz-WEB] [INFO] : 96.236.155.146 routing: Ctrl_Nodeworx_Lostpass -> index : /nodeworx/lostpass 2025-11-04 11:11:27.14436 [nosess-sfiw-v8iq-WEB] [INFO] : 96.236.155.146 routing: Ctrl_Nodeworx_Lostpass -> send : /nodeworx/lostpass 2025-11-04 11:11:29.67500 [nosess-sfiw-v8iq-WEB] [ERR] : Password reset relay failed for alt4.aspmx.l.google.com: Could not read from alt4.aspmx.l.google.com : /nodeworx/lostpass 2025-11-04 11:11:31.50115 [nosess-sfiw-v8iq-WEB] [ERR] : Password reset relay failed for alt2.aspmx.l.google.com: Could not read from alt2.aspmx.l.google.com : /nodeworx/lostpass 2025-11-04 11:11:32.29762 [nosess-sfiw-v8iq-WEB] [ERR] : Password reset relay failed for aspmx.l.google.com: Could not read from aspmx.l.google.com : /nodeworx/lostpass 2025-11-04 11:11:32.97734 [nosess-sfiw-v8iq-WEB] [ERR] : Password reset relay failed for alt1.aspmx.l.google.com: Could not read from alt1.aspmx.l.google.com : /nodeworx/lostpass 2025-11-04 11:11:33.77711 [nosess-sfiw-v8iq-WEB] [ERR] : Password reset relay failed for alt3.aspmx.l.google.com: Could not read from alt3.aspmx.l.google.com : /nodeworx/lostpass Send a Test Message as the Default Sender ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ As stated, above, for security reasons, password reset messages are sent directly from the server, instead of being directed through the mail service. This means that there will not be any logging related to the message in ``/var/log/send/current``. However, the Mail Queue page in NodeWorx has an option to send a test message from the server. These test messages are also sent using the Default Sender. Sending a test message from the Mail Queue page will log to ``/var/log/send/current``. Checking that log while sending a test message will indicate if Gmail is rejecting messages from the Default Sender. #. Log in to the server at the CLI as root, either via SSH or from the terminal #. Run the following to tail ``/var/log/send/current``. This will show mail being sent from, and received by, the server, in real time: .. code-block:: tail -f /var/log/send/current #. Send a test message from the Mail Queue page in NodeWorx. Information on how to send a test message can be found `here `__ #. Check the logging output. Logging for a successfully received message will look similar to the following: .. code-block:: @4000000069016fc90f6258cc new msg 9571069 @4000000069016fc90f6283c4 info msg 9571069: bytes 438 from qp 19248 uid 250 @4000000069016fc90faabff4 starting delivery 5125: msg 9571069 to remote exampleuser@gmail.com @4000000069016fc90faac7c4 status: local 0/10 remote 1/255 @4000000069016fca0b52951c delivery 5125: success: 142.250.31.26_accepted_message./Remote_host_said:_250_2.0.0_OK__1761701824_6a1803df08f44-87fc6b4c526si34975876d6.826_-_gsmtp/_ @4000000069016fca0b53027c status: local 0/10 remote 0/255 @4000000069016fca0b5340fc end msg 9571069 If Gmail rejected the message, the logging will look similar to the following: .. code-block:: @4000000069016eec0b565224 new msg 9571069 @4000000069016eec0b568104 info msg 9571069: bytes 436 from qp 16483 uid 250 @4000000069016eec0bb012b4 starting delivery 5117: msg 9571069 to remote exampleuser@gmail.com @4000000069016eec0bb01a84 status: local 0/10 remote 1/255 @4000000069016eec26b2a39c delivery 5117: failure: 142.250.31.27_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.26_ Your_email_has_been_blocked_because_the_sender_is_unauthenticated./550-5.7.26_ Gmail_requires_all_senders_to_authenticate_with_either_SPF_or_DKIM./550-5.7.26_/550-5.7.26__ Authentication_results:/550-5.7.26__DKIM_=_did_not_pass/550-5.7.26__SPF_[gmail.com]_with_ip:_ [12.34.56.7]_=_did_not_pass/550-5.7.26_/550-5.7.26__For_instructions_on_setting_up_authentication, _go_to/550_5.7.26__https://support.google.com/mail/answer/81126#authentication_af79cd13be357-89f48530e32si341746285a.2053_-_gsmtp/_ @4000000069016eec26b3b124 status: local 0/10 remote 0/255 @4000000069016eec270a3594 bounce msg 9571069 qp 16491 @4000000069016eec270a7be4 end msg 9571069 @4000000069016eec270b990c new msg 9571170 @4000000069016eec270bac94 info msg 9571170: bytes 1504 from <> qp 16491 uid 107 @4000000069016eec2756d2dc starting delivery 5118: msg 9571170 to remote defaultsender@gmail.com @4000000069016eec2756daac status: local 0/10 remote 1/255 @4000000069016eec277bb82c delivery 5118: success: Dropping_remote_bounce_message_to_prevent_backscatter. @4000000069016eec277c258c status: local 0/10 remote 0/255 @4000000069016eec277c546c end msg 9571170 How to Resolve -------------- There are two ways to solve this issue: - Use an external mail relay for password reset messages. More information can be found :doc:`here ` - Change the Default Sender address to an :doc:`email address for a domain on the server `. The domain must have valid :doc:`SPF ` and :doc:`DKIM ` records To Change the Default Sender address ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #. Log into NodeWorx from the browser (https://ip.ad.dr.ess:2443/nodeworx) #. Navigate to **Server > Settings** #. Under **Mail Options**, update the **Default Sender** field .. image:: /images/nw-default-sender.png :alt: default sender setting #. At the bottom of the page, click **Save** Things to Keep in Mind ---------------------- While this documentation describes the most common reason for password reset messages to not reach the designated inbox, it is not the only reason such a thing could occur. If the above steps do not resolve the issue, please submit a ticket to `https://support.interworx.com `__.