How to Block Email from a Specific Sender in EXIM (With Smart Domain Filters, Pattern Matching, and Advanced Content Rules)

EXIM offers powerful tools for email administrators to control exactly who can send mail to their systems. One of the most effective (and often overlooked) methods is using sender-based blocking, whether by full email address, wildcard domain, or clever pattern matching.

In this guide, you'll learn:

How to block email from specific senders in EXIM
Where to add these rules safely
Using wildcard and pattern matching for broader control
Static and dynamic blacklist approaches
How to combine sender-based rules with domain intelligence and message content filtering
Clever use cases to improve abuse detection, phishing protection, and policy enforcement

1. Where to Block Senders in EXIM

Just like IP-based blocks, sender-based filtering should go into the ACLs, typically inside the acl_check_rcpt section.

File paths depend on your configuration style:

Single-file config: /etc/exim4/exim4.conf.template
Split config: /etc/exim4/conf.d/acl/40_exim4-config_check_rcpt

Make sure this ACL runs before accepting a message, usually before or near the end of acl_check_rcpt.

2. Block a Specific Sender or Domain

To block a single domain or pattern:


						deny

						    message = Your message has been rejected because the sender is blacklisted.

						    senders = *@example.com

This denies any sender at example.com. You can also specify:

senders = spammer@example.com : *@spammer.org

Multiple entries separated by : are allowed.

3. Smart Wildcards and Pattern Matching

EXIM supports several lookup styles and patterns for efficient domain blocking.

Use regular expressions for advanced filters:


						deny
						    message = Rejected: known bad sender.

						    condition = ${if match{$sender_address}{.*@.*\.ru$}{yes}{no}}

This blocks all senders from .ru domains — useful during high-spam periods.

Use domain-specific filters:

Block subdomains without affecting the root:

condition = ${if match_domain{$sender_address_domain}{*.badsite.com}{yes}{no}}

You can also invert logic using ! to allow only approved senders:


						accept

						    condition = ${if match_domain{$sender_address_domain}{approved.com:trusted.net}{yes}{no}}

						deny

						    message = Sender not allowed.

4. Dynamic Sender Blacklists (Using Files)

Create a dynamic blacklist file:

/etc/exim4/sender_blacklist.txt

Add lines like:


						spammer@example.com

						*@junk.org

						*@*.marketing.ru

Then update your ACL:


						deny

						    message = Rejected: blacklisted sender.

						    senders = ${readfile{/etc/exim4/sender_blacklist.txt}}

This gives you a lightweight, maintainable system. Scripts can append/remove entries, and you can combine this with fail2ban or log triggers.

5. Advanced Use: Combine Sender with Message Content

Want to block users from a domain sending specific types of content?

Example: Block any message from *@suspicious.biz if it contains the phrase "click here" in the subject:


						deny

						    message = Message flagged and rejected due to spam content.

						    condition = ${if and{

						        {match_domain{$sender_address_domain}{suspicious.biz}}

						        {match{$h_subject:}{(?i)click here}}

						    }{yes}{no}}

This is extremely powerful for catching phishing, promo spam, or impersonation attempts.

6. Content-Based Sender Rules (More Dynamic Filtering)

You can even dynamically generate responses based on the sender:


						deny

						    message = Rejected. Sender $sender_address is blocked due to abuse incident #${sg{${lookup{$sender_address}lsearch{/etc/exim4/sender_reasons.txt}}}{ }{}}.

						    condition = ${if exists{/etc/exim4/sender_reasons.txt}{${if match{$sender_address}{${lookup{$sender_address}lsearch{/etc/exim4/sender_reasons.txt}}}{yes}{no}}}{no}}

And keep a file like:


						spammer@example.com : 3125

						abuser@evil.co : 4210

That lets you track internal case IDs or reference codes.

7. Reporting and Logging Rejected Senders

To asynchronously track hits, you can:

Add a custom header:

add_header = X-Reject-Sender: $sender_address

Tail EXIM logs:


						grep "X-Reject-Sender" /var/log/exim4/mainlog | while read line; do

						    echo "$line" | nc internal-logger.company.net 7777
						done

Or pipe directly to a webhook that updates a dashboard or sends alerts.

8. Bonus: Combine Sender Rules with Greylisting, DNSBLs, or SPF

Make layered checks — deny fast, but keep fallbacks.

Example: Allow @example.com only if SPF passes:


						deny

						    message = Sender domain has failed SPF validation.

						    senders = *@example.com

						    condition = ${if !eq{$spf_result}{pass}{yes}{no}}

You can also:

Apply greylisting to suspicious TLDs.
Accept mail only from DKIM-valid senders for known risky domains.
Ban full TLDs temporarily (e.g. .click, .tk).

Conclusion

Sender-based blocking in EXIM is one of the most versatile, precise tools in your MTA toolkit. Whether you're managing inbound abuse, enforcing corporate policy, or dealing with phishing attempts, it's easy to combine static rules, dynamic lookups, content filtering, and clever logic to secure your system.

See also: Learn how to build an automated abuse-handling workflow that updates your sender blacklist from EXIM logs in real time.

MYSTREAM AGENCY