Tweak Settings is where a large number of server-wide behaviours are set, most of which should be left alone. A handful are worth changing on almost every server, and two defaults cause support tickets until somebody finds them.
Change one thing at a time and note what you changed. This screen affects every account at once.
Mail: the two that matter most
The maximum hourly emails per domain. This is the rate limit that stops a compromised account sending thousands of messages before anyone notices.
Set it deliberately rather than leaving it unlimited. A number generous for real use and low enough to be a ceiling; a few hundred per hour suits most shared accounts, turns a compromise into a blocked queue instead of a blocklisting. For where the alternative ends, see What to Do When Your IP or Domain Is Blocklisted.
The percentage of failed or deferred messages that triggers a notification. A rise here is the earliest signal that an account is sending spam, and it arrives hours before a listing does.
Send both notifications somewhere a person reads.
Prevent nobody from sending mail
A specific setting with a specific purpose: it stops mail being sent by the web server user rather than by an account.
With it off, a compromised script can send without being attributable to any account, which makes tracing the source considerably harder after the fact.
Turn it on. Then check that legitimate applications still send. A site handing mail to the local program rather than authenticating is the one that breaks, and that site should be using authenticated SMTP anyway. For making that change, see How to Fix WordPress Email Not Sending.
Track the origin of outbound mail
Enabling this adds a header identifying the script that sent each message.
When an account starts sending spam, that header names the file. Without it you have a compromised account and a directory tree to search by hand.
It costs almost nothing and it is the single most useful thing on this screen when something goes wrong.
The compilers setting
Whether unprivileged users can run compilers on the server.
Disabling it removes a step that many exploits rely on, compiling something after gaining a foothold. It also breaks legitimate use: anything installing packages that build from source, which affects some Node and Python workflows.
Disable it by default and grant exceptions per user where somebody genuinely needs it, instead of leaving it open for everyone because one account does. Running Node.js and Python Applications in cPanel explains what those workflows need.
Referrer checks: on, with care
Two settings block requests to cPanel and WHM that arrive without a valid referrer, which is a defence against a logged-in user being tricked into performing an action.
Leave them enabled. The reason they get switched off is a legitimate integration failing, and the better fix is usually an API token for that integration rather than weakening the check for everyone. There is more on creating one in How to Use cPanel API Tokens.
Where new accounts get their defaults
Several settings on this screen decide what an account looks like at creation: the default PHP behaviour, whether certain features are on, how subdomains are handled.
Those apply to accounts created afterwards, not to existing ones. So changing a default is a change for the future and leaves your current accounts as they are, which is either what you wanted or a source of two populations of accounts behaving differently.
Decide which, and if you want existing accounts to match, change them explicitly. There is more on the per-package side in WHM Feature Manager and Feature Lists.
Two that look tempting and are not
Raising PHP limits server-wide to solve one account's problem. That multiplies across every account and every worker, and on a busy machine it is how memory runs out: set it per account instead. How to Configure PHP Settings in cPanel picks it up from there.
Disabling a security check because one client reported a problem. The narrower fix is nearly always available, and a disabled check is permanent in practice because nobody re-enables it later.
Record what you change
This screen has hundreds of settings and no history. A year from now, a server behaving differently from another one is explained by something here, and nothing on the screen says when or why it changed.
Keep a dated list alongside your other server notes: what you changed, from what, and the reason. It costs a line per change and it is what makes two servers comparable. How to Plan and Run Server Maintenance Windows deals with keeping that record.
Test after saving
Some changes take effect immediately and some require a service restart, and the screen does not always distinguish.
After changing anything mail-related, send a real message. After changing anything PHP-related, load a real page on a real account. Confirming the intended effect takes a minute; discovering it from a client takes considerably longer.
The other server-wide setting worth deciding once is how soon new panel versions reach you. There is more on the tiers and the one option that should stay enabled regardless in cPanel Update Preferences and Release Tiers Explained.
Record what you changed and why
Panel settings are adjusted during incidents and reviewed never, so a server accumulates changes nobody can explain. Keep a dated note of each one, what problem it addressed and what would make it removable. Without that, the next person either leaves everything alone because it might matter, or reverts something that was holding a fault at bay. Both outcomes come from the same missing sentence, and writing it costs less time than the conversation it prevents.