Sender Filtering

Sender filtering lets you control which senders a namespace accepts email from. You can either blacklist specific senders and accept everyone else, or whitelist specific senders and reject everyone else.

Filtering happens on our mail servers during the SMTP conversation, before the message body is transferred. A rejected email is never stored, never shows up in the inbox, and does not count towards your monthly email usage or the namespace quota.

Filtering is configured per namespace in the dashboard under Namespaces → (your namespace) → Settings → Receipt filtering. Only the namespace owner or an organisation admin can edit the policy; other team members can view it.

Filtering modes

A namespace is always in exactly one of these modes:

Mode	Behaviour
Off	Accept email from any sender. This is the default.
Blacklist	Reject email from senders matching any blacklist rule, accept others.
Whitelist	Accept email only from senders matching a whitelist rule, reject others.

Only the list belonging to the selected mode is applied. In blacklist mode the saved whitelist has no effect, and in whitelist mode the saved blacklist has no effect. Both lists are kept when you switch modes or turn filtering off, so you can switch back later without re-entering your rules.

Rules within a list are combined with OR: a sender matching any one rule counts as a match.

WARNING

A whitelist cannot be enabled while it is empty, and you cannot remove the last rule from an active whitelist. This prevents accidentally rejecting all incoming email.

Rule types

Each list holds up to 100 rules. A rule is one of the following:

Type	Matches	Example
Email address	Exactly this sender address.	notifications@example.com
Domain	Senders whose address is at exactly this domain. Enable Include subdomains to also match any subdomain.	example.com
Null sender	Messages with an empty envelope sender (<>). These are typically bounces and other delivery notifications.	–

Notes on matching:

• Domains are matched case-insensitively. The part of an email address before the @ is matched exactly as entered, so Alice@example.com and alice@example.com are different rules.
• Plus tags and dots are not normalised. user+tag@example.com only matches that exact address.
• A domain rule for example.com with Include subdomains enabled matches example.com and mail.example.com, but never badexample.com or example.com.attacker.test.
• Wildcards such as *.example.com are not supported. Use a domain rule with Include subdomains instead.
• Duplicate rules within a list are rejected.

Envelope sender vs. From address

Rules are matched against the SMTP envelope sender (also called the return path or MAIL FROM), not the From: header you see in the email. The two are often different. For example, many email providers send from a dedicated bounce domain such as bounce.mailer.example.net while the visible From: address is hello@example.com.

To find the envelope sender of an email you have already received, open the email in the dashboard and click the question-mark button next to the From address. The Sender details dialog shows both the From: header and the SMTP envelope sender that was recorded on delivery. Use the envelope sender when writing your rules.

Delivery notifications usually have an empty envelope sender. In whitelist mode these are rejected unless you add a Null sender rule. In blacklist mode they are accepted unless you add one.

Testing a sender

The Test a sender section on the Receipt filtering page lets you check whether a given envelope sender would be accepted or rejected by the policy as you are currently editing it, without sending an email. Enter an address, or <> for a null sender, and click Check. The result tells you whether the sender is accepted and whether it matched a rule.

The check runs against your unsaved draft, so you can verify a change before saving it.

When changes take effect

Saving the policy publishes it immediately, but our mail servers pick up changes on a short synchronisation cycle. Changes normally apply within about five minutes. Until then the previously saved policy continues to apply.

If someone else edits the same policy while you are editing it, your save is rejected with a conflict and the dashboard offers to reload the saved policy. This avoids silently overwriting another admin's changes.

What a rejected sender sees

Rejected messages are refused during delivery with a permanent SMTP error:

550 5.7.1 Receipt blocked by namespace policy

The sending mail server is responsible for generating a bounce to the sender, as it would for any other permanent rejection. Mailisk does not accept and silently discard the message, and the SMTP response does not reveal which rule matched or what your lists contain.

Rejected messages are not stored anywhere, so they cannot be retrieved later. Existing emails in the namespace are never affected by policy changes.