Email is the one service where "it mostly works" is not good enough. If a single setting on your mail server is wrong, your invoices land in spam, your password-reset links never arrive, and — worse — a stranger can send mail as you. Since Google and Yahoo tightened their bulk-sender rules in 2024, an unauthenticated mail server is no longer "a bit risky": it is silently rejected at the door.
This post is a complete, no-marketing tour of how Panelica protects email — every layer, why it exists, what it actually does, and exactly where you turn it on in the panel. We will draw the real screens as we go.
The short version: defense in depth
Spam protection is not one feature you flip on. It is a chain. Each link does one job, and an attacker (or a misconfiguration) has to beat every link in order. Panelica groups them into three fronts:
Front 1 — Outbound identity: proving the mail is really yours
Before your server can receive well, it has to send in a way Gmail trusts. Three DNS records do this. Panelica generates each one for you — you never hand-edit a zone file — from Email → Authentication.
- SPF — a public list of "these servers are allowed to send mail for my domain." Without it, anyone can forge your address.
- DKIM — a cryptographic signature stamped on every outgoing message. Panelica auto-creates a key per domain and publishes the public half in DNS. Gmail made this mandatory for bulk senders in 2024 — no DKIM, no delivery.
- DMARC — the policy that ties SPF and DKIM together and tells the world what to do with fakes (quarantine or reject), plus where to send abuse reports.
One click produces the key, and Panelica writes the matching TXT record into the
domain's zone for you. The same screen builds SPF (~all by default) and
DMARC (quarantine or reject, with a reporting address).
Front 2 — Inbound filtering: three gates every message must pass
This is where incoming spam actually gets stopped. Panelica runs three gates in order, each cheaper than the next, so junk is dropped as early as possible.
- Postscreen (reputation gate) — the cheapest, toughest filter. It checks the connecting IP against
zen.spamhaus.org,bl.spamcop.netandb.barracudacentral.org, while a whitelist (dnswl.org) protects legitimate senders. Botnet "zombies" are turned away at the door, so your server never spends CPU on them. - OpenDMARC (anti-spoofing gate) — confirms an incoming message truly comes from who it claims. This is what stops "your CEO" emailing accounts payable from a fake address.
- SpamAssassin (content gate) — the classic scoring engine with Bayesian learning. You set the spam threshold and the action (tag the subject, or reject outright).
Front 3 — Transport security & abuse control
- DANE — uses DNSSEC to guarantee outgoing mail is delivered over a verified encrypted channel, blocking "man-in-the-middle" downgrade attacks. It is opportunistic, so it never breaks delivery to servers that do not support it.
- MTA-STS — tells other servers to always use TLS when sending to you. Panelica starts it in safe "testing" mode so a misconfiguration can never silently lose mail.
- Outbound rate limiting — per-hour and per-day caps on sending. If one account is ever compromised, this contains the blast: your server cannot turn into a spam cannon and get blacklisted.
- Relay protection & TLS enforcement — the server refuses to relay mail for strangers (
reject_unauth_destination) and enforces a minimum TLS version. Plus per-domain allow/deny lists.
The part nobody else does: an honest panel
Here is the difference that matters most. On many control panels, you flip a "DMARC: ON" switch and the panel happily shows it as enabled — while in the background the service was never actually installed. We call this a silent no-op: the panel claims protection that is not there, and you only find out when mail breaks.
Panelica refuses to do that. Every protection toggle on the Email → Mail Settings → Protection tab shows its real runtime state — it reads the live mail server, not the saved setting. If the package is still installing, you see it. If something is wrong, you see that too.
And because a server reboot or an update can knock a dependency loose, Panelica adds a
self-heal step at every startup: if a required package or config line is
missing, the panel quietly reinstalls and re-wires it. This runs on both
Debian/Ubuntu (apt) and AlmaLinux/Rocky (dnf), and is tested across
a nine-OS matrix — so "I turned it on" stays true after a reboot, not just on the day
you clicked it.
Turning it all on — step by step
- Authenticate your domains. Go to Email → Authentication and generate DKIM, SPF and DMARC for each domain. One click each; the DNS records are written for you.
- Enable inbound filtering. Open Email → Mail Settings → Protection and switch on SpamAssassin, Inbound DMARC and Postscreen. Watch the badges go from Installing to Active.
- Harden transport. Turn on DANE and MTA-STS once your DNS is in place. Panelica keeps MTA-STS in safe testing mode until you confirm it.
- Set your limits. Configure the outbound per-hour/per-day caps and your spam threshold to match your traffic.
- Trust the badge. If every row shows Active, the protection is genuinely live. No guesswork.
Why this matters
Good email security used to mean an afternoon of editing main.cf by hand,
hoping every directive was right, and discovering mistakes only when customers complained.
Panelica turns the entire stack — SPF, DKIM, DMARC, Postscreen, SpamAssassin, DANE,
MTA-STS, rate limiting — into clearly labelled switches that tell you the truth about
what is running. You get deliverability that meets the 2024+ Gmail and Yahoo rules, and
spam filtering that holds up, without ever touching a terminal.
Email is hard. Your control panel should make it honest. See it in action at panelica.com.