Setting up email campaigns in Bitrix24: SPF, DKIM, segments, limits

Setting up mailings in Bitrix24: where emails get lost

Mass mailing to the database goes to spam or queues for sending — and from the outside it looks like "emails don't reach the recipient." The sales department thinks clients simply aren't responding, but in reality the receiving server rejects messages: some addresses return a hard bounce, the rest quietly land in the Spam folder and are never opened.

The cost of the mistake is a burned-out database and domain reputation that then takes months to restore.

The cause is almost always a combination of four things. The domain is not verified: the SPF and DKIM records lack the required values, so the recipient cannot verify that the email was actually sent by you.

The mailing is sent from managers' personal inboxes, without segments and without accounting for those who have already unsubscribed. And no one limited the sending rate — the receiving side sees a spike of identical messages and blocks the entire stream.

The first place to look is the email sending log in Bitrix24. There, for each message, you can see whether it was accepted, deferred, or rejected, with which response code, and which exact address bounced.

This removes guesswork: instead of "the mailing doesn't work," you get a list of specific causes — from an incorrect address format to a restriction on the email provider's side.

Next we examine how this is resolved: we verify the domain, set up email scenarios in the CRM, split the database by activity, and introduce a rate limit. Email deliverability stops depending on who pressed the send button and when.

What well-structured email sending gives: reach, response, reputation

The result of competent sending is visible not in settings but in campaign reports.

The first thing that changes is the share of delivered emails: the sending domain is verified and signed, mass and service streams are separated, and emails stop going to spam and the promotions tab. The effect is noticeable already on the first thousand addresses and only accumulates further.

The second metric is the unsubscribe rate. It falls when the mailing goes to segments of activity and interest, rather than the entire database at once: the client unsubscribes not from the company but from an irrelevant stream.

An honest sending frequency reinforces the same thing — response to emails grows, irritation does not.

The third is the speed of client response. When emails for a request, invoice, shipment, or abandoned purchase are sent automatically and at the right moment, the client responds within an hour, not after a manager's call. This directly shortens the deal cycle.

The fourth is the load on managers. Auto-replies, follow-up chains, and clear instructions remove typical questions, and time goes to those ready to discuss terms. In reports, this shows up as growth in qualified inquiries with the same headcount.

All these metrics rest on the reputation of the sender domain: it accumulates slowly and is lost on the very first spam complaints and a "junk" database.

You can check the effect over one reporting period — compare the delivery rate, unsubscribes, time to response, and number of inquiries per manager before and after setup.

Segments and mailing limits: how to avoid getting blocked

Mass mailings to the database and transactional emails with invoices go through one domain but live by different rules.

If you mix them in one stream, complaints about an advertising campaign hit the domain's reputation, and the client stops receiving invoices — the most expensive class of failures, which is then searched for weeks.

The mode is chosen by task, not by interface convenience:

Email sending rate is the parameter most often ignored. A sharp start to the entire database causes a spike in complaints, and providers begin throttling delivery for the entire domain, including invoices.

Therefore, campaigns go in waves: first the most active segments, several hundred addresses, with a pause between waves, and unsubscribes and hard bounces are immediately excluded from the database; otherwise they accumulate and spoil the statistics of subsequent campaigns.

We configure domain authentication on both circuits — without verified signatures, some emails go to spam even before the content is evaluated.

We take the external service when the database and campaign frequency outgrow the portal's limits; we leave the built-in one for triggers and moderate segments. A task review will show which mode you specifically need.

Work stages: from domain audit to handover of regulations

Setting up mailings in Bitrix24 begins not with an email template but with an analysis of how email is sent now.

By default, the agent sends through a corporate mailbox, and at a volume of several hundred emails per day, providers begin throttling connections or putting emails into spam. Below is the order of work, where each step relies on data from the previous one.

1. Domain and email signature audit. We check SPF, DKIM, and DMARC records, reverse DNS, the domain's reputation history, and the current spam placement rate. We record what is missing for legitimate sending.
2. Sending scheme. We analyze what goes through the email service and what goes through the corporate server, how transactional and mass streams are separated, and which domains the mailing goes to.
3. Email service connection. We verify the domain with the provider, configure records, set limits by stream, and define the behavior rule when sending fails.
4. Segment assembly. We tag the database by activity, source, and recency of consent so that mass emails do not go to those who have not opened them for a long time.
5. Testing on a test database. We run emails through mailboxes of different providers: we look at delivery, placement in interfaces, the unsubscribe link, and field substitution.
6. Handover of regulations. We provide instructions: how to add a segment, where to view bounce statistics, and what to do if deliverability drops.

What you keep: schemes, domains, templates, regulations

We do not leave the result in correspondence: your team keeps a working set of artifacts by which mailings can be run, checked, and developed without us. Below is exactly what we hand over and how each document is used in daily work.

• Sending scenario map — a table "event → email → segment → owner": registration, abandoned cart, deal status change, reactivation. It immediately shows where triggers are duplicated and where a new email will fit.
• Configured domain and records — SPF, DKIM, and DMARC policy in an agreed form, a separate subdomain for mass emails so the main domain's reputation does not depend on mailings, plus a verification instruction.
• Database segmentation rules — by which fields we divide contacts, how often we rebuild segments, what we do with inactive addresses and unsubscribes. The rules live inside Bitrix24, not in a separate file.
• Email templates — one set with block-based layout: header, body, legal footer, substitution variables. A new campaign is assembled from blocks without touching the layout.
• Contact database regulation — frequency of cleaning invalid addresses and hard bounces, procedure for updating subscription consent, who handles disputed cases and within what timeframe.
• Instruction for managers — a short memo: how to send an email manually, how to check that a contact is not on the stop list, what to do about a spam complaint, and where to record it.

We write the regulations for your process, not "according to the textbook": we coordinate with marketing, support, and sales so that the documents do not diverge from how work actually happens.

Case study: mailing to the database without blocks and manual cleaning

The client sent promotions and trigger chains from one domain and one stream: the subscriber base had accumulated over years and amounted to about 180 thousand addresses.

By the time of the review, deliverability held at 88%, unsubscribes and complaints were at 2%, and preparing one campaign took 5–6 hours: segments were assembled by exporting to a spreadsheet, and duplicates and invalid addresses were cleaned manually.

There were three causes: the domain was not authenticated, transactional and mass emails were sent from the same sending address, and the system did not react to complaints and returns.

We separated the streams by subdomains, configured SPF, DKIM, and DMARC, limited the sending speed during the warm-up period, and enabled automatic disabling of an address after a hard bounce.

Segments in Bitrix24 were built on activities — opens, clicks, last order date — instead of regular exports.

Hard bounces disappeared as a class — only temporary ones remained, which are resolved by a retry. Emails stopped going to those who do not read them, so unsubscribes fell fivefold, and the domain's reputation stopped dropping after each large send.

Preparing a campaign shrank from half a workday to 40 minutes, and the marketer no longer moves segments by hand.

What to do if emails are already going to spam or the database is not warmed up

First we separate two diagnoses: authentication and domain reputation.

If the email signatures are configured and the reverse zone matches the sender, but emails still land in spam, the cause is not technical but in recipient reactions: complaints, deletions without opening, and trap addresses inside the database. Then the work goes in reverse order: first cleaning and warm-up, then returning volumes.

Cleaning inactive addresses is a stop list, not deletion. Hard bounces, spam complaints, role mailboxes like info@, and duplicates go into it.

We do not discard contacts without opens for 90–180 days but move them to a separate segment for audience re-engagement and touch them with a short email series.

We build the contact database warm-up from the active core: first those who opened emails in the last month receive them, then we connect the segment up to 90 days, and only after that — the rest.

Volumes grow in portions, with control of unsubscribes, complaints, and inbox placement on mailboxes of different providers.

We keep the phased return to sending at measurable thresholds: complaints — tenths of a percent, unsubscribes — within a couple of percent, bounces — near zero.

As soon as a metric goes beyond the threshold, we step back to the previous volume and give the database time to stabilize. In Bitrix24, the pace is set by sending limits and segments, so a drop is visible at every step, not only after a block.

We separately split transactional and marketing streams: different subdomains and senders, so that a spike in complaints about a mailing does not drag down service notifications.

Common technical doubts before starting

Doubts before starting are almost always the same: will there be enough limits, can you send from your own domain, what to do with unsubscribes, and what access will be needed. Below are short answers so you don't have to figure this out during setup.

Can you send from your own domain?

Yes, and this is the right option. The domain remains yours; we add service records to it — sender verification and email signature — verify the domain, and only then launch sending. Without these records, mass emails go to spam or are rejected by recipients' mail servers.

How are unsubscribes handled?

The unsubscribe link is inserted into the email automatically, and the fact itself is recorded in the contact card. The address is immediately excluded from the segment, and no repeat email will be sent to it. There is no need to maintain stop lists manually.

What access is needed on our side?

Portal administrator rights or a separate role with access to mailings, access to the domain panel for editing service records, and a test mailbox for checking delivery. Access is granted for the duration of the work and revoked after handover.

Are mailings linked to tasks and deals?

Yes. Emails are triggered by deal stages and by tasks: a status change activates the required scenario. All correspondence is saved in the card — the manager sees what and when the client received.

Let's discuss the task: what to send and where to begin

To come back with an estimate and work plan, rather than general thoughts, we need inputs on two circuits — email and the contact database. Below is the minimum list: usually it resolves half the questions even before the call.

• Domains and addresses from which mailing is or is planned to be sent, including subdomains for mass sends.
• State of SPF, DKIM, and DMARC records: what is already published, who manages the zone and can make edits.
• Database volume, source of contacts (CRM, web forms, exports), and how often it is updated.
• Segmentation principles: by what criteria the audience is currently divided and what happens to it next.
• Statistics of recent sends: undelivered share, spam complaints, unsubscribes, repeat inquiries.
• Current pricing plan and daily limits on sending volume.
• Who on the client side approves texts and is responsible for providing access.

Then the order is simple: we discuss the task, review the inputs, and come back with an estimate and work plan — what we address first and what we can safely postpone.

After approval — access handover, setup on one domain and a test segment, verification of deliverability and reactions, then rollout to the remaining streams.