As @sebmaldo stated in his answer - all time-dependent actions with a date in the past start executing right away. To avoid this, you have to include date validation in your criteria, and this will mean that you have to split your single workflow rule into 3 - one for each time-dependent action.
Next, your current validation formula isn't perfect, can be rewritten to: ISBLANK(User) && Expiry_Alert__c
- What
record created date
is from user requirements? Why do you not reference it in your WR validation?
- Is
Expiry_Alert__c
a flag or a formula?
The best formula would be ISBLANK(User) && ((Expiration_Date__c - TODAY()) >= 15)
for 15 days alert and also create 2 more WR for 30 and 60 days.
Putting the answer from the link in the comment for easier viewing which save clicking steps. Also this is very common problem.
I would run an Email Deliverability Test
Testing Deliverability
Available in: All Editions except Database.com
User Permissions Needed
To test email deliverability:
“Modify All Data”
Salesforce sends email from 54 different IP addresses. If your organization blocks any of these IP addresses, users might not receive all email sent from Salesforce.
To verify your organization can receive email from every Salesforce IP address:
Click Your Name | Setup | Administration Setup | Email Administration | Test Deliverability.
Enter your business email address.
Click Send. Salesforce simultaneously sends a test message from all 54 IP addresses to your business email address. Each test message specifies the IP address from which it was sent.
Check your business email account to make sure it received all 54 test messages. (as of 6 Apr 2021, SFDC only sends 16 test messages)
If you received less than 54 test messages, your organization's email administrator must whitelist the Salesforce IP ranges on your organization's email server.
Whitelisting an IP address allows the email server to receive email from an IP address that might otherwise be blocked. The Salesforce IP ranges are:
96.43.144.64 to 96.43.144.65
96.43.148.64 to 96.43.148.65
182.50.78.64 to 182.50.78.79
202.129.242.64 to 202.129.242.65
204.14.232.64 to 204.14.232.79
204.14.234.64 to 204.14.234.79
Note:
If your organization activates email relaying, your email administrator only needs to whitelist the IP addresses Salesforce uses for email relaying (96.43.144.65, 96.43.148.65, 182.50.78.65, 202.129.242.65, 204.14.232.65, and 204.14.234.65).
For information on email relaying, see Setting Up Email Relaying.
Best Answer
After wasting 2 days on this issue, I submitted a case with Salesforce Support and debugged it with the Support, affected user and myself.
What we noticed was NO emails was being sent for when we used the test user not coming to both our company or personal email inboxes.
It was found that the user that is triggering the Email Alert has the email suffixed with the '.invalid' which won't trigger any email and won't appear in the Email logs.
So when testing Email alerts on sandbox, REMEMBER to use a test user with a valid email format (without the .invalid that is automatically added when refreshing sandboxes)