Decoding the 550 error in email forwarding: SRS, Postfix, and destination false positives
Back to blog

Decoding the 550 error in email forwarding: SRS, Postfix, and destination false positives

6/7/2026 · 2 min · Email

Forwarding failures with 550 often look like local MTA issues, but many are generated on the destination side before SMTP traffic even reaches your Exim.

1) Observed symptom#

Typical error:

550 5.1.0 <[email protected]>: Sender address rejected: User unknown in virtual mailbox table

At the same time, direct messages from remote domain to your domain are missing from exim_mainlog.

2) Why SRS matters#

SRS rewrites sender identity to preserve SPF compliance across forwarding hops. Disabling SRS globally may solve one edge case but usually damages overall deliverability and anti-spam trust.

3) Diagnosing destination-side false positives#

If the error references virtual mailbox table, that is usually Postfix logic. If Exim has no inbound log, SMTP session likely never reached your server.

Most likely remote behavior:

4) Remediation strategy used#

A) Convert alias into physical mailbox#

Instead of forward-only alias, create a real mailbox in cPanel.

Benefits:

B) Requeue pending deliveries#

exiqgrep -r @dominio-destino.com.br -i | xargs exim -M

This retries stuck messages after routing adjustments.

5) Practical checklist#

  1. Validate local logs before assuming local fault.
  2. Infer remote MTA type from error vocabulary.
  3. Confirm DNS/MX externally with dig.
  4. Keep SRS enabled; avoid global disable as quick fix.

Not every 550 is your Exim failing. In SRS + remote Postfix scenarios, root cause is often destination-side local routing assumptions. Physical mailbox fallback, log correlation, and controlled queue retry solve the issue while preserving SPF trust and sender reputation.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

CC BY-NC

This post is licensed under CC BY-NC.

Comments

Join the discussion below.

0 comments