Why 1C-Bitrix email templates break delivery
An email from 1C-Bitrix is rarely lost "just because." In nine out of ten cases, the problem is reproducible on a staging environment: the email template is built from table-based layout with inline styles, and email clients strip out part of the markup — in Gmail the email arrives without the button, in Outlook the grid falls apart.
Another common scenario is that mail events are tied to a template left over from an old version of the site: the event fires, but substitutes empty fields instead of the customer's name and order number.
Email deliverability also breaks at the configuration level. If the mail module settings specify a sender address on a domain different from the site's domain, SPF and DKIM fail validation — emails go to spam or bounce on the recipient's side.
A separate category is email template types: transactional (order confirmation, password reset) and bulk mailings require different infrastructure, yet they are often run through one shared mailbox.
Then, when a mailing spikes, transactional emails get queued and arrive hours later, when the customer has already left.
The third layer is encoding and headers. A subject line with Cyrillic characters without a correct MIME header turns into a jumble of symbols, and embedded images load as broken links because the template references local paths instead of absolute ones.
All of this looks like "emails aren't getting through," even though technically they were sent.
Here's how this gets resolved: an audit of mail events, rebuilding templates to meet client requirements, and configuring the sender domain so that emails consistently land in the "Inbox."
What proper email template setup delivers
Order in templates is not cosmetic — it is controllable deliverability. When an email is assembled from a single source and passes validation before sending, it lands in spam less often and breaks in email clients less often. Let's break down exactly what putting things in order delivers.
- Deliverability. A single source of emails and correct headers reduce the share of spam hits — order and password recovery emails reach the recipient instead of getting stuck in "Promotions".
- Consistent email style. The logo, colors, and signature come from a shared template, so the customer sees a recognizable brand in every notification rather than a set of disjointed layouts.
- Correct markup. Table-based layout and inline styles render the same in email clients and on mobile — the markup doesn't "fall apart" on half the devices.
- Less manual work. A new notification type is assembled from ready-made blocks in minutes instead of being rewritten from scratch every time.
- Predictable campaigns. Templates are versioned and validated before sending, so a mass campaign doesn't go out with a broken link or an empty placeholder.
- Transparent maintenance. Edits are made in one place and immediately apply to all emails, instead of being hunted down across dozens of files.
Each point addresses a specific class of failures: undelivered emails, broken markup, lost orders due to an unreadable notification. Next we show how to establish this order on your project.
Ways to build emails: comparison of approaches
An email in 1C-Bitrix is assembled from a mail template — a binding to an event type — and the markup that is substituted into it.
Then the question is how much of that markup you write yourself: you can rely on the module's standard templates, you can take a ready-made component template and override it, or you can build custom markup from scratch for a specific email client.
The choice affects how the email survives Outlook, Gmail, and corporate filters, and how much time editing will take when the layout changes.
| Option | When it fits | Limitations |
|---|---|---|
| Standard module templates | Transactional notifications: registration, password reset, order confirmation | A single framework for all events, weak control over appearance, edits via overriding |
| Ready-made component template with modifications | A typical store or portal where speed of launch matters | Inherits someone else's table structure, hard to embed brand style without breaking it |
| Custom markup for email clients | Newsletters, welcome series, branded emails | Requires table layout, inline styles, and testing in real clients |
Standard templates win where the email serves a function rather than an image: they are already linked to event types, substitute fields via #PLACEHOLDER#, and don't break when the module is updated.
Their weak spot is a common appearance for all notifications and limited manageability: to change a block, you have to override the template rather than edit it in the interface.
Custom markup gives full control over structure and typography, but requires discipline: table layout instead of flexible blocks, styles in attributes, separate checks in web versions and mobile clients.
The compromise is a hybrid: the framework and substitution logic remain standard, while the visual part is moved into a custom template with a test run across major clients. This approach most often gets the job done without rewriting the entire email logic.
How we implement email templates: stages of work
Work begins with an inventory: we export the list of email events from the system, match each one to a real business scenario — registration, access recovery, order confirmation, status change, manager notification.
At this step it becomes clear which events are duplicated, which send emails without a template, and which are not configured at all — these are the ones that most often lose a customer.
- Template audit. We review the current emails: where "raw" variables are inserted, where the layout breaks in email clients, where the subject line ends up in spam. We record the list of events and defects in a table.
- Structure approval. For each event we define the set of blocks, their order, the set of placeholder fields, and the branching logic — for example, the customer email and the manager copy are built from the same template with different fields.
- Email event setup. We link templates to events, define recipient types, subjects, and sender, and verify that data from cards and orders is inserted correctly.
- Layout and adaptation. We build the emails so they read equally well in desktop and mobile clients, with a proper fallback for images and a clear text hierarchy.
- Email testing. We run each event on test data: we check delivery, rendering, link behavior, and variable insertion across different scenarios.
- Template handover. We deliver the finished solutions with documentation: which event, which fields, what to change when editing, and where the source files are located.
- Support. After launch we monitor deliverability and, if needed, refine the templates for new scenarios.
This order closes the main risk — emails that go out to the customer with empty fields or fail to arrive. Describe your email events — we will come back with an estimate and a work plan.
What the client receives as a result
We hand over not a "set of files" but a working email notification loop: templates tied to email events, plus documentation your team can use to maintain them independently going forward.
- Ready-made email templates for key scenarios: registration and account confirmation, access recovery, order placement and status change, invoice and payment, feedback form replies, notifications to managers.
- Binding templates to email events: event type, recipient, subject, set of substituted fields — so the email goes out on a trigger rather than manually.
- Responsive layout for email clients: table-based layout, inline styles, readable typography on narrow screens.
- Copy and variables: agreed-upon wording, substitution of order and user data, consistent tone across all emails.
- Documentation on template structure: which fields come from where, where the email subject is edited, how to add a new email event without breaking existing ones.
- Instructions for the content manager: how to change text, logo, contacts, and links without a developer.
- Configured delivery checks: test sends to real inboxes, monitoring for landing in "Inbox", correct encoding and email subject.
- A list of common errors and how to fix them: empty variables, garbled characters, emails in spam, duplicate notifications.
We hand all of this over in the project repository and record it in the documentation — new emails are added using a ready-made template, without rebuilding the notification logic from scratch.
Case study: how we sped up notification delivery
The client is an online store on 1C-Bitrix with a catalog of several tens of thousands of items.
Order, status change, and abandoned cart notifications were generated on the fly: the template assembled data from dozens of separate database queries right at the moment of sending, and some emails were sent synchronously in the checkout flow.
The peak load came during sales: the notification queue grew faster than the agent could process it. The order confirmation email reached the customer with a delay, and during spikes in activity some sends were postponed indefinitely. Hence the support calls "I paid but there's no confirmation" and repeat orders.
What we changed
We separated email generation from sending: the template now receives an already assembled data set in a single query instead of pulling related entities one by one.
Heavy blocks — the product list, recommendations, discount calculation — were moved out of the template body into pre-prepared structures. Sending was moved to an asynchronous queue with retries, and the synchronous call from the checkout flow was removed.
We also addressed deliverability separately: we configured correct sender headers, aligned the text and HTML versions, and removed bulk mailing signals from transactional emails. This reduced the share of spam placements — order emails started reaching the main inbox again.
Results in numbers
| Metric | Before | After |
|---|---|---|
| Email generation time | seconds per email | fractions of a second |
| Delivery delay at peak | minutes and more | consistently within a minute |
| Share of postponed sends | noticeable | isolated cases |
| Spam placement | regular | isolated complaints |
The queue stopped growing during sales, and support stopped handling complaints about "missing" confirmations. At the same time, the templates remained editable through the visual editor — a marketer can change text and blocks without involving a developer.
How do 1C-Bitrix email templates differ from standard solutions?
A standard solution is an HTML email that a manager assembles manually or inserts into a newsletter via a third-party service. It knows nothing about the customer's data: not the order status, not the warehouse stock levels, not the segment the recipient belongs to.
1C-Bitrix email templates work differently — they are part of the system, not a separate file, so each email is assembled on the fly from current data.
The key difference is the binding to platform events. Registration, password recovery, placing and paying for an order, status change, abandoned cart, subscription expiration — each event has its own email template with its own set of fields.
The system automatically inserts the name, order number, cart contents, total, link to the personal account, and manager's details. The manager doesn't assemble the email by hand or move data between windows — they only oversee the logic.
The second difference is a unified visual standard. The layout is moved into a common framework: a header with the logo, a contacts block, a footer with company details and an unsubscribe link. Change the phone number in one place — it updates across all emails at once.
This eliminates the classic problem where the order email shows one number, the newsletter shows another, and the footer shows a third, outdated one.
The third is manageability and predictable delivery. Templates are stored in the system, not in a specific employee's mailbox, so they aren't lost when the team changes.
Headers, the return address, encoding, and plain-text versions of emails are configured — this reduces the share of messages landing in spam. Plus, emails display correctly in email clients and on mobile devices, rather than falling apart at the first line wrap.
And the fourth is scalability. When emails number in the dozens and there are several segments, manual assembly becomes a bottleneck. Templates in 1C-Bitrix let you add new events and language versions without rewriting everything from scratch. That is why email templates are not cosmetics but the infrastructure of customer communication.
Common technical concerns
Emails in 1C-Bitrix are assembled from a template and a mail event: the template defines the markup and field substitution, while the event determines the moment the email is sent. This is where typical concerns come from — let's go through each one.
Compatibility: will your templates break our current emails and modules?
A template is an isolated entity tied to a specific mail event. We don't rewrite existing templates; instead, we add new ones and switch the binding — the old ones remain in the system as a fallback.
If you have custom modules that generate emails themselves, we check the list of events and add templates for them. Rollback is a reverse switch of the binding, with no code changes.
Support: how hard is it to change templates ourselves later?
The markup is built on standard components and clear blocks, without custom constructs that only the author understands. Content and variables are separated so that a marketer can change text or an image through the admin panel without touching the code.
We hand over a short guide: where the template is located, which fields are substituted, and what can be safely edited.
Does this affect site speed?
Emails are generated at the moment of sending, not when the page loads, so they don't affect the storefront speed. We optimize heavy elements — images, layout: compressed images, clean tabular structure, no unnecessary attachments.
If there are many emails, we spread the sending out in a queue so that a peak newsletter doesn't slow down other processes.
What if a mail client renders the email differently?
We check the layout in popular clients and web interfaces, including mobile. For clients with limited style support, we prepare a fallback markup option so the email is readable even without images and external styles.
Still have questions about your case — describe the task, and we'll come back with an estimate and a plan.
Let's discuss your email template task
To offer a solution rather than a boilerplate template, we need to understand your current situation: which edition the portal runs on, how email sending is set up now, which events trigger the emails, and what exactly is unsatisfactory about the current emails.
Describe this in free form — then we will ask relevant clarifying questions and come back with an estimate and a work plan.
What is worth specifying in the request so the conversation is immediately substantive:
- the platform edition and core version — the available template mechanism and mail events depend on it;
- which emails are already being sent: registration, access recovery, order confirmation, statuses, manager notifications;
- where the templates currently reside — in module settings, in components, or sent manually;
- how sending is configured: via a local mail server, an external service, or a queue, and where delivery errors end up;
- what is not working: emails land in spam, layout breaks in email clients, order data is lost, there is no multilingual support;
- which integrations are affected — 1C, CRM, warehouse, payment systems;
- whether there are branding and corporate style requirements.
Based on the analysis, we will show which templates need to be rewritten, which events to add, how to extract common blocks into reusable components, and how to set up sending logging.
We will break the work plan into stages with clear timelines so you can see what is done and in what sequence.
If the task has not been formulated yet — that is fine too: tell us how the process works now, and we will propose solution options. We will discuss the task and come back with a plan.