Bitrix24 SPF, DKIM and DMARC setup, step by step

Bitrix24 Webmail does not issue or publish your domain’s SPF and DKIM records. Configure authentication with the mail service that will actually send your messages, then connect that approved SMTP sender in Bitrix24. A connected inbox alone does not establish this outbound route. Bitrix24’s documented default can use a Bitrix24 noreply address instead of your branded From address. Bitrix24 Webmail FAQ.

This guide covers adding an external SMTP sender from an already connected mailbox in Bitrix24 Webmail, and proving that this specific route preserves your intended From and authenticated signing identity. It is not a universal Bitrix24 DNS recipe, a new mailbox-provisioning guide, an on-premise server-administration guide, or a campaign-launch procedure. Your SMTP provider’s current account-specific instructions govern its DNS records, signing activation, supported authentication method and secure connection parameters.

Choose the route before changing anything

Separate three things that can look similar in the interface:

• Connected mailbox: the inbox available in Webmail. Being able to read messages here does not prove that a new outgoing message uses your desired SMTP server.
• External SMTP sender: the outbound identity selected in the message’s From menu. Bitrix24 says SMTP-connected senders appear in the sender list, not as additional Webmail inboxes.
• Default Bitrix24 sending: without external SMTP configured, the FAQ describes messages sent from a Bitrix24 noreply identity. Replies can be forwarded to your real address, but a new message addressed to that noreply identity is not received. Reply forwarding is not proof of branded DKIM.

The SMTP article also mentions CRM and Marketing entry points. The steps here use the documented Webmail path; do not infer that every CRM automation or campaign automatically adopts the new sender. Validate each additional route separately before relying on it. SMTP configuration and sender-list behavior; default sending and reply behavior.

Gather the approved provider settings

Have the mailbox owner and mail administrator confirm the intended visible From address, actual SMTP service, account’s permission to send as that address, server hostname, port, encryption mode and supported authentication method. Keep a record of the previously approved sender configuration without copying passwords into tickets or shared documents.

The mailbox owner controls mailbox settings and access. A Bitrix24 administrator does not automatically have access to another employee’s inbox. The SMTP article separately states that only an administrator can connect SMTP in the on-premise edition. Use authorized access for your actual edition and account; this guide does not establish a universal subscription or regional entitlement. Mailbox ownership and access; on-premise distinction.

Credential creation, persistent application access, enabling SMTP authentication, or expanding sender permissions are separate security decisions. Obtain the appropriate owner’s approval and follow the mail provider’s current supported method. Do not disable MFA, bypass a certificate warning or simplify a password to troubleshoot this integration. The Bitrix24 source contains password-character advice; it is not a reason to weaken an existing credential. If the provider’s supported secure method cannot be represented by the available Bitrix24 controls, stop and resolve compatibility with the administrators rather than falling back to insecure transport.

Complete authentication at the actual mail service

Before routing Bitrix24 messages through the provider, have the mail administrator confirm that the intended domain is authorized and signing is active for this account and submission path. Bitrix24 explicitly directs SPF and DKIM configuration to the mail server, not Webmail settings. There is no Bitrix24-issued selector, public key, CNAME target or SPF include to copy from this guide. Official authentication responsibility.

The provider handoff should identify:

• The actual SMTP MAIL FROM domain used for this route, distinct from the visible From address and Reply-To.
• The intended DKIM signing domain and active selector or selectors, and whether SMTP-submitted messages receive that signature.
• Any required public DNS records with exact types, full owners and complete values, and the separate verification/signing activation steps.
• The effective DMARC policy and alignment settings for the intended From domain, including applicable inherited policy.

Do not edit DNS simply because you added an SMTP sender. If the provider is already correctly configured, preserve it. If a provider-specific change is needed, complete that provider’s supported workflow with the DNS owner before this integration is accepted. Do not replace MX, move nameservers, remove a delegated _domainkey namespace, overwrite existing selectors or publish a private key. CNAME versus TXT requirements belong to that actual provider packet, not to Bitrix24.

For SPF, evaluate the real MAIL FROM identity, not automatically your website’s apex. Keep one v=spf1 TXT policy per evaluated owner, preserve legitimate senders and qualifiers, and account for the ten evaluated DNS-dependent-term limit including nested mechanisms. An all mechanism makes redirect ineffective. A second SPF policy or a generic include guessed from the application name is not a fix. SPF specification.

Add the external SMTP sender in Bitrix24

Use an already connected mailbox, with the approved settings ready:

1. Open Webmail and choose New message.
2. Open the arrow beside From, choose Add sender, then select SMTP.
3. Enter the approved sender name and email address. Leave Available to everyone unchanged unless the owner has separately approved sharing this sending identity with other employees.
4. Enter the actual provider’s server and port. Configure Use SSL consistently with the provider-supported secure connection mode. The official prose instructs using SSL and a valid certificate; do not assume this label proves compatibility with every implicit-TLS or STARTTLS configuration.
5. Supply the provider-supported login and authentication credential through the approved account workflow. Do not copy credentials into DNS or share them as troubleshooting evidence.
6. If an outbound limit is appropriate, use Set daily email limit and the owner-approved value. The SMTP provider’s own limits still apply.
7. Choose Save. Confirm that the intended sender is available in the From list before the controlled test below.

These controls and Save are shown in Bitrix24’s current linked screenshots. The screenshot’s port 555, unchecked Use SSL, example address and daily limit 250 are illustrative, not settings to copy. Use your actual provider’s supported secure parameters; stop if the required security mode is unknown or cannot be selected safely. Saving a sender is configuration, not evidence that SPF, DKIM or DMARC passed. Full Bitrix24 SMTP procedure and screenshots.

Prove the Bitrix24 route, not just the mailbox

With authorization, send a controlled message from Bitrix24 Webmail with this exact SMTP sender selected to a valid external test recipient you control. Use non-sensitive test content, not a customer conversation or campaign. Record the selected sender, time and message identifier. Compare the delivered message with the intended route and, where available, the SMTP provider’s authorized trace.

A message sent from the provider’s own webmail is a useful control, but it does not prove Bitrix24 used the same transport or signing configuration. A message delivered through the Bitrix24 noreply route is also a different result. Do not quietly accept a fallback identity as completion of the branded task.

At the receiver, use Authentication-Results generated inside the actual receiving service’s known processing boundary. Establish that service’s documented treatment of externally supplied Authentication-Results, such as removing, ignoring or clearly distinguishing them. Ignore attacker-inserted fields. Header position and a familiar authserv-id string alone establish nothing; if the boundary is unclear, use an administrator-verified receiver trace instead. Authentication-Results trust boundaries.

Accept the branded route only when all of these are established:

• The visible From remains the approved branded address, not a rewritten provider identity.
• The intended external SMTP provider’s signature, matched by its active d= signing domain and s= selector, has a trusted dkim=pass and aligns with that unchanged From under effective adkim.
• The trusted receiver reports dmarc=pass for that From. An unrelated aligned signature or an SPF-only DMARC pass does not close the intended DKIM check.
• The actual MAIL FROM identity and its SPF result are recorded and explained, even if aligned DKIM is sufficient for DMARC.
• The authorized trace or equivalent evidence supports the selected Bitrix24-to-provider route. Receipt alone is not route proof.

DKIM relaxed alignment compares Organizational Domains; strict adkim=s requires the signing domain to equal the From domain exactly. SPF strict aspf=s requires exact equality between the MAIL FROM and From domains; a child envelope domain can satisfy relaxed alignment but does not automatically satisfy strict alignment. Do not promise a custom Return-Path or strict SPF alignment from the Bitrix24 sender screen. Current DMARC alignment specification; EmailAuth’s custom MAIL FROM and SPF alignment explanation.

Troubleshoot the right layer

The message still shows a Bitrix24 noreply address. Check the actual selected sender and whether the intended external SMTP configuration was saved and used for this message. The FAQ identifies missing external SMTP as the reason for its documented default route. Do not try to fix a different From identity by adding guessed SPF records. Default-sender diagnosis.

The sender is listed, but no new inbox appears. That is expected for an SMTP-only connection. It adds an outbound sender, not another synchronized Webmail inbox. SMTP sender-list distinction.

Connection or login fails. Reconcile the exact server, port, security mode, valid certificate, account authorization and authentication method with the provider administrator. Stop on an unresolved security mismatch. Do not disable encryption or MFA, grant unrestricted relay access, or rotate shared credentials without approval.

DKIM is absent or fails. Ask the actual sending provider to confirm signing for this account and SMTP submission route, then check the active selector, complete public key resolution and whether a later relay changed the message. Do not generate a Bitrix24 selector or declare success because another signature passed.

SPF fails while DKIM passes. Investigate separately: fail or softfail concerns authorization or the selected policy qualifier; temperror indicates a transient evaluation problem such as DNS availability; permerror indicates a policy/evaluation defect such as duplicate policies, invalid syntax or exceeding the lookup budget. Diagnose the real envelope domain and sending route, not an assumed apex. Passing DKIM does not make these defects harmless. SPF result definitions and evaluation limits.

The message is canceled or delayed. The FAQ lists a nonexistent recipient or a blacklisted address as reasons for its cancellation error. Check a controlled recipient and the relevant policy without automatically removing suppressions. Queuing can delay mail, so do not send repeated test messages or change DNS merely because delivery is not immediate. Bitrix24 cancellation and delay guidance.

Preserve policy and recover safely

This integration does not require a new DMARC record or a policy downgrade. Preserve existing direct and applicable inherited policies, alignment settings and authorized report destinations. If no policy exists, arrange a separate domain-owner-approved deployment and monitoring plan; this guide intentionally does not supply a first-policy TXT record to paste while troubleshooting SMTP.

If report recipients are changed in that separate work, compare the Organizational Domain of the report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. A different Organizational Domain requires the report-generating receiver’s DNS authorization check; destinations within the same Organizational Domain are excepted. That protocol check does not replace owner approval of the recipient, report-data sharing and privacy implications. Aggregate reporting authorization, RFC 9990 section 4.

If testing fails, preserve the failed message and sanitized diagnostics. With the workflow owner, pause only affected sending or restore the previously approved sender/transport configuration. Do not intentionally exhaust limits, disable security, delete a mailbox or remove shared DNS keys to force a fallback. Preserve selectors needed by queued mail and other senders. Retest the failed Bitrix24 route and a known-good controlled provider route before resuming affected work. Do not silently change production mail to the default noreply identity if the approved requirement is branded From.

Documentation review and testing boundary

These are distinct from our review date. This guide is documentary guidance: no customer credentials, account settings, DNS records, actual messages or live application behavior were changed or tested during its preparation. Authentication does not guarantee inbox placement.