Planning email integration with BMC Helix services

Some BMC Helix services offer an internet-based email integration for receiving messages (customer-initiated email updates in BMC Helix applications) and sending messages (BMC Helix application-initiated notifications). Email exchanges use standard Simple Mail Transfer Protocol (SMTP) transactions between your mail infrastructure and the BMC Helix mail infrastructure, as shown in the following figure:

Systems-level integration architecture


The SMTP incoming and delivery servers are BMC-managed infrastructure.

Connectivity to external cloud and on premises infrastructure needs to be reviewed and approved by your BMC Account Management and technical teams; otherwise external connections are considered to be prohibited. Custom headers are not supported.

For the avoidance of doubt, the external cloud and on premises infrastructure configuration, administrative settings, logs, and your network environments are managed outside of BMC, therefore out of scope for BMC Support.  

Implementation options

For your email integration with BMC Helix services, you must make decisions about encryption settings and masquerading the BMC Helix mail address.

Inbound - BMC will host the public inbound mailbox, under the control of the Helix Service.

Outbound - When the Helix Service sends an email, the "From" address can be either our domain or a BMC customer's domain. BMC is also able to relay emails to a BMC customer-hosted mail server using a standard username and password protection.


To guarantee message privacy as email messages transit the public internet mail infrastructure, BMC supports email encryption based on Transport Layer Security (TLS) and Secure Sockets Layer (SSL). The use of TLS and SSL encryption for messages from your infrastructure to BMC Helix services is under your control and is configurable within your mail infrastructure. No additional action is required from BMC SaaS Operations to enable encryption.

For messages sent from BMC Helix services to your mail domains, you can request that BMC enable encryption by indicating either preferred, required, or none. When preferred, the BMC Helix service attempts to use TLS and SSL encryption when available, but can still use unencrypted delivery if TLS and SSL are unavailable from your mail infrastructure. When required, BMC queues and does not deliver messages unless TLS and SSL encryption can be used. To use mail encryption, your mail infrastructure must support the standard SMTP STARTTLS protocol command for the delivery of encrypted messages. When none, encryption is not enabled.

For this decision, you select required, preferred, or none for each of your mail domains.


BMC can guarantee TLS and SSL encryption only to the mail exchange (MX) host defined in the internet DNS for the customer mail domains. If you use an intermediary for mail delivery, you must separately ensure encryption between mail hosts in their delivery architecture.


You are given an email receiving address ( By default, BMC Helix applications also use this address as the apparent email "From" address for each message sent from the application to you. To enable masquerading, you supply an alternative email address such as, to use as the apparent "From" address. When enabled, this alternative email address is seen as the apparent "From" address for all messages sent to you from the BMC Helix application.

You might also want to use masquerading for messages sent from your users to BMC Helix services. To enable this behavior, you must establish a redirect or transfer rule in your mail infrastructure to forward messages from the masquerade address ( to the BMC Helix application receiving address ( No additional setup is required to enable masquerading.

For this decision, you select an alternative apparent "From" address or the default address.

When masquerading is used, you might be required to place the BMC Helix mail delivery server on the list of safe recipients. This action is required if your organization rejects mail messages from the internet where the "From" address is an internal company address, which is a common spam-avoidance filter. When requested, BMC SaaS Operations will provide the correct hostname and IP address to use for proper allowlisting.

Additionally, BMC recommends that customers using devices that interrogate traffic to/from the BMC Helix services (e.g., Bluecoat Proxy, Websense, Sophos UTM, Cisco SourceFire) be configured to allowlist ‘’ traffic through their proxies in order to optimize the user experience. Creating this exemption helps improve the performance as these devices basically serve as a traffic cop that will parse all traffic coming inbound and going outbound to the internet. By placing this exemption, user traffic is no longer interrogated or has to wait while other traffic is interrogated. If you are seeing ARERR 9351, you need to add this exemption.

For a list of external IPs required for allowlisting, see Public IPs for outgoing email servers.

Email alias

Administrators can create email aliases that forward all emails addressed to the alias to a specified account.

An email alias provides users the option to use different email addresses without having to manage multiple email accounts. Email alias makes communication simpler by letting users have multiple addresses for different purposes.

For example, you can use to handle invoices and to handle general inquiries. In this case, both addresses should point or forward the emails to the onbmc primary email account, that is,

Email security requirements

Sender Policy Framework (SPF)

SPF configuration is necessary to ensure that only authorized senders are authenticated on behalf of that domain. This setup will prevent forged emails and spam. With SPF configuration, your email server (where the domain is hosted) will identify the exact email server from where mails are sent. You will need to add the hostname or BMC's email server IP range in the SPF record of their domain.

Masquerading outbound emails with a sender address on behalf of the customer's  domain or third-party network will only be allowed if the following conditions are met:

  • The customer or third party must take steps to trust the BMC Helix SMTP servers to send emails on their behalf.  This includes adding our SMTP server public IP addresses to their published Sender Policy Framework (SPF) record. 
  • The customer or third party must modify their email filters to accept the masqueraded email from BMC SMTP servers without flagging it as unsolicited.
  • The customer or third party must provide evidence showing the above steps have been addressed.

Once these conditions are met, BMC will approve the masquerading configuration and move forward with implementation.

In the illustration below, we show the process flow for publishing the SPF record (customer task) and sending the email (outbound from BMC):

DomainKeys Identified Mail (DKIM)

DKIM is used to validate the authenticity of the email that is being sent. It protects the domains from email spoofing, thus protecting the messages' integrity. Using public-key cryptography, DKIM validates the content of the email by generating two keys: one is public and registered with the ISP (where the domain is hosted), and the other is private, configured by BMC and retained on the outgoing mail server. Together these keys create a digital signature that verifies that the destination server has received the message unaltered. 

DKIM uses two actions to verify your message:

  1. The first action takes place on a server sending DKIM signed emails:

    BMC will create the DKIM key pairs and provide the public key to you to add to your DNS. Your private key is kept secret and safe. When the sender sends an email to the recipient's email server, the DKIM signature is encrypted and attached to the mail header.  
  2. The second action takes place on the recipient server checking the DKIM signature:

    The receiving email server extracts the DKIM signature from the header and compares it with DNS records. A matching signature means that the DKIM check passes and the email is delivered.

To request help with your SPF or DKIM request, submit a request to BMC Support. For additional information, see Inbound and outbound email integration.

Multiple mailboxes to support multi-tenancy

One mailbox for each environment is supplied with your subscription (ie. a mailbox for BMC Helix ITSM and a mailbox for BMC Helix Business Workflows service). If you require multiple mailboxes to support multi-tenancy or a similar use case, you must submit a Case on Support Central > Case Management and include the following details: 

  • Company Name
  • Specify whether the mailbox should be added to BMC Helix ITSM or BMC Helix Business Workflows (especially if you have both subscription services)
  • Service URL

For additional mailbox requests with your BMC Helix ITSM and/or BMC Helix Business Workflows subscription service, please submit a Support Case. BMC Support holds the right to reach out should there be any concerns with your additional mailbox request. 

BMC Helix-to-customer mail delivery pattern

The following figure shows the detailed mail delivery flow for messages originating in BMC Helix applications for delivery to a customer email address:

BMC Helix-to-customer delivery

Click the image to expand it.

Customer-to-BMC Helix mail delivery pattern

The following figure shows the detailed flow for messages from a customer to BMC Helix applications:

Customer-to-BMC Helix delivery

Click the image to expand it.

Was this page helpful? Yes No Submitting... Thank you


  1. Mahendran Tm

    Few queries on Mailbox integration for SaaS Customers

    One Email box from BMC can have multiple aliases created - Is this aliases considered as Multiple email integrations ?

    In that case SaaS customers need to purchase Non Standard integration options with the number of aliases or it is considered as Service/Change Requests without Commercials involved ?

    Clarity on this in the documentation will help Customers for planning the email integration..

    Dec 11, 2019 02:15
  2. Sourabh Jhunjhunwala

    Query from several customers...

    Can we do the integration or connection of Helix to cloud-based exchange services (Office365) for email integration ?

    Jun 05, 2020 11:01
  3. Rahul Ranjan

    Mahendran Tm Aliases are virtual email addresses only so it wont be considered as multiple email integrations. Aliases will use the same mailboxes which are configured on email server. No need to purchase the Non standard integration for aliases.

    Sourabh Jhunjhunwala : No, we dont permit third party email servers on any application. All emails must go via BMC email servers only.

    Mar 10, 2021 10:29
  4. Julio Goncalves

    Please add a paragraph/section with comments in regard to the ability (or not) of adding custom headers to outgoing SMTP emails as part of the email integration.

    Sep 07, 2021 07:43
    1. Betty Xu

      Hi Julio, we send you an email for an internal review.  Please check your inbox.  Thank you for the feedback to improve our documentation! 

      Jun 28, 2022 02:31
  5. Andreas Petraschke

    "This enablement can either be preferred or required."


    "For this decision, you select required, preferred, or none for each of your mail domains."

    makes no sense to me. Is "none" missing for the first one?

    Dec 02, 2022 10:40
    1. Dhanya Menon

      Hello Andreas,

      Thank you for your comment. We have modified the text to indicate that enablement can either be preferred or required. 



      Jan 17, 2023 04:51
      1. Andreas Petraschke

        Thank you Dhanya

        It still doesn't make sense to me - please review it again.

        Jan 17, 2023 05:34
        1. Dhanya Menon

          Thank you for your comment, Andreas.

          I have updated this page with information for None option too.

          Hope this helps.



          Jan 18, 2023 03:55