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