SMTP relaying is a surprisingly brittle system, and the most common reason it breaks isn’t a complex security flaw, but a simple misconfiguration of who’s allowed to send mail through your server.
Imagine you’ve got an application server that needs to send out notifications. It’s configured to use your main mail server (let’s call it mail.example.com) as an SMTP relay. When the application tries to send, it gets an error like 550 5.7.1 Relay access denied.
This means your mail.example.com server received the connection and the MAIL FROM command, but decided the connecting host (app.example.com) isn’t authorized to send mail through it to the outside world. It’s acting like a bouncer at a club, refusing entry to someone who isn’t on the guest list.
Here are the most common reasons this happens, and how to fix them:
1. Missing or Incorrect mynetworks Configuration
This is the most frequent culprit. Most mail servers (like Postfix, Sendmail, Exim) have a directive that defines a list of "trusted" IP addresses or network ranges that are allowed to relay mail without further authentication. If your application server’s IP isn’t on this list, relaying is denied.
Diagnosis:
For Postfix, check the mynetworks parameter in /etc/postfix/main.cf:
sudo postconf mynetworks
For Sendmail, check the trusted_networks macro in /etc/mail/sendmail.mc.
For Exim, check the acl_smtp_rcpt or acl_smtp_mail sections in /etc/exim4/exim4.conf.template for hosts or networks checks.
Fix (Postfix example):
Let’s say your application server is at 192.168.1.100 and your mail server is 10.0.0.5. You’d add your application server’s IP to mynetworks.
Edit /etc/postfix/main.cf:
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.1.100
Then reload Postfix:
sudo postfix reload
Why it works: This explicitly tells Postfix that any connection originating from 192.168.1.100 is from a trusted source and is allowed to use the server as a relay.
2. Missing or Incorrect smtpd_recipient_restrictions (Postfix)
Even if an IP is in mynetworks, Postfix’s smtpd_recipient_restrictions can further control relaying. A common pattern is to allow mynetworks early in the chain but then deny relaying for others. If your mynetworks entry is correct but the overall restriction list is too strict, it can still fail.
Diagnosis:
Check smtpd_recipient_restrictions in /etc/postfix/main.cf:
sudo postconf smtpd_recipient_restrictions
Fix (Postfix example):
A typical configuration might look like this. Ensure permit_mynetworks is present and appears before any broad reject_unauth_destination rules.
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination
If permit_mynetworks is missing or placed after reject_unauth_destination, add it. Reload Postfix:
sudo postfix reload
Why it works: Postfix processes these restrictions in order. By allowing mail from mynetworks before it checks if the destination is authorized for the server itself, you grant relay access to your trusted clients.
3. IP Address Mismatch or Dynamic IP Issues
If your application server’s IP address has changed, or if it’s a dynamic IP that has been reassigned, your mynetworks configuration will be out of date.
Diagnosis: On the application server, check its current public IP address:
curl ifconfig.me
Compare this to the IP(s) listed in your mail server’s mynetworks configuration.
Fix:
Update the mynetworks list on your mail server with the application server’s current IP address. If the application server has a dynamic IP, consider assigning it a static IP, using a VPN with a stable IP, or implementing SASL authentication (see below).
Why it works: Ensures the mail server is checking against the correct, current IP address of the client attempting to relay.
4. Firewall Blocking the Connection
The application server might not be able to reach your mail server on the SMTP port (usually 25, 587 for submission, or 465 for SMTPS).
Diagnosis: From the application server, try to connect to the mail server’s SMTP port:
telnet mail.example.com 25
If it times out or says "Connection refused," it’s likely a firewall issue.
Fix: Ensure that firewalls on both the application server’s network and your mail server’s network (including any cloud security groups or network ACLs) allow traffic from the application server’s IP to the mail server’s IP on the relevant SMTP port (typically 25 or 587).
Why it works: Opens the network path, allowing the SMTP connection to be established so the relay authorization checks can even be performed.
5. SASL Authentication Not Configured or Used
For more robust security, especially if clients have dynamic IPs or are not on the same trusted internal network, you should use SASL (Simple Authentication and Security Layer). This requires clients to log in with a username and password. If SASL is enabled on the server but the client isn’t configured to use it, or if SASL is enabled but the client’s credentials are wrong, relaying can be denied.
Diagnosis:
Check Postfix’s SASL configuration in /etc/postfix/main.cf:
sudo postconf smtpd_sasl_auth_enable
sudo postconf broken_sasl_auth_enable # Should be 'no'
sudo postconf smtpd_sasl_security_options
On the client, check its SMTP client configuration (e.g., in your application’s settings) for username, password, and authentication mechanism (e.g., PLAIN, LOGIN).
Fix:
Ensure smtpd_sasl_auth_enable = yes in main.cf. Configure your application to use a valid username and password for authentication. Ensure the username and password are correct and the user is authorized to send mail (often managed by a smtpd_sender_login_maps or similar).
Example Postfix config snippet for SASL:
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot # or cyrus
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination
Reload Postfix and ensure your application is configured with correct credentials.
Why it works: SASL provides a cryptographic method for clients to prove their identity, allowing the mail server to grant relay access based on authenticated user credentials rather than just IP address.
6. Incorrect smtpd_sender_login_maps (Postfix)
If you’re using SASL, you might have a map that links authenticated users to the email addresses they are allowed to send from. If this map is incorrect, the user might be authenticated but still denied relaying because they’re trying to send from an unauthorized address.
Diagnosis:
Check smtpd_sender_login_maps in /etc/postfix/main.cf:
sudo postconf smtpd_sender_login_maps
Examine the file specified (e.g., /etc/postfix/sender_login_maps).
Fix:
Ensure the file correctly maps authenticated usernames to the email addresses they are permitted to use as the MAIL FROM address. For example:
user@example.com your_sasl_username
Then, run sudo postmap /etc/postfix/sender_login_maps and sudo postfix reload.
Why it works: This adds another layer of authorization, ensuring that even a logged-in user can only send mail as specific, permitted sender addresses.
After fixing relay access, the next error you’ll likely encounter is related to SPF, DKIM, or DMARC validation failures on the receiving end, as your mail server’s IP will now be sending mail to the internet.