Cleanbox
Features Helpdesk Blog Pricing Contact
Sign in Start free trial
Helpdesk Relay

Relay token configuration - prevent bypass and enforce on your server

When you use Relay, Cleanbox filters inbound email before forwarding it to your mail server. But unless you configure your server to only accept email that came through Cleanbox, anyone who knows your server's IP address or hostname can bypass the relay entirely — delivering email directly to your server, skipping all spam filtering, virus scanning, and Shield protection.

The verification token prevents this.

How the token works

Every Relay configuration has a unique verification token — a 64-character hex string generated automatically when you set up Relay. When Cleanbox forwards a filtered email to your mail server, it injects a header:

X-Cleanbox-Validation: your-token-here

You configure your mail server to reject any inbound email that does not contain this header with the correct value. Email without the header (not routed through Cleanbox) is rejected. Email with the header (routed through Cleanbox and filtered) is accepted.

Where to find your token

  1. Go to Relay in the Cleanbox dashboard
  2. Select your relay domain
  3. Click the Token tab
  4. Copy the token value and the full header line

The token looks like: a1b2c3d4e5f6...64 characters

What happens without the token

If you do not configure token verification, Relay still works — Cleanbox still filters and forwards your email. But your server accepts email from any source. Spammers can bypass Cleanbox by connecting directly to your server's IP address on port 25.

For maximum protection, configure both:

  • MX records pointing to Cleanbox (so legitimate email is routed through Cleanbox)
  • Token verification on your mail server (so direct connections are rejected)

Exim

Exim is the default MTA on servers running cPanel, WHM, and many Debian-based systems. The verification check is added as an ACL (Access Control List) rule.

Locate your configuration

  • /etc/exim4/exim4.conf (Debian/Ubuntu)
  • /etc/exim.conf (CentOS/RHEL)
  • /etc/exim4/conf.d/ (split configuration on Debian)

On cPanel/WHM servers, do not edit the config directly — it gets overwritten. Use WHM → Service Configuration → Exim Configuration Manager → Advanced Editor. Find the custom ACL section for acl_check_data.

Add the ACL rule

Add this to the acl_check_data section:

# Reject email that did not pass through Cleanbox Relay
deny
  message   = 550 Rejected: email must be routed through Cleanbox Relay
  condition = ${if !eq{$h_X-Cleanbox-Validation:}{YOUR_TOKEN_HERE}}
  recipients = *@yourdomain.com

Replace YOUR_TOKEN_HERE with your actual token and yourdomain.com with your relay-protected domain.

Multiple domains

If you protect multiple domains (each with its own token), use separate deny rules:

deny
  message   = 550 Rejected: email must be routed through Cleanbox Relay
  condition = ${if !eq{$h_X-Cleanbox-Validation:}{TOKEN_FOR_DOMAIN1}}
  recipients = *@domain1.com

deny
  message   = 550 Rejected: email must be routed through Cleanbox Relay
  condition = ${if !eq{$h_X-Cleanbox-Validation:}{TOKEN_FOR_DOMAIN2}}
  recipients = *@domain2.com

Test and restart

# Verify configuration syntax
exim -bV

# Restart Exim
systemctl restart exim

# On cPanel servers
/scripts/restartsrv_exim

Exim notes

  • The acl_check_data ACL runs after the message body is received, so headers are available for inspection.
  • On cPanel, always use the WHM Exim Configuration Manager. Direct edits to /etc/exim.conf are overwritten.
  • The recipients condition ensures the rule only applies to your relay-protected domains. Email to other domains on the same server is not affected.
  • For Exim split configuration (Debian), add the rule to /etc/exim4/conf.d/acl/40_local_check_data.

Postfix

Postfix is the default MTA on Ubuntu and many Linux distributions.

Header checks approach

Create /etc/postfix/cleanbox_header_check:

# Allow emails with valid Cleanbox verification token
/^X-Cleanbox-Validation: YOUR_TOKEN_HERE$/ OK

# Reject emails with an incorrect token value
/^X-Cleanbox-Validation:/ REJECT Email must be routed through Cleanbox Relay

Enable it in /etc/postfix/main.cf:

header_checks = regexp:/etc/postfix/cleanbox_header_check

Reload Postfix:

postfix check && postfix reload

Limitation: Header checks can only act on headers that exist. An email entirely without the X-Cleanbox-Validation header will not match either rule and will be accepted. For full enforcement, combine with the firewall approach below.

Firewall approach (recommended addition)

Since all legitimate email now comes through Cleanbox, restrict port 25 to only accept connections from Cleanbox's relay servers:

# Using iptables
iptables -A INPUT -p tcp --dport 25 -s CLEANBOX_IP_1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -s CLEANBOX_IP_2 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j REJECT

# Using ufw (Ubuntu)
ufw allow from CLEANBOX_IP_1 to any port 25
ufw allow from CLEANBOX_IP_2 to any port 25
ufw deny 25

This blocks connections at the network level — the email never reaches Postfix. The downside is that you need to update rules if Cleanbox's IPs change. The best practice is to use both: firewall as primary defense, header check as secondary.

Dovecot (via Sieve)

Dovecot is not an MTA — it handles delivery and IMAP. But if your setup uses Dovecot's LDA or LMTP with Sieve filtering, you can add a token check at delivery time as an additional layer.

Enable Sieve

In /etc/dovecot/conf.d/90-sieve.conf:

plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /etc/dovecot/sieve-before.d/
}

The sieve_before directive runs scripts before user-level rules, ensuring the check cannot be bypassed.

Create the Sieve script

Create /etc/dovecot/sieve-before.d/cleanbox-validation.sieve:

require ["header", "reject"];

# Reject emails without valid Cleanbox token
if not header :is "X-Cleanbox-Validation" "YOUR_TOKEN_HERE" {
  reject "Email must be routed through Cleanbox Relay";
  stop;
}

For specific domains only

require ["header", "reject", "envelope"];

if envelope :domain "to" "yourdomain.com" {
  if not header :is "X-Cleanbox-Validation" "YOUR_TOKEN_HERE" {
    reject "Email must be routed through Cleanbox Relay";
    stop;
  }
}

Compile and restart

sievec /etc/dovecot/sieve-before.d/cleanbox-validation.sieve
systemctl restart dovecot

Dovecot notes

  • Sieve runs at delivery time, not SMTP reception. The email was already accepted by your MTA. The sending server gets a success response, but the email is rejected during delivery. For an immediate SMTP-level bounce, configure the check in Exim or Postfix instead.
  • If you use Dovecot with Postfix, configure the primary check in Postfix and use the Sieve check as a safety net.
  • sieve_before ensures users cannot override the check with personal rules.

Testing your configuration

  1. Test normal delivery: Send an email to your relay-protected address from an external account. It should arrive normally through Cleanbox.
  2. Test direct bypass: Connect directly to your server on port 25 and try to deliver without the header:
telnet your-server-ip 25
EHLO test
MAIL FROM:<test@example.com>
RCPT TO:<you@yourdomain.com>
DATA
Subject: Direct bypass test

This should be rejected.
.
QUIT

Your server should respond with the rejection message after the DATA phase (Exim/Postfix) or after the delivery attempt (Dovecot).

Regenerating the token

When you regenerate the token in Cleanbox (Relay → Token → Regenerate):

  1. Copy the new token immediately
  2. Update your mail server configuration
  3. Restart/reload the service

Do this quickly. Between regeneration and updating your server, emails forwarded by Cleanbox carry the new token but your server still expects the old one — causing temporary rejections. Prepare the new config in advance to minimize downtime.