Путь письма о заказе от магазина до входящих

У магазина есть заказ, а у покупателя нет письма с подтверждением. В панели отправки при этом может стоять зелёный статус. Чтобы найти причину, нужно сначала выяснить, что именно этот статус подтверждает: создание сообщения, приём почтовым сервисом или передачу серверу получателя. Последний этап тоже не обещает попадания во входящие.

Начните с одного конкретного случая: время заказа, время предполагаемой отправки, адрес получателя и идентификатор сообщения в доступном журнале. Сопоставлять нужно одну попытку, а не все письма за день. При передаче сведений разработчику или провайдеру используйте разрешённый канал и уберите содержимое заказа, если оно для диагностики не требуется.

Если запись о письме вообще не появилась, проверять почтовую репутацию рано. Возможно, нужное событие магазина не создало уведомление, шаблон не подходит к выбранному сайту или обработка очереди остановилась. В магазине на 1С-Битрикс важно связать событие заказа с предназначенным ему почтовым шаблоном и фактическим механизмом отправки. Дополнительный модуль может использовать собственный маршрут.

Если сообщение создано, но не передано сервису отправки, нужны ошибка соединения, ответ сервиса и состояние очереди. Истёкшие учётные данные, превышение лимита или недоступность сети относятся к разным причинам. Перезапуск всего сайта не объяснит ни одну из них. Он может лишь изменить картину до того, как команда сохранит полезные сведения.

Если сервис отправки принял сообщение, посмотрите результат следующего перехода — к почтовой системе получателя. Временный отказ и окончательное отклонение требуют разной обработки. Сохраните полный код и пояснение ответа: одинаковое бытовое описание «не доставлено» скрывает и занятый сервер, и несуществующий ящик, и отказ из-за правил безопасности.

Принятие письма принимающей системой означает передачу ей ответственности за дальнейшую обработку, но не прочтение человеком. Письмо могло попасть в спам, отдельную категорию, карантин корпоративной почты или под пользовательское правило. Поэтому статус провайдера нужно читать по его документации, а не переводить слово «доставлено» как «покупатель увидел».

SPF проверяет, разрешён ли отправляющий сервер для домена технического отправителя. DKIM позволяет проверить подпись сообщения от определённого домена. DMARC связывает результат аутентификации с доменом в видимом поле отправителя. Именно эта связь часто теряется после подключения нового сервиса рассылок или переноса сайта.

У письма могут различаться домен, который видит человек, технический домен возврата и домен подписи. Поэтому успешная проверка SPF сама по себе ещё не доказывает успешность DMARC для видимого отправителя. Для прохождения DMARC достаточно успешного и согласованного пути через SPF либо через DKIM. Режим согласования определяет, требуется ли точное совпадение доменов или допустима связь на уровне организационного домена.

Условный пример: письмо показывает магазин как отправителя, а SPF подтверждает только технический домен провайдера, не согласованный с доменом магазина. При этом провайдер корректно подписал письмо доменом магазина, и проверка DKIM успешна. Такой путь может пройти DMARC через DKIM. Требовать, чтобы все названия доменов в исходнике были одинаковыми, было бы неверно.

Смотреть следует результаты, добавленные доверенной принимающей системой, а не произвольную строку внутри сообщения. У разных почтовых сервисов представление отличается. В частности, справка Яндекс KIT указывает, что в Яндекс Почте отдельная строка результата DMARC может отсутствовать. Само отсутствие привычной надписи ещё не доказывает провал проверки: нужно разбирать подпись, домены и действующую политику.

Не копируйте готовую DNS-запись из инструкции для другого провайдера. У магазина могут одновременно отправлять письма сайт, CRM и почта сотрудников. Настройка должна учитывать реальные источники. Изменение политики без их инвентаризации способно нарушить уже работающую переписку. Здесь описан порядок диагностики; изменение DNS требует отдельного плана для конкретного домена.

Почтовая система оценивает не только подлинность отправителя. Имеют значение репутация, жалобы, характер отправки и содержимое. Успешные SPF, DKIM и DMARC не являются билетом во входящие. В официальных рекомендациях Gmail прямо нет гарантии прохождения спам-фильтров для писем от внешнего провайдера.

Проверьте, не делит ли подтверждение заказа очередь с большой рекламной отправкой. Даже без полного отказа задержка может сделать письмо бесполезным: покупатель уже обратился в поддержку или повторил заказ. Сервисные уведомления стоит наблюдать отдельно по времени обработки и ошибкам, сохраняя понятную связь с заказом. Это не означает, что смена домена сама по себе исправит репутацию.

Посмотрите и на само письмо. Отправитель должен быть узнаваемым, тема — соответствовать действию, а содержание — объяснять состояние заказа. Обещание «заказ оплачен» нельзя отправлять только на основании создания заказа. Ссылки на личные данные и служебные секреты не должны попадать в общие журналы диагностики. Полный исходник письма часто содержит больше информации, чем нужно для первичного обращения в поддержку.

Низкая доля открытий тоже не доказывает недоставку. Почтовые клиенты ограничивают загрузку изображений, а измерение открытия зависит от используемого механизма. Для расследования конкретной потери полезнее цепочка событий и ответы серверов. Для наблюдения за потоком — доля отказов и задержки по почтовым системам получателей, если такие данные доступны.

Письмо, отправленное сотрудником вручную, может идти через другую инфраструктуру. Оно не проверяет маршрут уведомления из интернет-магазина. Для контрольного сценария нужен разрешённый тестовый заказ или штатная проверка именно того механизма, который обслуживает покупателей. Не рассылайте пробные сообщения по клиентской базе.

После исправления отправляют новое сообщение на подконтрольные тестовые ящики и сопоставляют все доступные этапы. Старое письмо не приобретёт новую подпись и не будет заново проверено только потому, что запись DNS уже исправлена. Результат одного ящика полезен, но не подтверждает доставку во все почтовые системы.

На стороне магазина потеря уведомления не должна скрывать сам заказ. Покупателю нужен понятный результат оформления и доступный способ уточнить состояние, а сотруднику — запись заказа независимо от доставки почты. Тогда расследование заканчивается конкретным выводом: например, сообщение создано, принято отправляющим сервисом и отклонено принимающей системой по установленной причине. Такой вывод позволяет исправить один участок вместо бесконечной смены шаблонов письма.

The store has an order, but the buyer has not received a confirmation email. Yet the sending panel may show a green status. To find the cause, you must first determine exactly what this status confirms: message creation, acceptance by a mail service, or transfer to the recipient server. The final stage also does not guarantee delivery to the inbox.

Start with one specific case: order time, expected send time, recipient address, and message ID in the available log. You must match a single attempt, not all emails sent that day. When sharing details with a developer or provider, use an authorized channel and remove order content if it is not required for diagnostics.

If a record for the email never appeared, checking the email reputation is premature. Perhaps the store event did not generate a notification, the template does not match the selected site, or queue processing has stopped. In a 1C-Bitrix store, it is critical to link the order event to its intended email template and the actual sending mechanism. An additional module may use its own routing path.

If the message was created but not passed to the sending service, you need the connection error, the service response, and the queue status. Expired credentials, exceeding limits, or network unavailability are distinct causes. Restarting the entire site does not explain any of them. It may only alter the situation before the team saves useful data.

If the sending service accepted the message, check the result of the next transition to the recipient's mail system. Temporary failures and permanent rejections require different handling. Save the full error code and explanation: the same everyday description 'not delivered' can hide a busy server, a non-existent mailbox, or a rejection due to security policies.

Acceptance of a message by the receiving system means transferring responsibility for further processing to it, but not human reading. The message could have ended up in spam, a separate category, corporate mail quarantine, or under a user rule. Therefore, the provider's status must be interpreted according to their documentation, not by translating the word 'delivered' as 'the buyer saw it'.

SPF checks whether the sending server is authorized for the technical sender's domain. DKIM allows verification of the message signature from a specific domain. DMARC links the authentication result to the domain in the visible sender field. It is this link that is often lost after connecting a new mailing service or migrating a website.

A message may have different domains: the one visible to the human, the technical return domain, and the signature domain. Therefore, a successful SPF check alone does not prove a successful DMARC check for the visible sender. To pass DMARC, a successful and aligned path through either SPF or DKIM is sufficient. The alignment mode determines whether an exact domain match is required or if alignment at the organizational domain level is permitted.

Hypothetical example: the email shows the store as the sender, and SPF confirms only the provider's technical domain, which does not match the store's domain. Meanwhile, the provider correctly signed the email with the store's domain, and the DKIM check is successful. Such a path can pass DMARC via DKIM. Requiring all domain names in the envelope to be identical would be incorrect.

Focus on the results added by the trusted receiving system, not an arbitrary string within the message. Different email services present this information differently. In particular, the Yandex KIT documentation notes that the separate DMARC result line may be absent in Yandex Mail. The mere absence of the familiar label does not prove a failed check: you must analyze the signature, domains, and the active policy.

Do not copy a ready-made DNS record from instructions intended for another provider. A store may simultaneously send emails from its website, CRM, and employee mailboxes. The configuration must account for these actual sources. Changing the policy without inventorying them can disrupt existing correspondence. This section describes the diagnostic procedure; modifying DNS requires a separate plan tailored to the specific domain.

Mail systems evaluate not only sender authenticity. Reputation, complaints, sending patterns, and content matter. Successful SPF, DKIM, and DMARC are not a guaranteed pass to the inbox. Official Gmail guidelines do not explicitly guarantee that emails from external providers will bypass spam filters.

Check whether order confirmation shares a queue with a large promotional blast. Even without a complete failure, delays can render the message useless: the buyer may have already contacted support or placed a duplicate order. Service notifications should be monitored separately by processing time and errors, while maintaining a clear link to the order. This does not mean that changing the domain alone will fix the reputation.

Also examine the email itself. The sender must be recognizable, the subject line must match the action, and the content must explain the order status. The promise "order paid" cannot be sent based solely on order creation. Links to personal data and internal secrets must not appear in general diagnostic logs. The full email source often contains more information than is needed for an initial support inquiry.

A low open rate also does not prove non-delivery. Email clients restrict image loading, and open measurement depends on the mechanism used. To investigate a specific loss, an event chain and server responses are more useful. To monitor the flow, use the failure rate and latency by recipient mail systems, if such data is available.

An email sent manually by an employee may travel through a different infrastructure. It does not verify the notification route from the online store. For a control scenario, you need an authorized test order or a standard check of the exact mechanism serving customers. Do not send test messages to the customer base.

After the fix, send a new message to the controlled test mailboxes and compare all available stages. An old email will not acquire a new signature, nor will it be re-verified just because the DNS record has been corrected. The result from one mailbox is useful, but it does not confirm delivery to all mail systems.

On the store side, a lost notification must not hide the order itself. The customer needs a clear checkout result and an accessible way to check the status, while the employee needs an order record regardless of email delivery. This allows the investigation to end with a specific conclusion: for example, the message was created, accepted by the sending service, and rejected by the receiving system for a defined reason. Such a conclusion enables fixing a single component instead of endlessly changing email templates.