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:
- remote host treats your domain as local
- attempts internal delivery first
- fails local user lookup and returns
550 User unknown
4) Remediation strategy used#
A) Convert alias into physical mailbox#
Instead of forward-only alias, create a real mailbox in cPanel.
Benefits:
- more consistent callback verification response
- stronger protocol-level user existence signal
B) Requeue pending deliveries#
exiqgrep -r @dominio-destino.com.br -i | xargs exim -M
This retries stuck messages after routing adjustments.
5) Practical checklist#
- Validate local logs before assuming local fault.
- Infer remote MTA type from error vocabulary.
- Confirm DNS/MX externally with
dig. - 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:
This post is licensed under CC BY-NC.



Comments
Join the discussion below.
0 comments