How to Fix Plesk Email Forwarding Not Working (Postfix & Relay Issues)

Plesk email forwarding not working is a frustrating problem because there's no obvious error — the forwarder is configured correctly in the Plesk panel, but emails to the forwarding address never arrive at the destination. The issue can stem from several different layers: Postfix relay restrictions, SPF/DMARC blocking at the receiving end, Plesk's own forwarding copy settings, or anti-spam filtering intercepting the forwarded message. This guide walks through each root cause with the diagnostic commands and configuration changes needed to fix them.

How Plesk Email Forwarding Works (And Where It Breaks)

When you configure a forwarder in Plesk (Mail > Email Addresses > Forwarding), Plesk adds a Postfix alias or redirect rule. When an email arrives for the source address, Postfix resends it to the destination address. This resending step — re-injecting the original email from your server — is where most forwarding failures originate.

The three most common failure points are:

• Postfix rejects the relay — your server is not authorised to send email that appears to come from the original sender's domain
• Destination server rejects the email — Gmail, Outlook, or other providers reject forwarded email because SPF or DMARC fails on the re-sent message
• Anti-spam software (SpamAssassin/Amavis) filters it — the forwarded message is flagged as spam before it leaves your server

Step 1: Confirm the Forwarder Is Configured Correctly in Plesk

Before digging into Postfix logs, verify the forwarder is set up correctly:

# Watch the mail log in real time
tail -f /var/log/maillog

# Or check recent activity
grep "FORWARD\|forwarded\|status=sent\|status=bounced\|relay denied" /var/log/maillog | tail -30

Root Cause 1: Relay Access Denied (554 Error)

If the log shows relay access denied or a 554 status, Postfix is refusing to forward the email because it treats the re-injection as an unauthorised relay attempt.

grep "relay access denied\|554" /var/log/maillog | tail -20

This usually happens because Postfix's mynetworks or relay_domains settings are misconfigured after a Plesk upgrade.

Fix: Verify Postfix Relay Configuration

# Check current relay settings
postconf mynetworks
postconf relay_domains
postconf mydestination

The relay_domains list should include the domains you are forwarding from. If it doesn't, you can force Plesk to regenerate the Postfix configuration (which is the safer approach than editing main.cf manually on a Plesk server):

# Regenerate Postfix config from Plesk
/usr/local/psa/admin/bin/mchk --with-mail-server-settings

# Then reload Postfix
postfix reload

Root Cause 2: SPF/DMARC Rejection at the Destination (Gmail/Outlook)

This is the most common cause of forwarding failures to Gmail, Outlook, and Yahoo. When your server forwards an email, it re-sends the original message with the original From: header intact. The destination mail server performs an SPF check and sees that your server's IP is not in the original sender's SPF record — so it rejects or quarantines the email.

Look for these indicators in the log:

grep "550-5.7.26\|550 5.7.1\|dmarc\|spf.*fail" /var/log/maillog | tail -20

The error will reference the original sender's domain failing SPF, not your domain.

Fix: Enable SRS (Sender Rewriting Scheme) in Plesk

SRS rewrites the envelope sender address to your own domain during forwarding, making SPF pass at the destination. Plesk supports SRS via the Postfix SRS module:

# Check if postsrsd is installed
rpm -qa | grep postsrsd   # CentOS/RHEL
dpkg -l | grep postsrsd   # Debian/Ubuntu

# Install postsrsd if missing
yum install postsrsd   # CentOS/RHEL
apt install postsrsd   # Debian/Ubuntu

After installing, configure Postfix to use it by adding to /etc/postfix/main.cf:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Then reload: postfix reload && systemctl restart postsrsd

Alternative Fix: Use Plesk's Built-In SRS Setting

In newer Plesk versions (Obsidian and later), SRS can be enabled via the admin panel: Tools & Settings > Mail Server Settings > SRS (Sender Rewriting Scheme). Enable it and save.

Root Cause 3: SpamAssassin or Amavis Blocking the Forwarded Email

If the forwarded email arrives at your server with a high spam score, SpamAssassin or Amavis may mark it as spam or drop it before it is forwarded. This is common with marketing emails, automated notifications, or newsletters being forwarded to an external address.

# Check Amavis/SpamAssassin activity
grep "Blocked SPAM\|spam\|X-Spam-Status" /var/log/maillog | tail -30

# Check the Amavis quarantine directory
ls /var/virusmails/ | tail -20

Fix: Whitelist the Forwarding Address in SpamAssassin

Add a whitelist rule in /etc/mail/spamassassin/local.cf:

whitelist_from *@senderdomain.com
whitelist_to destination@gmail.com

Then reload SpamAssassin: systemctl restart spamassassin

Root Cause 4: "Keep a Copy" Setting Causing Quota Issues

If "Keep a copy of each message in this mailbox" is enabled and the mailbox quota is full, Plesk's mail delivery attempt to the local mailbox fails — and in some configurations, this causes the entire forwarding action to abort, meaning the external forward never happens either.

# Check mailbox quota usage for the forwarding address
/usr/local/psa/bin/mailmng --get-settings --mailname=email@yourdomain.com

Solutions:

• Increase the mailbox quota in Plesk > Mail > Email Addresses > Mailbox tab
• Disable "Keep a copy" if you don't need local copies
• Enable autoexpiry or set up IMAP cleanup rules to prevent the mailbox from filling up

Root Cause 5: Forwarding Destination Is Blacklisting Your Server IP

Some corporate email servers and security appliances block forwarders from hosting IPs that appear on spam blacklists. Even if your server is not globally blacklisted, specific destination mail servers may have local policies against hosting providers.

# Check if your server IP is on common blacklists
dig +short TXT $(echo "YOUR_IP" | awk -F. '{print $4"."$3"."$2"."$1}').zen.spamhaus.org

If your IP is listed, follow the standard delisting process for that blacklist (Spamhaus, Barracuda, MXToolbox). Consider using a dedicated IP with clean reputation for outbound email if this is a recurring issue.

Verify Forwarding Is Working After Fixes

After applying fixes, send a test email from an external address (not your own server) to the forwarding address and watch the log:

tail -f /var/log/maillog

A successful forwarding sequence looks like:

postfix/smtpd: ... status=queued
postfix/qmgr: ... status=forwarded
postfix/smtp: ... status=sent (250 OK)

If the destination is Gmail, allow 2–5 minutes for the forwarded message to arrive. Check the spam/junk folder if it doesn't appear in the inbox.

Managing email forwarding for multiple clients across dozens of domains requires careful Postfix and anti-spam configuration. CloudHouse's server management team handles Plesk mail server configuration, SRS setup, and deliverability troubleshooting as part of ongoing server support.

FAQs