Reasons for Undelivered Emails Despite Correct SMTP

We often encounter a situation where emails get lost even with a proper SMTP configuration. The main causes are missing SPF/DKIM records, unexecuted agent queue, or exceeding mail server limits. For example, if the SMTP settings specify port 25 without encryption, many modern providers block the connection. We recommend port 587 with STARTTLS or 465 with SSL — this is the security standard. In one of our projects with a catalog of 50,000 products, emails were delayed by up to an hour; after moving agents to cron and configuring SMTP, delivery time dropped to 10 seconds. This saves up to 8 hours of administrative work per week. Using cron agents improves delivery speed by 10x compared to page-hit agents. Moreover, over 95% of mail issues stem from missing SPF/DKIM records, as confirmed by our audits.

Mail Notification Architecture in Bitrix

The Bitrix mail system consists of three layers: mail events, templates, and sending service.

Mail Events

The event type (e.g., SALE_NEW_ORDER) defines a set of macros and parameters. Configuration is done in the admin panel: Settings → Mail → Mail Events. Bitrix mail events are the foundation of all notifications.

Mail Event Templates

The specific email for an event: recipient, subject, body. One event type can have multiple templates for different sites or conditions. Configuration: Settings → Mail → Mail Templates.

Mail Sending Service

The choice of delivery method: sendmail, mail(), SMTP, or external services (Mailgun, SendGrid). For high-load projects, we use SMTP with authentication. SMTP is 10 times more reliable than sendmail for volumes over 1000 emails per day. Configuration: Settings → Product Settings → Mail.

Standard Events and Their Configuration

Bitrix comes with predefined events. For an online store, the key ones are:

• SALE_NEW_ORDER — new order
• SALE_ORDER_PAID — order paid
• SALE_ORDER_CANCELED — order canceled
• SALE_STATUS_CHANGED — status change
• MAIN_USER_REGISTER — registration
• MAIN_USER_PASS_CHANGED — password change

For each event, we configure: FROM, TO, SUBJECT, email body. A typical mistake: the FROM address uses a domain that does not match the sending server's domain — SPF/DKIM fails, and emails end up in spam.

Mail Notification Health Check

Run a test via Settings → Diagnostics → Mail Test. If the email doesn't arrive, check:

• SMTP server logs (SMTP is the email transfer protocol)
• Errors in /bitrix/modules/main/lib/mail/
• Agent settings: they should run via cron, not on hit

If agents are not running, emails get stuck in the queue. For critical notifications (order, registration), we enable immediate sending.

How to configure SMTP?

Follow these steps to configure SMTP:

1. Go to Settings → Product Settings → Mail → Mail Agent.
2. Enter SMTP host (e.g., smtp.yandex.com or corporate server).
3. Set port: 587 (STARTTLS) or 465 (SSL).
4. Provide login and password of the mail account.
5. Select encryption type.
6. Click Test to verify.
7. If successful, save configuration.

After configuration, run a test. If the email doesn't go out, check SMTP logs and verify that your provider is not blocking the ports.

Why are emails not delivered even if SMTP is configured?

Most common reasons: missing SPF/DKIM records, incorrect queue processing (agents not running), or exceeding mail server limits. Check SMTP logs and agent settings. Our optimized SMTP configuration delivers emails 5 times faster than default Bitrix setup.

Creating Custom Mail Events

For custom notifications (e.g., manager assigned to deal), create an event type via the admin panel or programmatically using CEventType::Add(). Then create a template and trigger sending from code:

CEvent::Send('MY_CUSTOM_EVENT', SITE_ID, [
    'NAME' => $name,
    'EMAIL' => $email,
    'MESSAGE' => $text,
]);

Send Queue and Delays

By default, emails are sent through a queue using the agent CAgent::AddAgent(). If agents are not set up on cron, the queue can accumulate, and emails arrive with delays of hours. For important events, enable immediate sending in mail settings. We recommend setting up agents on cron — this guarantees delivery within a minute. After our optimization, average email delivery time can drop from 30 minutes to 10 seconds.

Common Errors During Mail Setup

SPF/DKIM misconfiguration is the most common: 8 out of 10 projects with delivery issues have incorrect DNS records. The second most common is exceeding SMTP server limits (e.g., Yandex limits 500 emails per day for free accounts). We use corporate plans or transactional services. The third is incorrect queue configuration: agents don't run, emails pile up.

Turnkey Mail Event Setup Deliverables

When you order the service, we provide:

• Audit of current mail configuration and events
• SMTP setup with SPF/DKIM records
• Creation and adjustment of all templates (standard and custom)
• Delivery testing on all popular email clients
• Documentation on settings and recovery
• Administrator training on working with mail events
• Delivery guarantee (subject to our recommendations)

Pricing starts at $200 for basic SMTP setup, $500 for full audit, and $1,000 for custom events. Our solutions typically save clients up to $200 per month in lost revenue from missed notifications.

Our specialists have over 5 years of experience and have completed more than 50 Bitrix mail setup projects with a 99.9% delivery rate. After setup, clients report an 80% reduction in complaints about non-delivery.

Timelines

Contact us for a free consultation on mail setup. Order a mail system audit — we'll check all events and templates and provide recommendations.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.