Reflexion KBA's

If you are seeing a 503 MAIL FIRST error in a client's outbound queue, this could stem from a number of issues:

1: The MAILFROM field in the message is blank

2: If from a Distribution list, NDR tracking is not enabled.

3: If part of a multiple recipient message, one of the recipients addresses is blacklisted within Reflexion

To solve both 1 and 2, please open up the mail contact/user object properties in AD and confirm that the "Manager" checkbox on the Organization tab is selected, and filled in.

If this does not solve 2, please run the following script where "DistributionGroupName" is the name of the Group object:

Set-DistributionGroup "DistributionGroupName" - ReportToOriginatorEnabled   $true

To solve 3, please provide a list of the recipients to Reflexion Support and they will compare against our internal blacklist.

Please note, that causes 1 and 2 are the most likely reasons for this.  Please check these first.


The error message "#553 sorry, relay of mail is not allowed. (#5. 7.1) ##" indicates that:

  • The smarthost is not configured correctly to send mail via
  • The sending IP address(es) of the server are not listed as a trusted host
    • Your IP address may have changed or the IP address you are sending messages from is not in our trusted hosts
  • The sending domain is not sending from a declared domain in Reflexion


Log into your GoDaddy DNS control panel. 

Scroll down to MX Records.

Add the entries as seen below:


This error indicates the connection died after the we sent the data, often a sign that the receiving server's content filtering is being maxed out or that there is some type of connection filtering on the server/firewall.

For our customers using Cisco PIX or ASA firewalls, we suggest that the SMTP Fix Up or Inspect ESMTP settings be disabled on your firewall.  

These settings have been known to be related to undelivered or delayed inbound and outbound messages. For additional information regarding this issue, please see: 

For information on these settings and how to make changes, please see the links below:

3rd Party Blog - Cisco ASA Disable ESMTP Inspection:

Cisco Security Appliance (PIX 500 series, ASA 5500 series) Inspect Command Reference:

Cisco PIX 6.3 Configuring Application Inspection (Fixup):

Cisco Catalyst 6500 Series Switch and 7600 Series Router Firewall - Configuring Application and Protocol Inspection:

Microsoft TechNet - You Cannot Send or Receive E-Mail Messages Behind a Cisco PIX Firewall:

Please note that making any configuration changes to your networking appliances can have wide-reaching consequences. Please consult your organization's change control procedures before altering any settings.


Feedback and contact

If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.
This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

How to setup ConnectWise.


See the attached guide for Exchange 2013, Exchange 2007/2010, and Exchange 2003 smart host setup instructions.

Please be aware that the smarthost configuration is REQUIRED for RTCEncrypt, and highly recommended for RADAR/RADAR-Lite.

Feedback and contact

If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.
This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

This article is for issues sending to Gmail recipients and seeing the following error:
Remote host said: 421-4.7.0 This message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best protect our users from spam, the 421-4.7.0 message has been blocked.

Google and Gmail have started using a much more strict SPF filtering policy which requires a sending domain's SPF record to be correctly formatted.  Gmail is also rejecting messages from domains that do not have an SPF record listed.  Please make sure that the SPF record is in place, and correctly formatted by following the instructions in this other KB:


Enforcing IP restrictions is absolutely critical to ensure complete protection of your mail server. Because hackers and spammers can easily bypass cloud services and target your server directly, mail servers protected by Reflexion should only accept SMTP connections from the Reflexion IPs listed below and deny all other traffic:            (


Office 365

In the Exchange Admin Center (EAC), click Mail Flow > Connectors. Then create an Inbound Connector to receive emails from Reflexion IP's below: ( ( ( (

Exchange 2013

  1. Mail Flow, Rules, Create a new rule
  2. Apply this rule if, sender location is Outside the Organization
  3. Do the following - recommend reject or delete the message
  4. Click More options
  5. Add Exceptions for the Reflexion IP addresses            (            (            (            (

Exchange 2007/2010

  1. Open the Exchange Management Console
  2. Navigate to Server Configuration > Hub Transport > Default Receive Connector > Properties > Network tab
  3. Under "Receive mail from remote servers that have these addresses:" find the entry that says and delete it
  4. Under "Receive mail from remote servers that have these addresses:" click Add
  5. Input the first Reflexion IP range; repeat this step for each Reflexion IP
  6. Click on the Permission Group tab and ensure that anonymous delivery is allowed from our ranges
  7. Stop and restart the MSExchangeTransport service on the HUB transport server(s)

Exchange 2003

  1. Open the Exchange System Manager
  2. Expand Servers > Server Name > Protocols > SMTP > right-click "Default SMTP Virtual Server" (or the active receive connector name) and select Properties
  3. Navigate to the Access tab and then select the Connection button
  4. Remove any entries from previous providers or entries that have the IP range -
  5. Click Add to enter a new IP restriction
  6. Select the group of computers option, insert the first IP range for Reflexion, set the subnet mask to and click OK; repeat this step for each of the Reflexion IPs
  7. Restart the Simple Mail Transfer Protocol (SMTP) service to apply the changes

Feedback and contact

If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article.
This is invaluable to us to ensure that we continually strive to give our customers the best information possible.

Reflection: One Minute Video - Reflexion Archiving Discovery and Recovery (RADAR)

Reflexion's Spoofing Prevention option checks the Addresses listed in the headers of the message to determine if the inbound message is spoofed:

If either the Display address (From-address in Outlook) or the X-Sender address (Sender field in Reflexion Reports) claims to be from the domain receiving the mail, we will fail the incoming message.  This option does NOT check the domain's SPF record, OR the Username field in a piece of mail.  The block can be avoided by adding the X-sender to the Allow List, or by adding the sending IP to the IP Filtering good list.

Example of a message we would block:
From: []
to: []
X-sender: abc@phishco.spm

Example of a message we would NOT block:
From: Max McElroy [abc@phishco.spm]
To: Max McElroy [
X-Sender: abc@phishco.spm

In the second example, the Username field of the message is copying the name of a user, but the Reflexion system only checks the email addresses that are listed within the headers, in this case the abc@phishco.spm address.  Since this @phishco address is not listed in our Enterprise, we would not see this as a spoofed message.
There are ways to combat these Username field spoofs however, which are outlined in the below Technet article:

This article applies to any Enterprises that are sending mail outbound through our Smarthost

This article will: Briefly define DKIM and describe how it interacts with Reflexion

This article will NOT: describe how to configure DKIM

DomainKeys Identified Mail (DKIM) is a method to ensure that mail is A) coming from where it is supposed to, and B) not manipulated or altered while in transport.  This is achieved by adding a txt record with a "public key" to the domain registry, adding a "private key" to the mail service, and encoding a hashed copy of the keys to all mail sent by the mail service.  If the message is altered in transit, the hash of the keys is changed, and if the recipient server is enforcing DKIM checks, the message will be handled according to the recipient's checks.  This can be used to prevent "man in the middle" and hijacking style attacks from being delivered through email.  When used in conjunction with SPF or DMARC, DKIM can further helps prevent spoofed or false messages from being delivered.

However, Reflexion does not currently provide our own DKIM signing for outbound messages.  In addition, because of how DKIM is designed to work, we also cannot recommend using the Control Panel Footer if you both have DKIM, and use our smarthost for outbound mail.

As previously described, altering a message while in transit will change the key-hash for a DKIM protected message.  When Reflexion added the Control Panel Footer to an inbound message, this will break the hash for an inbound message.  Furthermore, when a message is sent back outbound through our smarthost we will strip the footer out of a message if we detect it; which would also cause any outbound messages to then fail a DKIM check.  Our official statement for our own clients is that we do not support the use of DKIM for this reason.

If your domain is utilizing DKIM to secure your messages, you can disable the Control Panel Footer for inbound messages.  This will allow you to send outbound through Reflexion without the key-hash being disturbed.  Alternatively, you can remove the Reflexion smarhost from your environment, but if the Control Panel Footer is active, external recipients will be able to see it.

Currently, we do not have any plans to initiate DKIM support.  If this changes, we will notify our partners and clients, and provide in depth configuration instructions.

For this Setup piece, we draw heavily from Google's own documentation.  Please start with this page:

This page is a refresher on mailflow and some terms.

In the GSuite portal

Inbound FROM Reflexion

On this page, you will setup your Inbound Gateway.  This setting will allow mail that is filtered by us to be exempted from DMARC and DKIM scanning.  You can also tag messages that do not come from our IPs as spam, or flat-out block them. Please add the following IPs to the table: ( ( ( ( (

Outbound TO Reflexion

This page has the setup instructions to send to our Smarhost.  Once you reached the Outbound Gateway field, please enter our smarthost address and hit save:

We strongly recommend using the FQDN for our smarthost rather than the IP.  We do not expect to change our IPs anytime soon, but using the FQDN will help prevent any mailflow outages if our IPs do change.

In the Reflexion Portal.

Domains(To receive email)

Please put the original MX records received from Google into the Domains table and set delivery to port 25.  

Trusted Hosts

Please put the public IPs for GSuites into the Trusted hosts table.  You do not need to put in individual IPs, but the ranges published by Google will cover their IPs.  The list below contains most of their IPs, but please also check with Google in case new or different ranges are in use. (This list is accurate as of 23 October, 2019)     

Please also remember to set your MX records to Reflexion.

While not mandatory, setting an SPF record can help streamline outbound mail transfer and helps our SPAM engine protect you and your clients from spoofed mail.

This guide will cover both inbound and outbound configuration

NOTE: We recommend this process is completed using Internet Explorer. There are known issues with browser controls used in the final validation step.


To set up outbound mail with Office 365, you will need to do the following:

  • Log into the Office 365 administration console.Navigate to the Admin > Exchange menu.
  • In the Exchange Admin Center, navigate to the Mail Flow > Connectors menu and create a new connector.
  • In the “From” section, select Office 365, and in the “To” section, select Partner Organization. Click Next.
  • Give the new connector a name, optional description, and decide if the connector should be enabled once it has been saved using the “Turn it on” checkbox. Click Next.
  • Leave the default “Only when email messages are sent to these domains” selected and click the plus icon to add the recipient domains that should use this connector.
  • To route all outbound email to Reflexion, enter * here and click OK, followed by Next.
  • Select the “Route email through these smart hosts” option, then click the plus icon and enter as the smart host. Click Save, followed by Next.
  • Leave the default “Always use Transport Layer Security (TLS) to secure the connection (recommended)” and “Issued by a trusted certificate authority (CA)” set and click Next.
  • Verify your settings and click Next.
  • To validate the settings, add an email address of a recipient from a domain external to your organization and click Validate.
  • Once Office 365 has successfully validated your settings, click Save.

Next Steps

To verify that Office 365 is routing email outbound via Reflexion successfully, log in to the Reflexion Console ( and click on the customer name > Reports > Recent Messages > Outbound.

You should see messages from your organization's internal users to external recipients listed here.

If you do not see messages listed here shortly after they have been sent, this typically indicates a configuration problem with your Office 365 send connector.

Double check your configuration and use the Office 365 Message Trace tool found in the Mail Flow > Message Trace menu of the Exchange Admin Center to help you identify the issue.


For inbound configuration, the MX records for the domain will still point to Reflexion.

In Reflexion

Office 365 should provide you an inbound MX record. Typically their MX records are in the form "company-domain"

In our portal, you can click on Enterprise Options > Enterprise Domains and then "Click here to add a new domain route" or you can click the icon under the Edit column and modify your existing entry.  If you are creating a new delivery destination, please make sure that the Type is set to FQDN.

In O365

Since messages are already being filtered by Reflexion, there is no need to have inbound mail filtered again by O365.  To disable the spam filtering specifically for messages coming from our IP addresses, please create a Mail Rule with the following flags:

Reflexion bypass

Apply rule if
Sender is located : Outside the organization

Sender's IP address is in the range:,,,

Do the following
Set spam confidence level (SCL) to : Bypass spam filtering.

This rule allows any messages forwarded by Reflexion to bypass any spam checks that O365 performs, including SPF checks which often cause inbound mail to end up in user's junk mail boxes.
Additionally, you could also create a "mirror rule" to reject any messages that do not come from our IP addresses.  O365 does not provide a template for this however, so we do not have an example to provide.

This article will: provide basic information on the Reflexion RADAR product series.

Reflexion offers a paid service add-on called "RADAR" to all clients.  Reflexion Archiving, Discovery, And Recovery is an archiving service that collects mail that has been processed by the RTC system, copies it, and pipes it over to our archive database.  There are two different types of archiving under RADAR:


  • Unlimited volume, indefinite duration.
  • Allows for the creation of "Packages" of mail from the archive in eml or pst format. 
  • Allows for the use of the Power Search feature. 
  • Archive contents can be exported by the Archiving team ONLY in EML format.
  • Allows for the use of "Journaling" configurations to collect mail sent between internal users on the local mail exchanger.


  • Unlimited volume, 90-day rolling duration. 
  • Does not support the Power Search, Packaging, or Journaling features. 
  • This "lite" version of the archive is best used by organizations that need to have a short-term mail collection but are not required to hold onto the messages beyond that time.

RADAR Requirements:

RADAR is enabled per mailbox.  Each mailbox is required to use the RTC service if they wish to have their mail archived.

To collect both inbound and outbound mail, use of the Reflexion smarthost is required.

Please feel free to contact Support if there are any questions on this information!

This article applies to any Enterprises using any Reflexion services (RTC, RADAR, RTCEncrypt)

This article will: briefly describe recommended practices and requirements, provide links to configuration KBs

This article will not: provide specific configuration information (MX, smarthost, etc)

Reflexion can be a little confusing when first approached, but thankfully the configuration and setup are simple and straightforward.  If you just purchased your Reflexion licenses through Sophos, created your first partnered client, or just need a refresher, please read on for a high level description of the setup flow.


1. With the Enterprise created in the database, the next step to is to make sure that the final destination mail server (mail exchanger) is setup to receive from Reflexion.  On Exchange based systems, this is accomplished by creating Connectors that allow mail delivery from out IP ranges. 

2. Once the inbound mailflow is configured, you can safely set your MX record to point to Reflexion's servers.

3. If you are sending outbound through our services, we very strongly recommend configuring an SPF record with Reflexion's information in it.  While SPF is not a standardized Internet policy, it has become very popular as a domain authentication item.  Reflexion does not offer DKIM signing, and we cannot recommend using Reflexion outbound while using a DKIM signature.

4. For outbound mail-flow, you will create another Connector, this time from the mail exchanger targeting Reflexion's smathost. 

For additional information on these steps, please view this KB: 

Enterprise Settings

The settings on the Enterprise Properties page are the "New User Default" settings: any users created will automatically inherit those settings.  The default settings will capture are effective, but may require some fine-tuning.  For a "quick-setup," we would recommend moving the Spam Threshold slider to 75, and enabling the Spoofing Prevention option.  For more information about advanced filtering options, please view this KB:

Additional Paid Services

Reflexion Archiving, Discovery, and Recovery (RADAR).  Reflexion offers the RADAR archiving service as an additional option to RTC.  This will automatically copy any messages processed for archive enabled users over to the RADAR service.  Users are then able to access their archived mail on the portal.  For information on RADAR, please view this KB:

Please note: For optimal performance on RADAR, we strongly suggest using the Reflexion smarthost to send mail outbound through our servers.  This will allow us to capture both inbound and outbound mail for the enabled users.

Reflexion Encryption Services (RTCEncrypt).  Utilizing a self-hosted version of ZixEncrypt, Reflexion is able to offer secure message transfer from our clients to their mail recipients.  Zix's secure message network receives a securemail request from our servers, holds onto the message, and sends a notification to the recipient that they have a securemail waiting from the sender.  RTCEncrypt also offers Force TLS options on special request.  For more information on RTCEncrypt, please view this KB:

Please note: RTCEncrypt REQUIRES the use of the Reflexion smarthost.  In order to pass the mail off to Zix, we need to receive the outbound mail from the mail exchanger.

As usual, please feel free to contact support if there are any questions!

RFC2183 is an Attachment Filtering option within Reflexion Total Control.  If a message is tagged with the error message provided in your quarantine, this means that the message sent to or from you does not meet the standards listed out by the IETF.

What is RFC2183?
RFC2183 is an IETF memo for how to handle files transferred through email (aka, attachments).  The memo outlines standard and guidelines for how to handle these files, and how they should be encoded into the headers of the message.

This does provide a number of limitation in how messages are handled, including, but not limited, to:
Files created within a mail client instead of on a filesystem (read receipts, msg/eml files, e-contact cards)
Filenames that are not created within US-ASCII standards (no characters with tilde or umlaut)
Executable style files that are embedded directly into the message

For more information directly from the IETF, please visit the the below website:

This article will: describe advanced message filtering options

This article will not: Infer best practices.

Reflexion RTC offers a number of "advanced" options to further filter messages that pass through the spam filter.  These options can be used to limit exposure, prevent specific types of files from coming through, block regional IPs, and more.  Read on for further information.

Permitted Languages:

The Permitted Languages feature allows the blocking of categories of languages and alphabet types.  If users are receiving spam messages in foreign languages or alphabets, these settings can be used to prevent their delivery.  Alternatively, if a client should only be receiving messages in English (or its relatives), then all languages other than "Western European" family can be blocked.  This can be applied to individual users, or on the Enterprise level

Permitted Countries:

Permitted Countries allows for blocking of messages from specific regional IP bands.  This option does NOT check to see who owns the IP, only WHERE the IP is registered.  This can have adverse effects on organizations that have international datacenters (O365, GSuites), but will block IPs owned/registered by the specified countries' IP registrar.  This option will not block messages from country specific top tier domains; please use the block list feature to block the domain name.  Permitted Countries can be applied to individual users, or on the Enterprise level.  Reflexion services use the IP2Location Geo-location services.  To confirm where an IP is registered, please use the Demo on the ip2location website:

Subject Filtering:

The subject filtering option will search subject lines of messages for a matching string.  The entry is not case sensitive, and will is not looking for an exact match.  This means that if the subject entry is just "milf" then "Milford" will be flagged as a subject violation.  The entries will accept spaces before and after the entry to help expand the match criteria, and not flag Milford as a subject violation.  Subject Filtering can be applied to individual users, or on the Enterprise level.

Attachment Filtering:

The attachment filtering rules are designed to build a "do not deliver" list for specific file types.  The entries on this page WILL overrule the Allow List.

Sub options:

Block executable files (...) within compressed files:  This option will check compressed files for various types of executable files, as long as the compressed archive is not password protected.

Block messages with attachments that violate RFC2183:  This option checks the attachments of a message to ensure that they are RFC2183  RFC2183 is more deeply explained on this KB:

Block all files containing macros:  This option is as described.  If there is a macro embedded into the attachment itself, this option will quarantine the message.  This option does NOT execute URLs or links within attachments, and will only check to see if the macro is embedded into the encoding of the attachment.

IP Filtering:

While Reflexion does maintain subscriptions to various IP blacklists, the IP Filtering option allows you to set up your own IP based blocking.  Creating a new entry will allow you to add individual IPs or specified subnets, and also specify if you want to Allow the entry, or block it as spam.

This article will: provide basic information on the Reflexion RTCEncrypt product.

This article will not: cover configuration

Reflexion offers a paid stand-alone service called "RTCEncrypt" to all clients.  RTCEncrypt is a securemail processing system that uses a self-hosted ZixMail cluster to securely process and protect email content.  Email is not inherently secure, so RTCEncrypt helps clients make their email communication compliant.  This works by Reflexion receiving the outbound message, processing it in our Zix cluster, and sending a separate email notification to the recipient informing them they have a secure message waiting.

RTCEncrypt is triggered based on:

  • Subject line
  • Content scanning
  • Marking a message as "confidential" in mail client

During the Configuration of RTCEncrypt, different policies can be selected, covering (US) SSNs, HIPAA, (US) state privacy, and other types of Personal Identity Information.  These policies will be run over an email that passes through the RTCEncrypt server, and if one piece of content in the email triggers the policy, the email is automatically encrypted.  The Content triggers will also parse through any attachments, unless the attachment is password protected.

Also during the configuration, one Force Trigger can be selected.  If this trigger is put into the front of the subject line, the message will also be encrypted even if there are no policy triggers in the content of the email.

Finally, if a user marks a message as "Confidential" in their mail client, RTCEncrypt will see the tag in the headers and also encrypt the message.

As stated above, our Zix cluster will receive the messages sent to our smarthost.  When the message is processed and determined to require encryption, the message is forwarded to a secure holding server and a notification is sent to the recipient.  The notification will inform the recipient who the message is from and ask them to log into the ZixSecure panel to access and reply to the message.

If a recipient cannot receive or open "notification" type emails, RTCEncrypt can also be configured to send as ForceTLS.  Please contact support for assistance in configuring ForceTLS.


  • Sending outbound mail through the Reflexion Smarthost
  • Configuring Zixvpm MX records for the client's domain.

Please note that users do NOT need to have RTC Enabled in order to use RTCEncrypt: this is a stand-alone product service.

When it comes down to adding allow entries for bulk/marketing mail providers, it can be tricky to nail down the specifics of what needs to be added to the list.  Thankfully, Salesforce makes this very simple!

Each Salesforce tenant has a dedicated subdomain, and a portion of their domain name that changes with every marketing blast sent.  Lets take a look at this example:

A lot going on there.  However, Salesforce's formula for creating these subdomains for their tenants makes it easy to break this down:  Salesforce has numerous server farms, and breaks them down into regions.  This specific tenant is on the "na52" server cluster.  This tenant's specific subdomain on this cluster is "d-hd8veae."  Everything in front of the "d-" portion will change with every campaign/mailblast sent.  With this information, you can add the following subdomain to make sure that everything from this specific tenant is accepted:

Please note that this only applies to this specific example!  You will need to check the Reports pages to confirm what server cluster your sender is a member of, and then use the next portion of the subdomain to identify the specific tenant.  

As usual, please feel free to contact support if you have any questions on this process!

This article applies to all Enterprises that use our smarthost to send mail.
What this article will cover: What is SPF and how to add Reflexion's SPF information


Sender Policy Framework (SPF) is used to create an "allowed senders" list for email sent by your domain name.  The entries included in an SPF record can point to individual IPs, ranges of IPs, or even another domain's SPF record.  These are combined and used to tell recipients enforcing SPF checks what IPs are allowed to send email for your domain name.  The SPF record itself is placed in the TXT field in your DNS registry.  SPF Enforcement is optional on the recipient side; just because there is a hard fail record does not necessarily mean that a message from an improper source will be blocked.

Please use the record below as a starting point:
v=spf1 mx -all

While all environments are different and yours may require additional tokens, this baseline record will authorize Reflexion to send on behalf of your domain:

If you already have an SPF record set up for your domain, you can simply add the statement “” to the end of the SPF record, before the “all” token.

For example; if your current SPF record is this: v=spf1 -all

You would update it so that it reads as follows: v=spf1 -all

'all' Tokens:
The character in front of the all statement in your SPF record tells the server checking a message how to handle an out of range sender.  As stated before, the recipient server has the final decision on how to handle a message after the SPF check is run.
The "-all" token shown in the above examples indicates that any message from outside of the included ranges of IPs should be hard failed
The "~all" token indicates that any message not matching this SPF record should be "soft-failed" meaning that the recipient should record the error but not outright reject the incoming message. 
The "?all" token indicates that the SPF record is in place, but is not being used for handling messages.

For more in-depth information regarding SPF records please visit 

Any questions regarding implementation/deployment of the record should be directed to your ISP or DNS provider.  Reflexion does not have access to your DNS panel, and we will not perform these changes for you.


The Reflexion Quick Start Configuration Guide (attached below) features setup tips for the Reflexion Total Control (RTC), Archiving (RADAR and RADAR Lite), and Encryption (RTCEncrypt) services.

The guide is also available as a 7.5-minute video:

Basic Configuration Settings

MX Record Values           [Preference = 0]     [Preference = 100]     [Preference = 200]

Outbound Smart Host

Please modify your SMTP server to route all outbound mail through the following smart host:

Exchange Access Restriction Procedure

This will lock your server down to only accept SMTP connections from Reflexion IPs. Enforcing IP restrictions is absolutely critical to complete protection of your mail server. Because hackers and spammers can bypass cloud services and target your server directly, mail servers protected by Reflexion should only accept SMTP connections from Reflexion IPs listed below and deny all other traffic: (

Office 365 Access Restriction Procedure

For Office 365, you will need to use the following IPs: ( ( ( (

Subnets for LDAP on Ports 369 and 636 (

SPF Record

Although not essential, it can help make email delivery more reliable if you create an SPF record for your domain name. This DNS record is to comply with the Sender Policy Framework (SPF) anti-spam initiative. It identifies Reflexion servers as being approved for sending email from your domain.

 It's a TXT record, which not all DNS servers or ISP control panels can handle. But if yours can, this is the record to add:

v=spf1 mx ~all 

This is how it should appear in your DNS zone file.

Subdomains to use for optional encryption product

  1. Create the following sub-domain:

  2. Create the following MX records for the new sub-domain: MX preference = 10, mail exchanger = MX preference = 10, mail exchanger = MX preference = 10, mail exchanger =

  3. Repeat these steps for all enterprise domains requiring encryption.

Reflexion Total Control Best Practices

Reflexion: One-Minute Video - Address-on-the-Fly

Reflexion: One-Minute Video - Encryption

Reflexion: One-Minute Video - RTC Email Security


You get the the following error in Reflexion:

Send mail through your approved SMTP relay, or add a PTR record so the rDNS check more closely resembles their HELO name.

This error also occurs when there is an SPF record mismatch and the receiving server has a robust SPF checking rule.

The attached documents cover how email encryption works and how it would be enabled (Configured) 

If the SPAM handling option is set to "Quarantine" , email from blocked sender will be moved to quarantine folder by default.

If the user does not want to see any messages from their blocked senders, the option "Vaporize messages from senders on the block list instead of quarantining them" will need to be enabled on the respective user or Update Users page.

Please note, "Vaporize messages from senders on the block list instead of quarantining them" option will silently delete all email from all block listed sender and there is no way to recover vaporized emails.  

There is no method to directly differentiate between messages caught as spam, or blocked on the Reports page itself; you will need to click on a message other than where it says "Spam" to go to the Message History page.  If you click on a message from a blocked sender, the History Details page will show REASON: Sender was on a blacklist; message was vaporized.

Most popular articles 
Newest articles