We let you block senders by address or wildcard pattern at the SMTP level

Simple feature, but it comes up a lot: sender blocklisting.

How it works

Add an email address or a wildcard pattern to your blocklist. Some examples:

• spammer@example.com blocks that specific address
• *@annoying-newsletter.com blocks everything from that domain
• *@*.marketing.example.com blocks all subdomains under their marketing infrastructure

Blocked messages are rejected at the SMTP level during the initial connection. The sending server gets a 5xx rejection. The message never gets forwarded, never hits your inbox, never consumes your email volume quota, and never shows up in your logs as a delivered message. It's gone before it enters the pipeline.

Why SMTP-level rejection matters

Some services accept the message first and then filter it on the backend. That means the message was already processed, stored temporarily, and counted against your usage before being discarded. With SMTP-level rejection, the sending server knows immediately that delivery failed. If it's a legitimate sender you accidentally blocked, they'll get a bounce notification right away instead of their message silently disappearing.

Management

You can manage the blocklist from three places:

• The dashboard (add/remove entries, see the full list)
• The REST API (programmatic management, bulk operations)
• The MCP server (tell your AI agent "block everything from spammer.com")

What we track

The blocklist itself is simple, but we log rejection events so you can see how many messages are being blocked and from which senders. Useful for spotting patterns or confirming that a block rule is actually catching what you intended.

What it doesn't do

The blocklist is for explicit sender blocking. It's not a spam filter. We run rspamd for content-based spam filtering separately. The blocklist is for when you know exactly who you don't want to hear from and you want them rejected hard at the door.

What's your approach to blocking unwanted email at the infrastructure level? Do you prefer sender-based blocking, content filtering, or a combination? We've been thinking about adding support for header-based rules (block messages with specific X-headers or subject patterns) but haven't decided if that's worth the complexity.