MTA
Settings
CipherMail uses Postfix as its Mail Transfer Agent (MTA). The MTA is the component that sends, receives, and routes email.
Most common Postfix options can be configured in the MTA configuration page . Use this page for everyday tasks such as setting relay hosts, adjusting network and relay restrictions, and managing basic delivery behavior.
Advanced Postfix parameters that are not shown on the MTA configuration page can be managed from the MTA config page . This page is intended for experienced administrators who need fine‑grained control.
The next section describes the Postfix settings relevant to this product. For comprehensive information about all available Postfix options, see the official Postfix documentation at http://www.postfix.org/documentation.html.
My Host Name
My Host Name should be set to the fully qualified domain name (FQDN) of your mail server, for example: mail.example.com. This value is important because it is used in several places:
As the default domain added to email addresses that are sent without a domain.
As the SMTP HELO/EHLO name announced to other mail servers.
In message headers (for example, Received headers) and in system notifications such as bounce messages.
Recommendations and requirements:
Use a unique, stable host name that belongs to your domain (do not use the bare domain itself; prefer a host under it, such as mail.example.com rather than example.com).
Ensure the FQDN has correct DNS A/AAAA records pointing to your server’s IP address.
Ensure reverse DNS (PTR) for your server’s IP resolves back to the same FQDN.
If you use TLS certificates, the certificate’s common name (CN) or subject alternative name (SAN) should match this FQDN to avoid TLS warnings.
Use lowercase letters, no trailing dot, and avoid underscores.
If this value is incorrect or not fully qualified, other mail systems may refuse connections, flag your messages as suspicious, or you may see TLS name mismatch warnings.
How to determine the correct value:
Use the host name assigned by your DNS and systems administrator for this server.
Verify that the name resolves forward (A/AAAA) and reverse (PTR) to the same host.
In many Linux environments, hostname -f returns the current FQDN, but DNS should still be checked to confirm it is publicly resolvable.
For clustered setups, each node typically has its own FQDN. Use the node’s actual host FQDN for My Host Name unless your deployment documentation states otherwise.
Relay domains
Relay domains are the email domains that your mail server (MTA) is allowed to accept and handle messages for. In most organizations, this list includes only your own company domains - the ones where your users’ mailboxes live (for example, example.com and any approved subdomains). When an email arrives for a relay domain, the server accepts it and delivers it locally or forwards it to the correct internal system. Emails for domains that are not in the relay list are rejected to prevent misuse or accidental relaying. Only add a domain here if your organization is responsible for receiving mail for it.
Hint
In most deployments, you should configure at least one relay domain. The exception is when the gateway is used only to send email and does not receive incoming messages.
External Relay Host
This is the default next-hop server used to deliver email for any domain that is not configured as a relay domain. If you leave this field empty, email is routed using the domain’s DNS MX records.
Enter the destination as a host name or IP address followed by the port number,
for example: [external.example.com]:25
Internal Relay Host
The “Internal relay host” is the default next-hop destination for delivery to domains listed as relay domain. If left empty, email will be delivered using mx-records.The host name consists of the host name or ip number and the port number, like https://internal.example.com:25
The Internal relay host is the default next hop for messages sent to domains configured as relay domains. If you leave this field empty, messages will be delivered using DNS MX records.
Enter the destination as a host name or IP address followed by the port number,
for example: [internal.example.com]:25
Reject unverified recipient
If your mail server relays email for specific domains, it must verify recipients before accepting messages. In other words, the relay should know which email addresses actually exist on the downstream server. If the relay accepts messages for any address without checking whether the next hop will accept them, undeliverable mail may bounce later to the (often forged) sender address. This creates “backscatter”, which can damage your sending reputation, cause blacklisting, and waste system resources.
To prevent backscatter, configure the relay to reject unknown recipients during the SMTP session. Common ways to do this include synchronizing a list of valid recipients from the destination system, performing SMTP recipient verification (checking the RCPT TO response of the next server), or integrating with a directory service such as LDAP to validate addresses. Avoid using catch‑all mailboxes unless you explicitly need them.
A mail gateway can verify whether a recipient address exists before accepting an email. When the gateway receives a message for an address it has not seen before, it asks the next mail server in the delivery path if that address is valid. The gateway only accepts the message if the next server confirms the recipient exists.
To improve performance and reduce repeated lookups, the gateway temporarily stores (caches) the result of this check. While the result is cached, future emails to the same address are accepted or rejected immediately based on the stored outcome.
To enable recipient verification, enable “Reject unverified recipient”
For more information about address verification, visit the Postfix documentation at http://www.postfix.org/ADDRESS_VERIFICATION_README.html.
Tip
If the CipherMail gateway receives email from a mail server that has already validated the recipients, you do not need to enable this option.
Unverified Recipient Reject Code
To enable recipient verification, turn on “Reject unverified recipient.” The “Unverified Recipient Reject Code” controls the SMTP response sent when a message is refused. Start with code 450, which signals a temporary failure and prompts the sending server to try again later. After you confirm that verification is working correctly, you can change the code to 550 to indicate a permanent failure. With code 550, sending servers will stop retrying.
My Networks
To send email to external domains (domains not configured as relay domains), the
connecting SMTP server must have its IP address included in “My Networks”. Add
allowed networks in CIDR format, for example 192.168.1.1/32 or 10.1.2.0/24.
Caution
Only add IP ranges that you own and manage to “My Networks”. Adding unknown or external ranges can turn the gateway into an open relay, allowing others to send spam through it. This may lead to your IP addresses being blacklisted.
Message Size Limit
The maximum size of email which is accepted by the MTA.
Helo Name
Enter the hostname that your server will present in the SMTP HELO or EHLO command when connecting to other mail servers.
If left empty, the system uses the machine’s current hostname.
Recommended value: A fully qualified domain name (FQDN) that publicly resolves and ideally has a matching reverse DNS (PTR). Example: mail.example.com
IP literal: If you must use an IP address, enter it in SMTP literal form: [203.0.113.25] for IPv4, or [IPv6:2001:db8::1] for IPv6.
Using a valid, resolvable FQDN with matching reverse DNS improves deliverability and reduces the risk of your mail being flagged as spam.
Edit Main Config
The “MTA Settings” page allows you to configure the main MTA settings. Postfix settings for which there is no UI option, can be managed using the “MTA Config” page
Caution
Editing the main Postfix configuration file directly can render your mail server inoperable. Only change settings if you fully understand their effects. For a comprehensive list and explanation of all Postfix parameters, consult the postconf(5) documentation: https://www.postfix.org/postconf.5.html
Queues
MTA
The MTA Queue page shows all email messages currently in the Postfix mail queues. These include messages waiting to be handed off to the CipherMail back-end for processing (for example, applying policies or encryption) and messages waiting to be delivered to internal or external recipients. What you see is a live snapshot: the contents of the queue can change at any time as Postfix processes mail. Messages may appear, disappear, or update while you are viewing the list.
You can manage messages in the queue with the following actions:
Delete: Permanently remove the message from the queue. Use this for spam or messages that should never be delivered.
Bounce: Return the message to the sender with a non-delivery report (NDR).
Hold: Pause the message to prevent any further delivery attempts. Use this while investigating an issue. Release: Resume delivery attempts for a message that was previously placed on hold.
Requeue: Place the message back into the active queue to trigger a new delivery attempt. This is useful after fixing a temporary issue, such as a network or DNS problem.
Each message may show a queue ID, sender, recipients, size, arrival time, and an optional delay reason reported by Postfix. The number of queued items and their status can change rapidly on a busy system.
Flush Queue
Postfix automatically retries delivery of messages that are temporarily undeliverable. After the first failed attempt, it retries shortly thereafter. If multiple attempts fail, the time between retries gradually increases (this is normal “backoff” behavior). When the next hop is unreachable, for example due to a network outage, the queue can grow, and it may take some time for Postfix to clear the backlog once the issue is resolved. If you want to trigger immediate redelivery attempts for all queued messages, you can flush the queue .
Flushing does not guarantee delivery; it simply tells Postfix to try again right away using the current network and DNS conditions. If the underlying problem persists (such as a remote server still being down or DNS still failing), messages will remain queued and Postfix will continue its normal retry schedule.
Use Flush Queue after you have fixed a connectivity or configuration issue, or when you know the receiving system is available again and you want to expedite delivery.
Caution
On busy systems, emails may not be delivered immediately. Forcing a queue flush in this situation can worsen delays. Only flush the queue if messages were queued due to a temporary issue that has now been resolved.
Send Mail
Use the “Send Mail” action to send a test email from the user interface .
The following fields are supported:
- Subject
The Subject of the email.
- From
The from header for the email.
- Sender
The envelope sender of the email.
- Recipients
A comma-separated list of valid recipient email addresses (for example: alice@example.com, bob@example.org).
- Body Is MIME
When enabled, the email body is treated as a complete MIME-formatted message. This means the content you provide should already include its own MIME headers and structure, such as Content-Type, character encoding, multipart boundaries, and any attachments. Use this option if you are supplying a raw MIME message. If you are only sending plain text or HTML content without custom MIME parts, leave this option disabled.
- Body
The body of the email.
MPA
The MPA Queue page lists all email messages currently waiting to be processed by the Mail Processing Agent (MPA). The MPA handles tasks such as encryption, decryption, and other mail preparation steps. After processing, the MPA passes each message to the Mail Transfer Agent (MTA) for delivery to recipients.
Under normal conditions, the queue should remain small because messages move quickly from the MPA to the MTA.
A growing or consistently large queue may indicate that the MPA is temporarily busy, cannot keep up with the current volume, or is unable to deliver the mail to the MTA.
Repository
The Error repository stores messages that encountered a problem while being handled by MPA. Typical reasons include issues in the email template such as missing variables or invalid syntax.
You can manage messages in the Error repository in two ways:
Delete: Permanently remove the message if it is no longer needed. This is useful when the content is obsolete or the message should not be sent.
Requeue: Send the message back into the normal processing flow after you have fixed the underlying issue. For example, correct the template error or update the recipient address, then requeue the message so MPA can attempt delivery again.
Tip
Before requeuing, make sure the root cause has been resolved. Requeued messages will be processed as new attempts and can fail again if the problem persists.
Maps
Postfix uses map files to handle tasks such as access control, address rewriting, and content filtering. You can manage these maps from the MTA Maps page. To use a map in Postfix, reference the map file by its filename in the main configuration files (main.cf or master.cf).
A lookup table will be created in the directory /etc/postfix/maps.d/. The filename extension of the generated map file depends on the “Map type”. The full filename of the loopup table will be /etc/postfix/maps.d/MAP-TYPE.NAME.map.
The lookup table is created in /etc/postfix/maps.d/. The file extension is
determined by the selected map type. The resulting file follows the naming
pattern /etc/postfix/maps.d/MAP-TYPE.NAME.map, where MAP-TYPE is the chosen map
type and NAME is the table name.
The following map types are supported: btree, cidr, hash, pcre and regexp
The following default maps are available:
virtual-alias-maps
tls-policy
smtp-sasl-password_maps
check-recipient-access
transport-maps
spf.protection.outlook.com
gmail.com
Note
The default mapping files are referenced from Postfix main config (main.cf).
This is however not required. The Postfix main config can be modified to not
use the default provided mapping files.
virtual-alias-maps
Use virtual alias maps to configure forwarding for local email. Each mapping must use the following format:
<local-email> <foward-email>
- Example:
root tech@example.com
Hint
We recommend setting up an email forwarding rule for the root user to a mailbox that is monitored by an administrator.
tls-policy
The default Postfix client TLS policy uses opportunistic TLS. When sending email to external SMTP servers, Postfix will attempt to use TLS whenever the remote server supports it. In this mode, a TLS connection is established even if the remote server’s certificate cannot be validated. Although this does not fully authenticate the connection, encrypting the channel is still better than sending email without TLS.
Connecting to an SMTP server without TLS, or without verifying the server’s certificate, can expose you to man-in-the-middle attacks. To ensure connections are only established when they are trusted, configure an SMTP TLS policy for the relevant domain.
To set up a TLS policy for a domain, follow these steps:
Open the “TLS Policy Map” and select the tls-policy line
For every external domain for which a TLS policy should be configured, add a TLS policy line similar to:
example.com:25 verifySee below for an explanation of policy lines
Click Save to save the changes
Policy line
A TLS policy line defines how the system validates a TLS connection for a specific domain. The line follows this format:
<domain> <policy>
Where <domain> is the domain name of the external SMTP server and <policy> is the TLS policy to use.
Note
For comprehensive information about Postfix TLS policies, see the official Postfix TLS documentation: http://www.postfix.org/TLS_README.html
The domain is the fully qualified domain name (FQDN) of the external email domain. The policy applies whenever mail is sent to that domain, regardless of which MX host actually receives the message. If you enclose the name in square brackets (for example, [smtp.example.com]), the policy is used only when a connection is made to that exact hostname (i.e., connected to the A record)
Example:
Suppose the TLS policy is the following:
ciphermail.com verify [tls.example.com] verify match=alternative.com
And suppose the MX record for ciphermail.com is:
ciphermail.com IN MX 10 mail.ciphermail.com
And the following transport rule was added:
other.com smtp:[tls.example.com]
If an email is sent to info@ciphermail.com, the email will be delivered to mail.ciphermail.com only if the TLS certificate used by mail.ciphermail.com is trusted and has the correct domain domain name.
If an email is sent to info@other.com, the mail will be delivered to the SMTP server tls.example.com (because there was a transport rule). Because the TLS policy line for tls.example.com is surrounded by [], the explicit TLS policy for tls.example.com will be used. Because of the additional match rule, the TLS connection will only be established if the TLS certificate was issued to alternative.com.
smtp-sasl-password_maps
The SASL password mapping file contains a list of domains which require username/password authentication.
A line in the SASL mapping file should be configured as:
<domain> <username>:<password>
Where <domain> is the domain name of the external SMTP server,
<username> is the login name and <password> is the login password.
If you enclose the domain in square brackets (for example, [smtp.example.com]), the policy is used only when a connection is made to that exact hostname (i.e., connected to the A record)
Example
[smpt.example.com] test:notsosecretpassword
For more information on how to configure SASL for Postfix, see https://www.postfix.org/SASL_README.html
check-recipient-access
The check_recipient_access is a mapping from RCPT TO address to a corresponding action.
The access line must be formatted as follows:
<domain> <action>
Where <domain> is the recipient and <action> is the corresponding action.
Some of the supported actions are:
- REJECT optional text…
Reject the address etc. that matches the pattern. Reply with “$access_map_reject_code optional text…” when the optional text is specified, otherwise reply with a generic error response message.
- BCC user@domain
Send one copy of the message to the specified recipient.
If multiple BCC actions are specified within the same SMTP MAIL transaction, with Postfix 3.0 only the last action will be used.
This feature is available in Postfix 3.0 and later.
- PREPEND headername: headervalue
Prepend the specified message header to the message. When more than one PREPEND action executes, the first prepended header appears before the second etc. prepended header.
Note: this action must execute before the message content is received; it cannot execute in the context of smtpd_end_of_data_restrictions.
This feature is available in Postfix 2.1 and later.
For more details on the access table format and an overview of all actions see https://www.postfix.org/access.5.html
transport-maps
A transport map is a simple lookup table that tells the system which delivery method and next-hop server to use for specific recipients or domains. It overrides the default routing so that messages can be sent through different servers based on the recipient address. Use a transport map when email for a particular domain should not follow the general “Internal” or “External” Relay Host setting.
For example, if most outbound mail is sent via your main relay but messages for example.org must go to a partner’s gateway at mail.partner.example, you can add a mapping from example.org to that server. The system will then route only those messages through the specified next hop, while all other mail continues to use the default relay.
Key points:
You can map entire domains or individual addresses to a specific transport and next-hop server.
Transport map rules take precedence over the default outbound relay configuration.
If no transport map entry matches, the system uses the standard “External Relay Host” settings.
This is useful for special routing needs such as partner integrations, departmental gateways, compliance appliances, or testing environments.
A transport mapping should be formatted as follows:
<pattern> <next-hop>
Where <pattern> is an email address or domain and <next-hop> is the mail server.
Examples:
abuse@partner.example.com [abuse.smtp.example.com]:1234 partner.example.com [tls.smtp.example.com]email to abuse@partner.example.com will be delivered to
abuse.smtp.example.comon port 1234 and all other email to partner.example.com will be delivered totls.smtp.example.comon port 25.
For more details on the transport table format https://www.postfix.org/transport.5.html
spf.protection.outlook.com
This lookup table is automatically kept up to date with the IP ranges that
Office 365 uses to send email. It refreshes once per day by retrieving the SPF
record for spf.protection.outlook.com.
The table is used to integrate the CipherMail gateway with Office 365. For more details, see the Office 365 integration guide Office 365 Integration Guide: Introduction
gmail.com
This lookup table is automatically kept up to date with the IP ranges that
Google Workspace uses to send email. It refreshes once per day by retrieving the SPF
record for gmail.com.
The table is used to integrate the CipherMail gateway with Google Workspace. For more details, see the Google Workspace integration guide Google Workspace Integration Guide: Introduction