Email firewall — block spam sources before SMTP even answers.
IP-based access rules right at the network layer (nftables) — before Postfix. Known spam sources are rejected without consuming a single filtering resource. Active instantly, replicated across every node in the cluster.
How it works
The firewall acts at the lowest layer of mail processing: rules take effect via nftables at the network level, before a connection ever reaches Postfix, Postscreen or rspamd. A blocked IP never even sees an SMTP banner — the connection is dropped immediately. That saves compute: traffic that would never be delivered anyway costs no scan time.
Three rule types
- Allow — an IP or CIDR block is explicitly permitted (highest priority). The IP is exempted from Postscreen and rate limiting — ideal for internal networks and trusted relays that must never be blocked by accident.
- Block — an IP/CIDR is permanently blocked. The SMTP connection is dropped instantly, no banner. For known spam sources from abuse reports or your own experience.
- Rate-limit — the connection rate of an IP/CIDR is capped. Catches aggressive senders without discarding legitimate delivery entirely.
Configurable per rule
- IP / CIDR — a single address (
1.2.3.4) or a whole block (1.2.3.0/24) - Action — allow, block or rate-limit
- Port — SMTP (25), submission (587) or both
- Comment — e.g. the abuse report the IP came from
Instant, and everywhere in the cluster
Rules take effect instantly, no restart required. In the active-active cluster, MailGuard replicates every firewall rule to all nodes automatically — a block entered on one node applies to the whole cluster at once. No manually maintaining a second gateway, no drift between nodes.
Why the network layer, not just the filter
Cloud email-security services only filter spam in their own application layer — the connection is accepted, the mail received, then scored. MailGuard runs on your gateway and hands you the nftables layer directly: you decide which networks never get to speak at all. That is faster, lighter on resources and stays entirely inside your infrastructure — GDPR-compliant, made in Germany.
Field-tested recommendations
- Consistently block known spam sources from abuse reports and your own experience
- Add internal networks and trusted relays as allow so they are never blocked
- Use very broad CIDR blocks (/8, /16) only after careful review — they hit many addresses at once
- Before every block, check whether your own management IP is affected — an accidental self-block locks you out of the interface
Reject spam before it costs resources?
The email firewall blocks known sources at the network layer — active instantly, cluster-wide, on your own gateway.
See pricing