iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Most Postfix forwarding failures come from one of four causes: the address is configured in the wrong alias system, the lookup database was not rebuilt, the domain has the wrong destination role, or remote SMTP delivery failed after Postfix accepted the message. Identify which mechanism owns the recipient, verify the effective configuration and indexed map, reload Postfix, then follow one test message by its queue ID through the logs. This separates an alias lookup problem from a relay-policy, DNS, or remote-server problem without weakening your relay controls.
First identify what kind of forwarding you configured
Postfix has two commonly confused forwarding mechanisms. Local aliases and ~/.forward files apply to recipients that Postfix treats as local users. Virtual aliases apply to complete addresses in virtual alias domains. The syntax, domain settings, database rebuild command, and troubleshooting path differ.
| Aspect | Local aliases or .forward |
Virtual aliases |
|---|---|---|
| Recipient key | Usually a localpart such as help; the domain is a local destination. |
Full address, such as help@example.com. |
| Typical configuration | /etc/aliases plus newaliases, or a user’s ~/.forward. |
virtual_alias_domains and virtual_alias_maps. |
| Domain declaration | The recipient domain is normally in mydestination or another local-destination class. |
The forwarding domain belongs in virtual_alias_domains, not in mydestination. |
| Map entry example | help: recipient@remote.example in an aliases file. |
help@example.com recipient@remote.example in a virtual table. |
| Lookup behavior | Local alias expansion follows local delivery rules. | Virtual alias lookups use complete addresses and can expand recursively. |
| Verification | Run newaliases after editing /etc/aliases; inspect local delivery logs. |
Run postmap after editing the virtual table, verify with postmap -q, then reload and test. |
Do not put a virtual-domain address in /etc/aliases and expect the virtual map to find it. Conversely, adding a local account to virtual_alias_maps does not make that account a virtual-domain recipient. Decide the intended scope before changing a file.
Check Postfix’s effective settings before editing files
Configuration snippets can be misleading when a later parameter, a distribution default, or a map type overrides them. Ask the running Postfix installation what it actually uses:
#1 Best Overall
postconf myhostname mydestination virtual_alias_domains virtual_alias_maps
postconf relay_domains smtpd_relay_restrictions smtpd_recipient_restrictions
postconf -nThe first command displays the destination and alias parameters most relevant to forwarding. postconf -n prints non-default settings and is useful for spotting an unexpected override. Run these commands as an administrator and compare the output with the address you are testing.
- Confirm the forwarding domain appears in
virtual_alias_domainswhen you intend virtual-domain forwarding. - Confirm
virtual_alias_mapspoints to the table you are editing, including its lookup type such ashash:,lmdb:, or another type supported by your installation. - Check that the same domain is not also listed in
mydestination. A domain classified as local and virtual at the same time can produce loops or unexpected local-recipient errors. - Check whether
relay_domainsor relay restrictions are affecting the SMTP client that submits the message. Forwarding for your own hosted domain is different from allowing arbitrary clients to relay through the server.
Use the exact configured path in every subsequent command. A frequent mistake is rebuilding /etc/postfix/virtual while virtual_alias_maps actually points to a different file or database.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Configure and verify a virtual alias correctly
1. Declare the virtual alias domain
For a domain whose addresses should forward without corresponding Unix accounts, add the domain to virtual_alias_domains. The setting can be a space-separated list or a lookup table, depending on your design. A simple main.cf example is:
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtualReplace the domain and map path with your own values. Do not list example.com in mydestination at the same time. The Postfix Virtual Domain Hosting Howto states this unambiguously: “NEVER list a virtual alias domain name as a mydestination domain!”
2. Use a full-address key in the table
Put one mapping per line in the source table. Separate the key and one or more recipients with whitespace:
Rank #2
support@example.com support-team@remote.example
sales@example.com alice@remote.example,bob@remote.exampleThe left side must match the address Postfix looks up, including its domain. An entry for support does not reliably replace support@example.com in a virtual alias table. Keep comments on separate lines beginning with #, and remove invisible formatting or typographic quotation marks copied from a web page.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute3. Build the indexed map after every edit
A hash: or similar indexed map is not read directly from the text file for each delivery. Rebuild it:
postmap /etc/postfix/virtualIf the configured map uses another path or type, use that path and the corresponding postmap syntax. Editing the source file without running postmap leaves the old database in place, so Postfix continues to behave as if your change never happened.
4. Query the map before sending mail
Test the exact key and map specification:
postmap -q "support@example.com" hash:/etc/postfix/virtualA successful query prints the destination. No output means the key was not found in that database; check spelling, case, whitespace, the domain, and whether you rebuilt the map. If the command reports a database or permission error, fix that before testing SMTP.
5. Reload, then send one controlled message
postfix check
postfix reloadpostfix check catches several ownership, permission, and syntax problems. A reload makes changed parameters available to new deliveries without stopping the service. Send one message to the exact left-hand address and record the queue ID from the log or the sending client.
When local aliases or forward files are the right tool
System aliases
Use /etc/aliases for local recipients such as system addresses. A typical entry is:
postmaster: admin@remote.example
security: rootAfter editing, rebuild the aliases database:
newaliasesThen send a test to the local address and inspect the local delivery log. The address is interpreted in the context of a local destination domain; this is not a substitute for a full-address virtual mapping.
User ~/.forward files
For a Unix user’s personal forwarding, place the destination address in that user’s home-directory .forward file. Ensure the file is readable by the delivery process and that the home directory permissions allow traversal. A misowned file, a world-writable home directory, or a security policy such as SELinux can cause Postfix or the local delivery agent to ignore it. Check the relevant local-delivery log rather than assuming the virtual map is broken.
Use one mechanism for each address where possible. Having an entry in /etc/aliases, a .forward file, and a virtual alias for the same recipient makes the expansion chain harder to reason about.
Free tools Windows power users keep installed
One-click scans. No signup required.
Follow one message through the delivery pipeline
Testing in layers prevents you from treating every failure as an alias problem. Use this order:
Rank #4
- Inspect the map. Run
postmap -qfor the exact recipient and verify the configured map path withpostconf virtual_alias_maps. - Validate and reload. Run
postfix check, thenpostfix reload. - Submit one message. Use a controlled sender and one recipient. Avoid repeated retries while diagnosing; they make the log harder to read.
- Capture the queue ID. Find the ID in the SMTP submission response or the mail log. It is the key that ties cleanup, queue manager, alias expansion, and delivery lines together.
- Read the logs. Debian and Ubuntu commonly use
/var/log/mail.log; Red Hat-family systems commonly use/var/log/maillog. Systems using systemd may show the same events withjournalctl -u postfix. - Check the queue. Use
postqueue -pto list deferred mail. Inspect a specific queued message withpostcat -q QUEUE_ID. Do not delete a message until you understand why it is deferred.
In a normal virtual forwarding path, log lines identify services such as cleanup, qmgr, virtual, and smtp. The virtual delivery-agent documentation describes the status information exposed by these paths. An alias expansion proves that Postfix found a destination; it does not prove that the remote SMTP server accepted it.
| What the log shows | Likely location of the problem | Next check |
|---|---|---|
| No queue entry or immediate recipient rejection | SMTP policy, destination classification, or recipient lookup. | Inspect relay restrictions, domain roles, and the exact map query. |
| Original address expands to the remote address | Alias lookup is working. | Follow the subsequent smtp delivery result. |
| Message remains deferred with a remote SMTP status | DNS, connectivity, TLS, rate limiting, or remote policy. | Read the complete SMTP diagnostic and test the destination independently. |
| Bounce generated after acceptance | Final delivery failed after Postfix accepted the message. | Use the queue ID and bounce text; do not rebuild an already verified alias map without evidence. |
Fix “Relay access denied” without creating an open relay
“Relay access denied” usually means Postfix does not consider the requested destination locally deliverable and the submitting client is not authorized to relay. First determine whether the message is supposed to be accepted for a domain you host or whether a remote client is trying to use your server to send elsewhere.
- If the destination is your virtual forwarding domain, add that domain to
virtual_alias_domainsand ensure the alias map contains the full recipient address. - If the sender is an authenticated submission client, verify the submission service’s SASL authentication and the relay restrictions that permit authenticated users.
- If the sender is an internal trusted network, verify the narrowly defined network policy rather than permitting all Internet clients.
- Check for a typo in the recipient domain. A domain that is not declared as local or virtual is correctly treated as a relay destination.
Do not solve the error by setting a broad permit rule or disabling relay restrictions. The Postfix SMTP relay and access-control guidance warns: “On today’s Internet, spammers abuse servers that forward mail from arbitrary systems, and abused systems end up on anti-spammer denylists.” Keep restrictions enabled and authorize only the destinations and clients you actually operate.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Fix “mail loops back to myself”
This error means Postfix delivered or attempted to deliver the message to a host that resolves back to itself, without a valid terminating local or virtual recipient. The most common configuration cause is listing a virtual alias domain in mydestination, which conflicts with the virtual-domain role.
- Run
postconf mydestination virtual_alias_domains myhostnameand look for the forwarding domain in more than one destination class. - Remove the virtual alias domain from
mydestinationwhile retaining it invirtual_alias_domains. - Verify that DNS for the domain points to the intended inbound host and that the host’s name is not being used as an accidental forwarding target.
- Rebuild the map, reload Postfix, and send a new test rather than relying on a previously queued message.
Virtual alias expansion is recursive. The Postfix virtual(5) manual states: “Virtual aliasing is recursive; to terminate recursion for a specific address, alias that address to itself.” In practice, avoid chains that point back to an earlier address; if a deliberate self-terminating alias is required, document it and test the resulting local delivery behavior.
Fix unknown-recipient bounces and missing forwards
An unknown-recipient response generally means Postfix could not find the address in the active recipient map or the domain is not classified as a destination it accepts. Check the full address, not just the localpart:
- Query
postmap -q "user@example.com"against the exact map named byvirtual_alias_maps. - Confirm the source table uses ordinary ASCII characters and has no trailing characters in the key.
- Run
postmapagain after every edit. Verify the database file’s timestamp changes and that the Postfix user can read it. - Check whether a catch-all or other map is being consulted before or after the expected map; the effective parameter output is authoritative.
- Confirm that the recipient domain is the one declared in
virtual_alias_domains, including the correct spelling and any required subdomain.
If the map query succeeds but SMTP still rejects the recipient, the rejection is occurring later in the restriction or delivery path. Use the queue ID to locate the first error line rather than changing unrelated alias entries.
When Postfix accepts the message but the remote mailbox never receives it
Successful alias expansion only changes the envelope recipient. The subsequent remote SMTP transaction can still fail. Read the smtp service’s status for a response code and diagnostic text, then classify the failure:
- Temporary 4xx response: the message is normally deferred and retried. Check
postqueue -pand the retry timing before forcing repeated deliveries. - Permanent 5xx response: the remote server rejected the message. The diagnostic may identify an invalid recipient, policy block, authentication requirement, or reputation issue.
- DNS or connection failure: verify the destination’s MX records, resolver configuration, firewall egress, and TLS requirements.
- Content or authentication policy rejection: forwarding can alter the relationship between the original sender and your server. SPF, DKIM, DMARC, and Sender Rewriting Scheme behavior depends on your mail flow and provider; consult current receiving-provider and Postfix documentation before deploying a policy change.
Do not repeatedly edit the alias map when the log already shows that Postfix handed the message to the remote SMTP service. At that point the forwarding lookup worked; investigate the remote response and your outbound identity.
Direct forwarding versus a relay host
Postfix can deliver forwarded mail directly to the recipient domain’s MX hosts or send it through a configured relay host. These are different delivery designs, not interchangeable fixes for a missing alias.
| Decision axis | Direct forwarding | Relay-host delivery |
|---|---|---|
| Destination control | Postfix looks up and connects to each recipient domain’s MX records. | A designated smarthost receives outbound mail and performs onward delivery. |
| Sender authentication | Your server’s hostname, IP reputation, TLS, and message authentication are exposed directly to recipient servers. | The relay provider’s credentials, policies, and sending infrastructure govern the onward SMTP transaction. |
| Observability | Your logs show the final remote SMTP response directly. | Your logs show the handoff to the relay; final rejection details may appear in the relay’s portal or returned status. |
| Typical reason to choose it | You operate the server’s DNS, outbound connectivity, and mail reputation. | Your network blocks direct SMTP, or an organization centralizes outbound delivery and policy. |
Changing to a relay host does not repair a wrong virtual_alias_domains entry or an unindexed map. Fix recipient classification and expansion first, then choose the outbound route based on operational requirements.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsSecurity and operational safeguards
- Limit aliases to intended recipients. Avoid an unrestricted catch-all that turns every typo or hostile probe into outbound traffic.
- Keep
smtpd_relay_restrictionsand related recipient restrictions enabled. Permit authenticated or explicitly trusted clients, not arbitrary Internet senders. - Monitor queue growth and repeated delivery failures. A sudden increase can indicate a forwarding loop, compromised credentials, or abuse of a valid alias.
- Protect map files and their generated databases with ownership and permissions that allow Postfix to read them but prevent untrusted users from changing destinations.
- Document which domains are local, virtual alias, or relay domains. Ambiguous ownership is the root of many “relay access denied” and loop incidents.
- Test with a single controlled message after each material change and retain the queue ID and relevant log lines for rollback or support.
A compact recovery checklist
- Write down the exact recipient address and the mechanism intended: local alias,
.forward, or virtual alias. - Run
postconf mydestination virtual_alias_domains virtual_alias_maps relay_domains. - Ensure a virtual forwarding domain is not also in
mydestination. - Inspect the configured table and confirm a full-address key such as
user@example.com. - Run
postmapon the configured source table, then verify withpostmap -q. - For
/etc/aliases, runnewaliases; for a.forwardfile, check ownership, permissions, and local-delivery policy. - Run
postfix checkandpostfix reload. - Send one test message and record its queue ID.
- Read the cleanup, queue-manager, alias, virtual, SMTP, bounce, or error log lines associated with that ID.
- Only after local expansion is confirmed, troubleshoot DNS, connectivity, TLS, remote policy, or forwarding authentication behavior.
- Remove or defer queued test messages deliberately; do not delete evidence before recording the failure.
This sequence keeps the diagnosis causal: map lookup first, domain role second, relay policy third, and remote delivery last. It also preserves the restrictions that prevent a forwarding server from becoming an abuse target.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
