Every day we send our users dozens of different emails. Mostly they are digests, notifications on new comments and personal messages.
It's important to understand, that delivering of those emails depends not only on our mailing system but also on:
correctness of user actions;
the correct operation of their email boxes;
the correct operation of their email clients.
Usually the user may not receive an email in two cases:
an email wasn't sent to user's mailbox;
user's mailbox (or email client) is full, or operates incorrect.
Let's see, why those situations appear and how to resolve them.
There are several reasons, why the email can't be sent to users mailbox:
1.1. The user made a typo, and all emails are sent to the wrong email address. There are two ways to solve this problem:
authorized user can check and edit email address himself in account settings;
unauthorized user can contact the support to edit the email address (confirmation of account ownership required).
1.2. Notification sending is not provided, is not activated in the settings, or the condition necessary to send a notification has not come. Such problems can be identified by checking the settings and observing the conditions for sending notifications, for example:
if the user doesn't receive any email notifications it may be caused by user himself; notifications may be disabled on global settings page, or, user, while being on a post page, could accidentaly press the hotkey «m» or may have disabled notifications locally, for this particular post;
if the user doesn't receive personal digest, one should check digest sending settings, probably there were no interesting posts for the selected period.
1.3. Email notification is in the queue. It can happen is two cases:
if there is a wide scale mailing happening. It concerns only mailings, because important letters (such as email confirmation) are sent via the dedicated mailing queues;
if we've tried to send the notification, but the recipient's server didn't accept it and «asked» us to send it later. This is possible, when «greylisting» mechanism is overloaded with requests, or can't receive an email for some other reason. In this case, we put an email to the queue and try to send it later.
We're controlling the email delivery process using standart mechanisms (bounce messages / NDR / DSN / NDN). But it's important to understand, that we can't affect the process if the trouble is on a user's side.
In some cases, recipient's server can report an error, like:
mailbox doesn't exist on server (invalid user / unknown user);
email delivery to the particular mailbox is prohibited / user blocked (account disabled);
user exceeded the data quota / mailbox is full (user quota exceeded);
mail server declined an email because of spam suspicion (suspect of spam);
route to the mailbox is unreachable (unknown route);
other similar SMTP errors with 5xx codes.
It often happens that recipient's server works incorrect and reports incorrect error code. For example it can report that mailbox is full, while that is not true.
2.1. If the user's server reported an error, our system suspends sending notifications, to that email address. This is necessary, because otherwise, mailing servers will consider us as spamers, who ignore server warnings.
If our system received an error report and suspended notifications, user will see a system warning at the top of the website: «We can't deliver emails to your email address. To solve this problem, please, follow the link». To solve the problem, user must follow the link from the warning and follow further instructions.
If you've checked and fixed everything from the instruction above, but still don't receive email notifications, you should try some different ways to solve the problem:
check the spelling of your email address and fix it, ig there is a typo in it;
contact the support. Our specialists will check notifications sending history for your e-mail address, and will provide you with an error code and MessageID. With that information, owner of the mailbox can contact the administrator or a specialist of the mail server to clear the situation;
change the email address, using one from a different mail server, which works correctly.
You shouldn't contact our support and ask to disable the mail delivery check, because our system is not available to do that.
2.2. If the recipient's server hasn't received an email and «asked» us to send it later, then we put an email to the queue and try to send it later. This is possible, when «greylisting» mechanism is overloaded with requests, or can't receive an email for some other reason.
2.3. Recipient's server reported, that message is delivered successfully, but the user hadn't found it in «Inbox». That can be caused by:
user's mail server has a delivery time delay;
forwarding or any other personal inbox filter is activated. For example, «Google Mail» service can move our notifications to «Social» folder. It this cases it's recommended to check filters settings. In different mail services there are different settings for filters, more then that, there may be group filters active in corporate mailing systems, which filter the incoming mails before they get to the recipient's mailbox;
recipient's spam-filter moved our email to the quaranteen folder.
Most mailing services guard their users from spam and filter their incoming mail traffic. They use many different algorithms to detect spam. Unfortunately, they don't give 100% guarantees that mail server will correctly detect spam.
We obviously do not know what criteria a particular spam filter operates on. As a rule, such information constitutes a commercial secret of its developers. Therefore, having received from the user information that our notification has been affected by someone else's spam filter, we can only speculate as to what settings of this filter led to its untimely triggering..
In most cases, the problems of incorrectly classifying service notifications as spam are due to the fact that mail services use outdated methods of detecting unwanted messages. Such techniques give a high percentage of incorrect notification processing results.
Filters based on user behavior are another problem. Each transfer of a service notification to a spam folder increases the likelihood that new notifications from the same sender, including those received at the addresses of other users, will be automatically placed in the spam folder.
Such «behavioral» spam detection algorithms may not take into account common situations when:
by registering on our website, the user made a typo in the email and a letter to confirm it came to another user;
the user has registered on our resource by mistake and does not know how to unsubscribe from receiving new notifications;
the mailing address has changed its owner and the new owner perceives notifications from our resources as unwanted;
a user (usually blocked for violating the rules of the resource) deliberately places notifications from our resources into spam folders in order to mislead the spam filter;
a user accidentally moved a letter to a spam folder.
At first glance it may seem that such situations are quite rare. But in our case we are talking about the regular distribution of notifications to tens of thousands of different recipients, carried out over many years. Therefore, in situations when a user detects notifications from our service in a spam folder, we always recommend transferring notifications from our services to regular folders and adding our addresses to the address book, to known senders, in order to improve spam learning statistics filter.
Users of our resources often use Google’s corporate solutions (G.Suits/Google Apps) to organize mail on the corporate domain. At the same time, they, as a rule, create so-called group addresses (info@, sales@, hr@, etc.), which forward incoming mail to several recipient addresses at once. In G.Suits, the traditional method of group mail aliases is replaced by the so-called Google Groups, which by their nature are more similar to group mailing lists.
It should be understood that G.Suits is a standalone product with its own mechanisms, including for spam filtering. An email that arrives at the group's address and is filtered as spam does not appear in the spam folder of the final recipient, but waits for a reaction in the group management interface in the Moderation section. Employees of companies authorized to administer corporate G.Suits, as a rule, forget to check this section in a timely manner. Therefore, we recommend that our users proactively disable the pre-moderation mechanism for their group addresses in the Google Groups settings interface.
If we receive a complaint about a problem with receiving notifications, and during the check it is detected that the user's mailbox is in the corporate domain, and its server informs us that all notifications sent to it were successfully received, then first of all, we recommend the user to contact the administrator of the corporate mail server.
As already mentioned, letters that are dubious from the point of view of spam filters are deleted or placed in a special quarantine folder. The name and location of this folder varies from service to service. Typical names: Spam, Junk;.
Email clients may not download the contents of such folders to the user's device, or even automatically delete their contents. Thus, you can reliably verify that there is no notification in the quarantine folder only by checking it directly through the web interface..
In the Google Mail interface, the Spam folder is hidden behind an additional spoiler, which makes it difficult to check and, as a result, leads to the appearance of dialogs in the like:
— I do not receive a notification to confirm registration! Sent several times. Mail is correct. There is nothing in spam.
— If you didn’t find notifications in your inbox, please check your spam folder via the link
— Thank you! All letters were there.
Our support specialists are always ready to help users identify problems with the delivery of notifications from our resources. In order to speed up the solution of the problem, in your message to the support service we recommend to specify:
your username on our resources;
email address, you expected to receive mail on;
type of expected notification (e.g. email confirmation);
approximate date and time range.
This data will help our specialists to find the notification in the mailing history and trace its path up to the transfer to the server serving the recipient's mailbox. If necessary, our support service specialists will provide the user with the data (MessageID) necessary to clarify the further fate of the notification from the mail service support service.