SMTP Restrictions automatically disables after enabling – affecting all 5 cPanel servers on 138.0

am experiencing the same issue on all 5 of my cPanel/WHM servers.

Environment

cPanel & WHM: 138.0 (build 7)
OS: AlmaLinux 9.x
Imunify360: installed
CSF: NOT installed
This issue started after upgrading the servers to cPanel version 138.
The behavior is identical across all 5 servers.

Problem

When I go to:

WHM → Security Center → SMTP Restrictions

and click Enable, the feature appears to enable successfully.

However, after approximately one minute, it automatically returns to:

Disabled

As a result, smtpmailgidonly is changed/returned to:

smtpmailgidonly=0

I have verified this directly with:

grep -n '^smtpmailgidonly=' /var/cpanel/cpanel.config

which returns:

267:smtpmailgidonly=0

This happens consistently on all 5 servers.

Important impact

When SMTP Restrictions is disabled, websites/scripts on the servers are unable to operate as intended with the SMTP restrictions configuration.

This is a server-wide issue and is not isolated to a particular cPanel account or WordPress installation.

Troubleshooting already performed

Verified the cPanel configuration:

/var/cpanel/cpanel.config

and confirmed:

smtpmailgidonly=0

Checked the SMTP Tweak systemd service:

systemctl status smtpmailgidonly.service --no-pager

The service is:

smtpmailgidonly.service - SMTP Tweak
Loaded: /etc/systemd/system/smtpmailgidonly.service
Active: inactive (dead)

It is not running because the following condition is not met:

ConditionPathExists=/var/cpanel/smtpgidonlytweak

Ran:

/usr/local/cpanel/scripts/check_cpanel_pkgs --fix

It completed with no output or reported errors.

Checked /usr/local/cpanel/logs/error_log.

There are entries related to installation of the smtpmailgidonly.service, but no clear error indicating why SMTP Restrictions is being disabled.

Checked the cPanel access log and confirmed that the WHM SMTP Restrictions Enable action is being received.
We also observed nftables.service failures on the server with errors related to unsupported xtables compatibility expressions, including rules involving Imunify360.

However, we are aware of cPanel issue CPANEL-46555, which was marked as fixed:

"Fix SMTP restriction firewall rules on AlmaLinux 9 and CloudLinux 9 to use native nftables syntax, preventing nftables service failure on reboot."

Therefore, we do not want to assume that CPANEL-46555 is the cause without further investigation.

Imunify360 is installed, but Imunify360 SMTP Traffic Management is disabled.
CSF is not installed, so there should be no CSF SMTP_BLOCK conflict.

Audit investigation

We added an audit watch to:

/var/cpanel/cpanel.config

using:

auditctl -w /var/cpanel/cpanel.config -p wa -k cpanel_config_watch

The audit confirmed that cPanel processes access the configuration file.

We also captured an event involving:

whostmgr12

accessing /var/cpanel/cpanel.config immediately after the SMTP Restrictions operation.

However, the captured event only showed an openat operation with O_RDWR; it did not provide evidence of a write or truncate operation.

Therefore, we have not yet identified which process is actually changing:

smtpmailgidonly=1

back to:

smtpmailgidonly=0

What we need from cPanel

Because the exact same behavior started after upgrading to cPanel 138 and occurs on all 5 of our servers, we suspect a cPanel-level issue rather than an individual server configuration problem.

Could you please investigate:

Why SMTP Restrictions automatically changes from Enabled to Disabled approximately one minute after being enabled.
What process is setting smtpmailgidonly=0.
Whether there is a known issue in cPanel 138.0 build 7 related to SMTP Restrictions.
Whether this is related to the native nftables changes introduced/fixed under CPANEL-46555.
Whether there are known interactions between cPanel 138 SMTP Restrictions and Imunify360 on AlmaLinux 9.
Whether there is a recommended patch, update, or workaround.

The fact that this happens identically on all 5 servers strongly suggests that the issue may be related to the cPanel 138 code/configuration rather than a single-server configuration.

We can provide full logs and run additional diagnostic commands if required.

Please let us know which diagnostics you would like us to collect while the issue is occurring.

Thank you.

cPRex Jurassic Moderator

September 16, 2026 16:18

Hey there! Thanks for bringing this up. I was able to confirm the behavior and I've created case CPANEL-56968 for our developers to look into this. I've also linked this thread to the case so I'll be sure to post any updates once I hear something on my end.

Pathfinder

September 17, 2026 19:20

I just noticed the same issue on 2 servers that were updated this morning. The smtp restriction is disabled, I enable it then run the security Advisor again and it shows disabled.

Adam

September 21, 2026 17:55

I'm seeing the same. It seems in my case:

cPanel's SMTP script is failing because /etc/sysconfig/nftables.conf contains Imunify360-generated xt match "set" compatibility rules that the native nft loader cannot reload.

The missing SMTP marker file and inactive service are consequences, not the root problem.

What is happening

Imunify360 installs working firewall rules through iptables-nft.
cPanel's SMTP script exports the complete active ruleset into /etc/sysconfig/nftables.conf.
That export includes Imunify360 compatibility expressions such as:

xt match "set"

cPanel then runs:

systemctl restart nftables

Native nft cannot reload those compatibility expressions.
The restart fails, so cPanel rolls SMTP Restrictions back to disabled.

My understanding is that Imunify360 SMTP Traffic Management is separately managed from WHM SMTP Restrictions and can restrict outbound SMTP connections, with whitelist support for users that require direct SMTP access. (WHM > Plugins > Imunify360 > Settings > SMTP Traffic Management)

So it seems the solution may be to use that functionality instead?

September 22, 2026 17:52

Adam - while there is a separate issue with nftables, it seems this is a unique problem so I created a separate case for it.