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

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 <SRS0=hash=domain.com=user@meudominio.com.br>: 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

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.

This post is licensed under CC BY-NC.