Postfix Sender Client Access Restrictions Not Working for Subdomains

Postfix sender client access restrictions fail for subdomains because the default lookup mechanism in sender_access performs exact matches only. To enforce rules on parent domains and all their subdomains, you must explicitly prefix domain names with an at symbol (@) in your restriction tables or utilize the check_sender_access feature with proper regex patterns. This ensures that mail from @sub.example.com is correctly evaluated against rules defined for @example.com.

Understanding Postfix Access Table Lookups

When configuring Postfix to restrict email senders based on their address, administrators typically use the smtpd_sender_restrictions parameter in the main.cf configuration file. A common approach involves defining a hash map file, such as /etc/postfix/sender_access, which contains lists of email addresses or domains paired with actions like REJECT or OK. The critical issue arises when an administrator defines a rule for a primary domain, such as example.com REJECT, expecting it to also block emails from subdomains like sales.example.com. By default, Postfix treats entries in these access files as literal strings. When an incoming email originates from [email protected], Postfix looks for an exact match of sub.example.com in the table. It does not automatically infer that this domain is a child of example.com. Consequently, if only example.com is listed, the lookup fails, and Postfix proceeds to the next restriction in the chain. This behavior is consistent across recent versions including Postfix 3.7.11 on Debian 12. Without explicit instructions to treat the entry as a domain pattern, the restriction remains ineffective for any subdomain structure.

The Correct Syntax for Domain Restrictions

To resolve this mismatch, you need to change how you define domains in your access table. Postfix supports a specific syntax where prefixing a domain name with an at symbol (@) tells the lookup engine to treat the entry as a domain suffix rather than an exact string match. This means that defining @example.com REJECT will match [email protected], [email protected], and critically, [email protected]. You should edit your sender access file, usually located at /etc/postfix/sender_access. Remove any existing entries that look like bare domain names without the leading at sign. Replace them with the correct format. For example:

# /etc/postfix/sender_access
@example.com    REJECT Sender domain blocked
@spam-domain.net    REJECT Known spam source

After making changes to the text-based access file, you must generate the binary database file that Postfix actually reads. Run the following command to rebuild the hash map:

sudo postmap /etc/postfix/sender_access

This creates a new file named /etc/postfix/sender_access.db. Ensure that the permissions on this file are readable by the Postfix process, typically owned by root but accessible by the postfix user group. Finally, reload the Postfix configuration to apply the changes:

sudo systemctl reload postfix

Alternative Approach Using Regular Expressions

If you require more complex matching logic, such as blocking multiple subdomains with varying patterns, you can use regular expression maps instead of plain hash maps. This method involves creating a separate file, often named /etc/postfix/sender_regexp, and configuring Postfix to use the regexp lookup type. In your main.cf, ensure your restriction calls the regexp map:

smtpd_sender_restrictions = check_sender_access regexp:/etc/postfix/sender_regexp, ...

Inside the regexp file, you can use Perl-compatible regular expressions to match subdomains dynamically. For instance, to block any subdomain of example.com, you might use a pattern like:

/\@.*\.example\.com$/    REJECT Subdomain blocked

However, note that regular expression lookups can be slower than hash lookups and may introduce performance overhead on high-volume servers. For most standard administrative tasks, the @ prefix method in hash maps is preferred due to its simplicity and speed. If you decide to use regexp, remember to run postmap on the regexp file as well, although some configurations allow direct reading depending on the setup.

Verifying the Configuration

Once the configuration is updated, testing is essential to confirm that subdomains are now being restricted. You can simulate an incoming email using the sendmail command line utility or through an SMTP client. Attempt to send an email from a subdomain address that should be blocked. Check the Mail log, typically found at /var/log/mail.log or /var/log/syslog, for entries indicating that the sender was rejected. Look for log messages containing "reject" and the reason provided in your access table. If the rejection occurs, the configuration is working correctly. If not, verify that the sender_access file is referenced in the correct order within smtpd_sender_restrictions. Postfix evaluates restrictions sequentially; if an earlier rule accepts the connection, subsequent sender checks may be skipped. Ensure no preceding rule inadvertently allows the traffic before reaching your sender restrictions. For related issues regarding email delivery on different network setups, you might find Handling Email Delivery with Dynamic IP Addresses on Ubuntu Server using Postfix useful, as network constraints can sometimes mask configuration errors. Additionally, understanding how envelope addresses interact with headers is crucial for comprehensive email management, as detailed in Change Postfix Sender Envelope MAIL FROM Address To Match Return Path Header Email For Multiple Domains.

Frequently Asked Questions

Why did my existing rules stop working after upgrading?

Upgrading Postfix does not typically change the fundamental lookup behavior of access tables, but configuration defaults or migration scripts might reset certain parameters. Always verify that your main.cf still points to the correct access files and that the syntax remains valid for the new version.

Can I mix exact address and domain restrictions in one file?

Yes, you can mix both types in a single sender_access file. Exact matches like [email protected] REJECT will work alongside domain suffixes like @example.com REJECT. Postfix processes the file line by line, so place more specific rules above general domain rules to ensure they take precedence.

What is the difference between sender_access and recipient_access?

sender_access evaluates the MAIL FROM command (the envelope sender), while recipient_access evaluates the RCPT TO command (the envelope recipient). They serve different purposes; sender restrictions often control who can relay or send bulk mail, whereas recipient restrictions manage mailbox availability and routing.

How do I debug why a rule is not triggering?

Enable verbose logging by setting debug_peer_list in main.cf for the specific server IP or domain. Restart Postfix and attempt a connection. Check the logs for detailed lookup results showing whether Postfix found a match in the access table or proceeded to the next rule due to a miss.

Is there a performance impact when using too many access rules?

Hash maps (hash:) are highly optimized and generally have negligible performance impact even with thousands of entries. However, regular expression maps (regexp:) can slow down processing significantly if the patterns are complex or numerous. Stick to hash maps for simple list-based restrictions whenever possible.