DEV Community

Cover image for Understanding cPanel SMTP Restrictions: Security, External SMTP, and the Trade-Offs
Mohammed AlShannaq
Mohammed AlShannaq

Posted on

Understanding cPanel SMTP Restrictions: Security, External SMTP, and the Trade-Offs

#cpanel #linux

A cPanel setting called:

Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)

looks simple.

You either enable it or disable it.

In practice, however, the decision can affect application compatibility, email abuse controls, troubleshooting, and the way hosted applications connect to external email services such as Microsoft 365, Gmail or any other External SMTP.

I am not arguing in this article that the setting should always be enabled or always be disabled.

The aim is simpler:

  • explain what the setting actually does;
  • show a legitimate application scenario that can fail because of it;
  • explain why the failure can be confusing;
  • present the security argument for enabling it;
  • present the compatibility argument for disabling it;
  • and provide a practical troubleshooting method.

The correct decision depends on the hosting environment, the operator's security model, and the needs of hosted applications.

What does the setting do?

According to cPanel's official documentation, SMTP Restrictions can configure the server so that only:

  • the mail transport agent (MTA);
  • Mailman;
  • and the root user

can connect to remote SMTP servers.

Other users and services are denied the ability to bypass the local mail server and send mail directly through remote SMTP systems.

cPanel describes this bypass behaviour as something commonly used by spammers.

Official documentation:

https://docs.cpanel.net/whm/security-center/smtp-restrictions/

In simplified form, with the restriction enabled, an application running under a normal hosting user may not be allowed to connect directly to a remote SMTP endpoint on a restricted SMTP path.

The intended security model is roughly:

Hosted application
       |
       | SMTP connection
       v
Local Exim server
       |
       v
Remote destination
Enter fullscreen mode Exit fullscreen mode

rather than:

Hosted application
       |
       | direct SMTP connection
       v
External SMTP server
Enter fullscreen mode Exit fullscreen mode

That distinction is the centre of the whole discussion.

The legitimate application case

Consider a PHP application that uses PHPMailer:

$mail->isSMTP();
$mail->Host = 'smtp.office365.com';
$mail->SMTPAuth = true;
$mail->Port = 587;
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
Enter fullscreen mode Exit fullscreen mode

There is nothing inherently suspicious about this configuration.

The application may belong to a company whose email service is hosted on Microsoft 365. The developer may intentionally want the application to submit mail through Microsoft rather than through the hosting server's local Exim service.

The expected path is:

PHP application
      |
      | STARTTLS + SMTP AUTH
      v
smtp.office365.com:587
      |
      v
Microsoft 365
      |
      v
Recipient
Enter fullscreen mode Exit fullscreen mode

This pattern is common in modern applications.

Similar designs can exist with:

  • PHPMailer;
  • Laravel mail;
  • Symfony Mailer;
  • WordPress SMTP plugins;
  • Nodemailer;
  • Google Workspace;
  • transactional email providers;
  • and other authenticated SMTP services.

So the important distinction is this:

Direct external SMTP is not automatically malicious. It can be a deliberate application architecture.

The surprising failure mode

When administrators think about a blocked outbound connection, they often expect:

Connection timed out
Enter fullscreen mode Exit fullscreen mode

or:

Connection refused
Enter fullscreen mode Exit fullscreen mode

But SMTP restrictions can produce a much more confusing symptom.

An application may attempt to connect to:

smtp.office365.com:587
Enter fullscreen mode Exit fullscreen mode

and then fail with an error similar to:

Peer certificate CN=local-server.example.com
did not match expected CN=smtp.office365.com
Enter fullscreen mode Exit fullscreen mode

At first sight, this looks like:

  • a Microsoft 365 problem;
  • a STARTTLS problem;
  • a broken certificate chain;
  • a DNS problem;
  • a firewall problem;
  • a WAF problem;
  • or an application library bug.

But another possibility is that the connection is not reaching the expected external SMTP endpoint.

Instead, the SMTP connection may be handled by the local mail service.

The effective path can become:

Application
    |
    | tries smtp.office365.com:587
    v
Local SMTP restriction behaviour
    |
    v
Local Exim service
    |
    v
Local server certificate
Enter fullscreen mode Exit fullscreen mode

The application expects the identity of smtp.office365.com, but receives the identity of the local server.

The TLS hostname check then fails correctly.

A controlled troubleshooting method

The following method can help distinguish:

  • provider-level network blocking;
  • a general server connectivity problem;
  • and user-level SMTP restriction behaviour.

Do not send any email during these tests.

The goal is only to inspect connectivity, SMTP banners, and TLS identity.

Test 1: connect as root

Run:

openssl s_client \
  -starttls smtp \
  -connect smtp.office365.com:587 \
  -servername smtp.office365.com \
  -crlf
Enter fullscreen mode Exit fullscreen mode

If the connection reaches Microsoft, the output should show a certificate chain and SMTP service associated with Microsoft rather than the local hosting server.

This proves that the server itself has a route to the external SMTP service.

However, this test alone is not enough.

A restriction may treat root differently from normal hosting users.

Test 2: connect as the hosting user

Run the same test under the relevant Linux or cPanel user:

sudo -u exampleuser openssl s_client \
  -starttls smtp \
  -connect smtp.office365.com:587 \
  -servername smtp.office365.com \
  -crlf
Enter fullscreen mode Exit fullscreen mode

Now compare the result.

A useful diagnostic pattern is:

As root:
→ Microsoft certificate

As hosting user:
→ local server certificate
Enter fullscreen mode Exit fullscreen mode

That strongly suggests that the behaviour depends on the user context rather than on general network reachability.

Test 3: test from PHP under the same user

A minimal PHP script can test the actual application context without authentication and without sending a message:

<?php

declare(strict_types=1);

$host = 'smtp.office365.com';
$port = 587;
$timeout = 10;

$errno = 0;
$errstr = '';

$socket = stream_socket_client(
    "tcp://{$host}:{$port}",
    $errno,
    $errstr,
    $timeout,
    STREAM_CLIENT_CONNECT
);

if ($socket === false) {
    fwrite(STDERR, "TCP connection failed\n");
    fwrite(STDERR, "Error {$errno}: {$errstr}\n");
    exit(1);
}

stream_set_timeout($socket, $timeout);

echo "TCP connection established\n";

$banner = fgets($socket);

if ($banner === false) {
    fwrite(STDERR, "Connected, but no SMTP banner was received\n");
    fclose($socket);
    exit(1);
}

echo "SMTP banner:\n";
echo trim($banner) . PHP_EOL;

fwrite($socket, "EHLO test.local\r\n");

echo "\nEHLO response:\n";

while (($line = fgets($socket)) !== false) {
    echo trim($line) . PHP_EOL;

    if (preg_match('/^250\s/', $line) === 1) {
        break;
    }
}

fwrite($socket, "QUIT\r\n");
fclose($socket);

echo "\nConnection closed without authentication or sending email\n";
Enter fullscreen mode Exit fullscreen mode

Run it under the hosting user:

sudo -u exampleuser php /tmp/test-smtp-587.php
Enter fullscreen mode Exit fullscreen mode

No SMTP authentication is performed.

No MAIL FROM command is sent.

No RCPT TO command is sent.

No message body is transmitted.

The script only:

  1. opens a TCP connection;
  2. reads the SMTP banner;
  3. sends EHLO;
  4. reads the capabilities;
  5. sends QUIT.

If the application asks for smtp.office365.com:587 but receives a banner from the local Exim server, the behaviour becomes much easier to understand.

The value of an A/B test

Where operationally safe and authorised, an administrator can compare behaviour before and after changing the SMTP Restrictions setting.

A simplified result may look like this:

Restrictions ON
→ hosting-user PHP process
→ local Exim banner
Enter fullscreen mode Exit fullscreen mode

Then:

Restrictions OFF
→ same hosting-user PHP process
→ Microsoft 365 SMTP banner
Enter fullscreen mode Exit fullscreen mode

This is much stronger evidence than guessing from an application error message.

The important point is not that every cPanel server will behave identically.

The important point is that testing should be done:

  • from the same server;
  • under the same user;
  • using the same destination;
  • and ideally from the same application runtime.

The argument for keeping SMTP Restrictions enabled

There is a strong and legitimate security argument for enabling the feature.

1. Centralised control

If applications cannot bypass the local MTA on the restricted SMTP paths, the hosting operator has a more centralised mail architecture.

Mail that passes through Exim can be subject to local controls such as:

  • logging;
  • queue inspection;
  • delivery reporting;
  • local policy;
  • rate limits;
  • and abuse investigation.

2. Reduced ability to bypass the local MTA

A compromised script may otherwise attempt to connect to an external SMTP system.

With the restriction enabled, the operator reduces the ability of ordinary user processes to bypass the local mail server on the restricted paths.

This is the core rationale described by cPanel.

3. Easier investigation when mail uses Exim

When mail passes through the local MTA, the operator may have better evidence in:

  • Exim logs;
  • queue data;
  • delivery reports;
  • and local sending statistics.

A 2022 cPanel Community discussion presents exactly this concern. A moderator points back to cPanel's security rationale, while another community participant argues that keeping all outgoing mail through Exim makes spam activity easier to notice and trace.

Community discussion:

https://support.cpanel.net/hc/en-us/community/posts/19161442634903-Restrict-outgoing-SMTP-why-is-bad-to-allow

These are valid operational concerns.

The argument for disabling SMTP Restrictions

There is also a legitimate compatibility and application-design argument for disabling the feature.

1. Modern applications often use external email services

A hosted application may intentionally use:

smtp.office365.com
Enter fullscreen mode Exit fullscreen mode

rather than:

localhost
Enter fullscreen mode Exit fullscreen mode

The organisation may have already chosen Microsoft 365, Google Workspace, or another provider for its email architecture.

Forcing the application through the hosting server's local Exim service may not match the intended design.

2. Legitimate application SMTP can fail

The restriction can interfere with applications that expect a direct external SMTP submission path.

The resulting problem may be especially confusing when the application receives the local server's TLS certificate instead of the external provider's certificate.

3. The setting is not an absolute ban on every possible external SMTP design

A 2025 cPanel Community discussion examined PHPMailer using SMTP2Go on port 2525.

Participants discussed that SMTP Restrictions affect standard SMTP ports such as 25, 465, and 587, while a custom port such as 2525 may continue to work if allowed by the firewall.

A cPanel moderator noted that a custom port may mean the SMTP Restrictions do not apply in that case.

Community discussion:

https://support.cpanel.net/hc/en-us/community/posts/34506598182295-SMTP-Restrictions-and-External-SMTP-providers

This is an important nuance.

It suggests that the setting should not be described as a complete boundary against every possible external SMTP connection.

4. cPanel officially documents disabling the feature for scripts that need to bypass Exim

This is one of the most important points in the discussion.

A cPanel support article updated on 22 May 2026 states that SMTP Restrictions help reduce outbound spam by forcing SMTP connections through local Exim.

It then explains that if a script needs to bypass Exim when sending messages, the feature may need to be disabled.

Official cPanel support article:

https://support.cpanel.net/hc/en-us/articles/1500009931961-How-to-disable-SMTP-Restrictions

This does not mean cPanel recommends disabling the setting everywhere.

It does show that bypassing Exim can be a recognised operational requirement rather than an inherently invalid configuration.

Does disabling the setting break Exim logging?

This question deserves a direct answer.

Disabling SMTP Restrictions does not, by itself, mean that Exim stops logging mail that actually passes through Exim.

Consider two paths.

Path A: the application still uses local Exim 

Application
    |
    v
Local Exim
    |
    v
Remote recipient
Enter fullscreen mode Exit fullscreen mode

This mail still passes through the local MTA.

The normal Exim logging, queueing, and reporting model continues to apply to that mail.

Path B: the application intentionally uses an external SMTP provider 

Application
    |
    v
smtp.office365.com
    |
    v
Microsoft 365
    |
    v
Recipient
Enter fullscreen mode Exit fullscreen mode

This mail does not pass through local Exim.

Therefore, it is not expected to appear in local Exim logs.

That is not the same as "Exim logging has stopped working".

It means the application selected another SMTP provider.

The operational question is therefore:

Does the hosting operator require visibility and control over all application SMTP traffic, or only over mail that uses the operator's own mail infrastructure?

Different hosting providers may answer that question differently.

Direct-to-MX delivery and authenticated submission are not the same thing

A useful security discussion should distinguish different SMTP patterns.

Direct-to-MX delivery 

Compromised process
      |
      v
Recipient MX on port 25
Enter fullscreen mode Exit fullscreen mode

In this case, the hosting server's IP may be the direct SMTP source seen by the recipient's mail infrastructure.

This can create a clear IP reputation risk.

Authenticated SMTP submission 

Application
      |
      v
External provider on port 587
      |
      | SMTP AUTH
      v
Provider infrastructure
      |
      v
Recipient
Enter fullscreen mode Exit fullscreen mode

Here, the hosting server is the source of the submission connection, but the external provider normally performs final delivery.

The provider may apply:

  • authentication;
  • tenant policy;
  • rate limits;
  • anti-abuse controls;
  • reputation controls;
  • and account suspension.

This does not make abuse impossible.

It does mean that the risk model is different from a process directly delivering spam to recipient MX servers.

External provider on a custom port 

Application
      |
      v
External relay on port 2525
Enter fullscreen mode Exit fullscreen mode

This is yet another model, and the 2025 cPanel Community discussion shows why port-specific behaviour matters.

Treating every form of "external SMTP" as identical can hide important technical differences.

What are the real risks of disabling the restriction?

A neutral assessment should acknowledge the risks clearly.

1. User processes can bypass local Exim

This is the central and intended effect.

An application can use another SMTP provider instead of the local MTA.

2. External SMTP traffic is not visible in Exim logs

If a message never passes through Exim, Exim cannot log its message transaction.

Investigation may require:

  • network telemetry;
  • process information;
  • firewall logs;
  • endpoint security data;
  • or evidence from the external provider.

3. A compromised site may use external SMTP credentials

Applications often store service credentials in configuration files or environment variables.

If a site is compromised, an attacker may try to misuse those credentials.

This is not unique to SMTP, but direct external SMTP connectivity can make such misuse possible from the compromised environment.

4. The server IP is still visible as the connection source

Even when the external provider performs final delivery, it can see the IP address that initiated the SMTP submission connection.

Abusive activity may therefore lead to:

  • provider-side blocking;
  • investigation;
  • or abuse complaints.

5. Local Exim limits do not control third-party SMTP traffic

If the application bypasses Exim, local Exim limits are not the enforcement point for that external SMTP transaction.

The external provider's controls become relevant instead.

What disabling the restriction does not automatically mean

It is equally important not to exaggerate.

Disabling SMTP Restrictions does not automatically mean:

  • Exim logging stops working;
  • local mail becomes untraceable;
  • the server becomes an open relay;
  • every user can send through Microsoft 365 without credentials;
  • every external SMTP message is delivered from the hosting server's IP;
  • or the server will automatically be blacklisted.

Those are separate questions.

The actual outcome depends on:

  • the destination SMTP service;
  • whether authentication is required;
  • whether the application uses local Exim or a third-party provider;
  • the provider's policies;
  • the firewall configuration;
  • and the behaviour of the hosted process.

A practical decision framework

Instead of asking:

Is SMTP Restrictions good or bad?

a better set of questions may be:

1. What type of hosting environment is this?

  • traditional shared hosting;
  • managed application hosting;
  • a single-tenant server;
  • a developer-focused platform;
  • or a mixed environment?

2. Do customers legitimately need external SMTP?

For example:

  • Microsoft 365;
  • Google Workspace;
  • external transactional mail;
  • application-specific mail providers.

3. Is the operator's policy to force all SMTP through local Exim?

That can be a valid policy.

But it should be an intentional architecture decision.

4. What visibility exists outside Exim?

If external SMTP is allowed, can the operator investigate unusual outbound connections through:

  • firewall telemetry;
  • process monitoring;
  • endpoint protection;
  • network monitoring;
  • or other security controls?

5. What happens when a legitimate application fails?

Can support staff recognise:

expected external SMTP certificate
received local server certificate
Enter fullscreen mode Exit fullscreen mode

as a possible SMTP restriction symptom?

6. Has the decision been tested under a normal hosting user?

A root-level network test may not reproduce user-level restrictions.

A balanced operational approach

Some operators may reasonably choose:

SMTP Restrictions = Enabled
Enter fullscreen mode Exit fullscreen mode

because they prioritise:

  • centralised mail control;
  • Exim visibility;
  • and reducing direct SMTP access from user processes.

Others may reasonably choose:

SMTP Restrictions = Disabled
Enter fullscreen mode Exit fullscreen mode

because they prioritise:

  • compatibility with modern applications;
  • customer-managed external email services;
  • and direct authenticated SMTP submission.

A third group may keep restrictions enabled while using:

  • external relays on supported custom ports;
  • smarthost designs;
  • or other controlled architectures.

There is no useful universal answer without understanding the environment.

Final thoughts

cPanel SMTP Restrictions solve a real problem.

They can reduce the ability of ordinary user processes to bypass the local mail server, which can be valuable in shared hosting environments.

But the same control can also interfere with legitimate applications that intentionally use external SMTP providers.

The most important lesson is not "always enable it" or "always disable it".

It is this:

Understand the actual traffic path before making the decision.

When troubleshooting, test:

  • as root;
  • as the hosting user;
  • and from the actual application runtime.

Inspect:

  • the SMTP banner;
  • the TLS certificate;
  • the destination;
  • and the user context.

And when deciding whether the restriction belongs in your environment, separate:

  • direct-to-MX delivery;
  • authenticated SMTP submission;
  • external relays;
  • local Exim traffic;
  • and custom-port designs.

They are not the same problem.

A simple ON/OFF switch can represent a much larger architectural trade-off.

References

  1. cPanel & WHM Documentation — SMTP Restrictions

    https://docs.cpanel.net/whm/security-center/smtp-restrictions/

  2. cPanel Support — How to disable SMTP Restrictions

    https://support.cpanel.net/hc/en-us/articles/1500009931961-How-to-disable-SMTP-Restrictions

  3. cPanel Community — Restrict outgoing SMTP, why is bad to allow?

    https://support.cpanel.net/hc/en-us/community/posts/19161442634903-Restrict-outgoing-SMTP-why-is-bad-to-allow

  4. cPanel Community — SMTP Restrictions and External SMTP providers

    https://support.cpanel.net/hc/en-us/community/posts/34506598182295-SMTP-Restrictions-and-External-SMTP-providers

This article is intended as a technical and operational analysis. It does not recommend one universal configuration for every cPanel server.

Top comments (0)