Почтовый ящик переполнен: что проверить до удаления писем

Если новые письма перестали приходить, не начинайте с массового удаления или смены DNS. Попросите отправителя прислать полный отчёт о недоставке (DSN), найдите расширенный код состояния и одновременно проверьте занятую квоту ящика в панели хостинга. Код X.2.2 означает переполнение ящика; X.3.1 — нехватку места в почтовой системе, которую владелец отдельного ящика может не исправить сам. Эти значения определены в RFC 3463. Результат проверки — не исчезнувшее предупреждение, а принятое контрольное письмо без нового отказа и запас свободного места в панели.

Первая цифра расширенного кода показывает класс ответа: 4 — временный отказ; 5 — окончательный отказ. При окончательном отказе одна лишь повторная отправка обычно не помогает: требуется изменение сообщения или устранение причины отказа на стороне получателя. RFC 3463 рекомендует считать переполнение ящика временной ошибкой. В реальном отчёте может встретиться временный код 4.2.2 или окончательный 5.2.2; последний приведён в примере документации cPanel. Сохраняйте фактический код отчёта: пара 2.2 указывает на переполнение ящика, а первая цифра определяет класс отказа. Не путайте это с размером одного письма или отключённой учётной записью.

• адрес получателя и точное время попытки;

• расширенный код вида 4.2.2 или 5.2.2;

• текст ответа сервера получателя;

• идентификатор сообщения, если он указан;

• с какого внешнего ящика выполнялась проверка.

Если отправителю не пришёл отказ, это ещё не доказывает исправность ящика: сообщение могло оставаться в очереди или быть принято и затем отфильтровано. И наоборот, код X.2.2 уже даёт конкретную причину — в этот момент проверка SPF, DKIM или смена MX-записи не освобождает место.

1. Откройте именно тот почтовый ящик, который указан в отказе, и запишите текущий объём и назначенную квоту.

2. Проверьте общий лимит диска или почтового пространства аккаунта: свободное место сайта не всегда равно доступному месту почты.

3. Посмотрите распределение объёма по папкам — входящие, отправленные, черновики, спам и корзина могут учитываться по-разному.

4. Найдите крупные и старые сообщения, но ничего не удаляйте до сохранения нужной переписки и проверки правил хранения.

5. Если заполнен не ящик, а вся почтовая система или показатель в панели неясен, передайте провайдеру адрес, время, код и идентификатор сообщения.

В документации cPanel по управлению ящиком отдельно показаны текущий объём и квота, а раздел Email Disk Usage распределяет использование по папкам. Это пример конкретной панели, а не универсальное название кнопок. Документация также предупреждает, что значения могут обновляться с задержкой из-за кеширования: после очистки не стоит объявлять проблему решённой только потому, что цифра ещё не изменилась или, наоборот, исчезла мгновенно.

• Сначала сохраните сообщения, которые нужны для заказов, финансовых взаиморасчётов, гарантий или внутреннего контроля.

• Начните с известных крупных вложений и ненужных копий, а не с команды «удалить всё».

• Проверьте, освобождает ли удаление место сразу и нужно ли отдельно очищать корзину в вашей системе.

• Не смешивайте очистку ящика с изменением DNS, паролей или маршрута почты: это разные действия и разные риски.

• Если письма должны храниться по внутренней политике компании, согласуйте архивирование до удаления.

Есть нюанс: одинаково названная кнопка может выполнять очень разные действия. В Plesk Obsidian команда Empty mailbox удаляет входящие, исходящие и черновики выбранного ящика. Это не аккуратная очистка крупных вложений, а полное опустошение. Для рабочего адреса магазина такую операцию нельзя использовать вслепую.

1. Дождитесь, пока панель покажет запас свободного места, учитывая возможную задержку пересчёта.

2. Отправьте одно контрольное письмо с внешнего сервиса на проверяемый адрес. Используйте уникальную тему и нейтральное содержание без данных клиентов.

3. Проверьте, что отправитель не получил новый отказ, а письмо появилось в ожидаемом ящике.

4. После получения контрольного письма ещё раз запишите, сколько места уже занимают сообщения в ящике, и время доставки. Речь о фактически использованном объёме, а не о выделенном лимите хранения.

5. Если это адрес для заказов, отдельно выполните разрешённый тест штатного уведомления магазина: ручное письмо не доказывает работу сайта.

Контрольное письмо не обязано проходить тот же маршрут, что уведомление интернет-магазина. Если внешний тест приходит, а письмо о заказе нет, подтверждён только приём этого контрольного сообщения. Между контрольным письмом и уведомлением ящик мог снова заполниться. Кроме того, возможны фильтрация и превышение допустимого размера другого письма. Дальше сопоставьте время, отправителя, размер и ответ получателя для обоих сообщений, затем проверьте маршрут уведомления. Продолжить проверку цепочки поможет материал «Путь письма о заказе от магазина до входящих»: там разделены создание уведомления, передача почтовому сервису и ответ системы получателя.

Проверять MX-запись имеет смысл, когда отказ указывает на домен, маршрут или недоступность почтового сервера, а не после подтверждённого X.2.2. Для отдельной проверки записей откройте сервис проверки DNS-записей, но его результат не показывает занятую квоту ящика.

If new emails stop arriving, do not start by mass-deleting messages or changing DNS settings. Ask the sender to provide a full delivery status notification (DSN), locate the extended status code, and simultaneously check the mailbox quota in the hosting control panel. The code X.2.2 indicates a full mailbox; X.3.1 indicates insufficient space in the mail system, which an individual mailbox owner may not be able to fix alone. These values are defined in RFC 3463. The result of the check is not a vanished warning, but a successfully received control email without a new rejection and available free space in the control panel.

The first digit of the extended code indicates the response class: 4 means a temporary failure; 5 means a permanent failure. With a permanent failure, simply resending usually does not help; the message content must be changed or the cause of the failure must be resolved on the recipient's side. RFC 3463 recommends treating mailbox overflow as a temporary error. A real report may contain a temporary code 4.2.2 or a permanent one 5.2.2; the latter is shown in the cPanel documentation example. Preserve the actual report code: pair 2.2 indicates a mailbox overflow, while the first digit determines the failure class. Do not confuse this with the size of a single message or a disabled account.

• recipient address and the exact time of the attempt;

• extended code of the form 4.2.2 or 5.2.2;

• text of the recipient server's response;

• message identifier, if provided;

• the external mailbox from which the check was performed.

If the sender did not receive a failure notice, this does not prove the mailbox is working: the message might still be in the queue or accepted and then filtered. Conversely, code X.2.2 already provides a specific reason; at this point, checking SPF, DKIM, or changing MX records will not free up space.

1. Open exactly the mailbox specified in the rejection message and record its current volume and assigned quota.

2. Check the account's total disk limit or mailbox space: a website's free space does not always equal available mailbox space.

3. Review the volume distribution across folders—Inbox, Sent, Drafts, Spam, and Trash may be counted differently.

4. Locate large and old messages, but do not delete anything until you have saved the necessary correspondence and verified retention policies.

5. If the entire mail system is full rather than a single mailbox, or if the panel indicator is unclear, provide the provider with the address, time, error code, and message identifier.

In the cPanel documentation for mailbox management, the current volume and quota are displayed separately, and the Email Disk Usage section breaks down usage by folder. This is an example of a specific control panel, not a universal button name. The documentation also warns that values may update with a delay due to caching: after cleaning, do not declare the issue resolved simply because the number has not yet changed or, conversely, has disappeared instantly.

• First, save messages required for orders, financial settlements, warranties, or internal audits.

• Start with known large attachments and unnecessary copies, not with a 'delete everything' command.

• Check whether deletion frees space immediately and whether you need to empty the trash separately in your system.

• Do not mix mailbox cleanup with DNS changes, password updates, or mail routing changes: these are different actions with different risks.

• If emails must be retained per company internal policy, coordinate archiving before deletion.

There is a nuance: a button with the same name can perform very different actions. In Plesk Obsidian, the Empty mailbox command deletes incoming, outgoing, and draft messages for the selected mailbox. This is not a careful cleanup of large attachments but a complete emptying. For a store's working address, this operation must not be used blindly.

1. Wait until the panel shows the available free space, accounting for possible recalculation delays.

2. Send a single test email from an external service to the address being checked. Use a unique subject line and neutral content without customer data.

3. Verify that the sender did not receive a new error and that the email appeared in the expected mailbox.

4. After receiving the control email, record again how much space the messages in the mailbox currently occupy and the delivery time. This refers to the actually used volume, not the allocated storage limit.

5. If this is an address for orders, separately perform the allowed test of the store's standard notification: a manual email does not prove the site is working.

The control email does not have to follow the same route as the online store notification. If an external test arrives but the order email does not, only the receipt of that control message is confirmed. Between the control email and the notification, the mailbox could have filled up again. Additionally, filtering or exceeding the allowed size of another message is possible. Next, compare the time, sender, size, and recipient response for both messages, then verify the notification route. The article «Order Email Path from Store to Inbox» will help continue the chain verification: it separates notification creation, handover to the mail service, and the recipient system's response.

Checking the MX record is relevant when the failure indicates a domain, route, or mail server unavailability, rather than after a confirmed X.2.2. To check records individually, open the DNS record checking service, but its result does not show the mailbox quota usage.