Bali, Indonesia
Home
About
Work
Blog
Insights
Insights

Send Newsletters Through cPanel's Exim or an External Relay Under Gmail Bulk Rules?

October 24, 2026
0:00
A newsletter plugin on a cPanel site sends a few hundred emails a week without trouble. Then the owner wants to mail the whole list, which is mostly Gmail addresses, and asks support whether the server can handle it or whether they need an external sending service. The answer has little to do with whether Exim can push the mail out. It can. What matters is what happens once Gmail treats the domain as a bulk sender, and who absorbs the consequences when something goes wrong.

How Gmail decides you are a bulk sender

Gmail calls anyone sending close to 5,000 messages or more per day to personal Gmail accounts (@gmail.com and @googlemail.com) a bulk sender. The count is taken across your primary root domain, not per mailbox or per server. Mail from news.example.com, shop.example.com and example.com adds up to one total. Order receipts and password resets count too, because they come from the same domain as the newsletter. Google also says that once a domain meets the threshold, it stays classified as bulk. One big campaign is enough. Bulk senders must publish SPF and sign with DKIM. They need a DMARC record (at least p=none) and a From: domain that aligns with the SPF or DKIM domain. They also need valid forward and reverse DNS for the sending IP, TLS on the connection, one-click unsubscribe for marketing mail, and a low spam complaint rate as reported in Google Postmaster Tools. Mail that falls short gets throttled, sent to spam, or rejected outright. Counting is per domain, and that has a consequence people often miss. Moving to an external relay changes the IP and the infrastructure, but it does not reset your bulk status or your domain reputation. Those follow the From: domain wherever the mail is sent from.

What Exim does with one newsletter message

It helps to follow a single message through a cPanel server. Most confusion about local sending comes from not knowing where the message is at each step.
  1. Submission. The plugin hands the message to Exim. It either calls PHP mail(), which runs the local sendmail binary (Exim's), or it opens an authenticated SMTP session to the local server. Exim's access control lists (ACLs) run at this point. On cPanel, this is also where the per-domain hourly counter gets checked.
  2. Spool. Once accepted, the message is written to the spool under /var/spool/exim/input as a header file and a data file sharing one message ID. The plugin now reports the message as sent. In reality it is only queued.
  3. Routing. Exim's routers run in order. For a gmail.com recipient, a DNS-based router looks up the MX records and assigns a remote SMTP transport.
  4. Transport. Exim opens a TCP connection to a Gmail MX on port 25 from the server's outgoing IP. That is the main shared IP unless the host has mapped domains to other IPs, typically through /etc/mailips. Exim negotiates STARTTLS, adds the DKIM signature for the sending domain, then sends the envelope and the message.
  5. Outcome. A 250 reply means Gmail accepted it. Exim removes the spool files and logs the delivery with =>. A 4xx reply is a temporary deferral. The message stays in the spool, the log shows ==, and Exim's retry rules decide when to try again. A 5xx reply is permanent. Exim logs ** and generates a bounce to the envelope sender.
The 4xx path is where bulk sending gets messy. When Gmail dislikes the rate or the reputation, it defers, as described in Why Exim Logs Gmail 421 Rate Limit Deferrals for cPanel Domains. Exim records the failure in its retry hints database. Those hints are shared across the whole server, so other accounts' mail to the same Gmail hosts can wait behind the same retry schedule. The queue grows, and every retry is another connection from an IP Gmail is already wary of. You can see which route and transport Exim would use for a Gmail recipient, and which interface the transport binds to, without sending anything:
BASH
# Show which router and transport would handle this address (no mail is sent)
exim -bt [email protected]

# Print the remote SMTP transport settings, including interface and DKIM options
# (transport names differ between cPanel versions; use the name exim -bt reported)
exim -bP transport remote_smtp
Illustrative output format for exim -bt (names and IPs vary):
TEXT
[email protected]
  router = <router-name>, transport = <transport-name>
  host gmail-smtp-in.l.google.com [<mx-ip>] MX=5

Where the hourly limit and the shared IP get in the way

cPanel servers usually cap how many messages a domain can send per hour. In WHM this lives under Tweak Settings, and the host chooses the value. Take an illustrative cap of 500 per hour. A 5,000-message campaign then needs at least ten hours. Messages over the cap are usually deferred back into the queue, though the behavior depends on configuration. So the campaign does get spread out, but by accident. Nobody planned the pacing, and the queue holds thousands of messages the whole time. A second setting caps the percentage of failed or deferred messages a domain may have per hour. An old list full of dead addresses produces bounces. Gmail throttling produces deferrals. Together they can push the domain over that percentage, and the server then stops it from sending entirely. That includes the invoices and password resets going out from the same domain. Then there is the IP. Gmail weighs both domain and IP reputation. On shared hosting, the outgoing IP's reputation is the sum of every account on the server. You cannot control your neighbors, and the host controls the PTR record. A VPS with its own IP fixes the neighbor problem but creates a new one. A fresh IP has no sending history, so it needs gradual warm-up before it can carry full campaign volume. A quick read-only check shows how much is waiting and whether Gmail is deferring:
BASH
# Number of messages currently in the Exim queue
exim -bpc

# Recent deferrals to Gmail in the main log (cPanel log path)
grep 'gmail' /var/log/exim_mainlog | grep ' == ' | tail -n 20

Which duties stay with you either way

With local Exim, nearly everything is yours or your host's. cPanel can generate DKIM keys and sign outgoing mail, but you should confirm it is enabled for the domain. SPF must authorize the server's IP. You need to publish DMARC yourself. The host owns PTR. Exim will not add List-Unsubscribe or List-Unsubscribe-Post: List-Unsubscribe=One-Click headers, so the plugin has to add them and act on unsubscribe requests quickly. Google cites a two-day window. Bounces go back to the envelope sender's mailbox, where nobody tends to read them, so someone has to remove hard-bouncing addresses. Watching complaint rates means verifying the domain in Postmaster Tools. A relay takes over the infrastructure side. It owns the IP pool and its reputation, paces connections to Gmail, handles retries, and usually processes bounces and complaints. Some relays add unsubscribe headers and some leave that to you. Check rather than assume. What stays with you is the domain. You still have to publish the relay's DKIM key on your domain so signatures align with your From: address. You authorize the relay in SPF, either with an include or with a custom return-path subdomain, and an include can push you past SPF's ten-lookup limit. DMARC stays yours, and so do list quality and content. If recipients mark the mail as spam, your domain reputation drops no matter whose IP delivered it. When alignment breaks after a switch, the receiving side's headers show which identifier failed, as covered in Reading Authentication-Results Headers to Fix DMARC Alignment.

Questions that decide where the mail goes

Start with the real daily volume to Gmail across the whole root domain, transactional mail included. If it sits well under the threshold and the list is opt-in and clean, local Exim with correct authentication is usually fine. Next, ask whose IP you are sending from. On a shared IP you inherit other accounts' reputation and cannot fix PTR yourself. That shifts the balance toward a relay well before you reach bulk volume. Compare the hourly cap to the list size. If the campaign would sit in the queue for most of a day, and a failure could block the domain's other mail, the server is the wrong place for it. Check whether the site can reach the relay at all. Many cPanel servers enable SMTP Restrictions, which stop user processes from connecting to outside mail servers. A plugin pointed at a relay over SMTP may then fail silently or fall back to local mail. Relays that offer an HTTP API avoid this. A server-wide smarthost, where all of Exim's outbound mail goes through the relay, is only an option if you control WHM. It also changes delivery for every account on the server. Finally, ask who reads bounces and handles unsubscribes. If the honest answer is nobody, choose the setup that handles them for you. Some owners send the newsletter from a subdomain such as news.example.com to keep marketing separate from transactional mail. That can help isolate some reputation signals. It does not take you out of the bulk count, because Gmail still adds the volume to the root domain. A practical rule: keep mail on the server while volume is low, the IP is yours or clean, and the list is healthy. Move campaigns to a relay once you approach bulk volume or rely on a shared IP, and keep transactional mail wherever it delivers reliably. Either way, set up SPF, DKIM, DMARC alignment and one-click unsubscribe before the first big send. A relay does not exempt your domain from those requirements.