I’m encountering an issue with email forwarding on a Virtualmin/Postfix setup and could use your help troubleshooting.
Problem:
We have a mailbox (let’s call it invoice@clientdomain.tld) configured to automatically forward incoming emails to an external bookkeeping address, like:
kotlin
KopiërenBewerken
clientid123@external.bookkeeping-service.tld
This works perfectly fine for all external senders. However, when we (the hosting provider) send an invoice email to that address, the message:
Bounces with:
kotlin
KopiërenBewerken
<clientid123@external.bookkeeping-service.tld> (expanded from <invoice@clientdomain.tld>): too many hops
<"invoice@clientdomain.tld"@ourmailserver.tld>: too many hops
And often remains stuck in the mail queue with a deferred status, referencing a host ospito.net, which we do not recognize or use anywhere in our configuration.
Setup:
Outgoing mail is sent from a Virtualmin-managed Postfix server (mail.ourdomain.tld).
The local mail server also handles MX for clientdomain.tld.
SPF record for clientdomain.tld:
ini
KopiërenBewerken
v=spf1 a mx ip4:our.outgoing.ip ?all
What I’ve tried:
Verified that forwarding is only happening once in .forward or aliases.
Confirmed no loops in the transport or virtual maps.
External senders have no issues — only mail coming from our infrastructure gets rejected.
Checked postfix logs — the message often defers with a DNS query to ospito.net before eventually failing.
No known reference to ospito.net in our DNS, postfix config, or aliases.
Questions:
Could this be a misconfigured SRS (Sender Rewriting Scheme) issue?
Why would our server even try to resolve ospito.net? Could this be a spoof or malware entry?
Could the way Postfix handles local forwarding combined with external redirection be causing a loop?
Has anyone seen anything like this, especially in combination with external forwarding addresses (e.g. to bookkeeping or invoice automation platforms)?
Any insights or guidance would be hugely appreciated.
I can’t really help without actual information I don’t think.
It sounds like a DNS misconfiguration, but it could also be that you’ve explicitly configured myhost, mydomain, mydestination, or myorigin, incorrectly (you pretty much can’t configure any of these correctly in a virtual hosting environment if you change them…so if you changed them, they’re almost certainly wrong and can cause a variety of confusing delivery issues).
I’m sorry I haven’t shared the actual domains here—on a public forum I prefer not to expose client details or reveal potential weak points. However, I’m happy to send all of the relevant DNS records, Postfix settings (myhostname, mydomain, mydestination, myorigin, transport and virtual maps, etc.) and log excerpts via private message or support ticket so you can see exactly how it’s configured.
From what I’ve gathered so far, the forwarding is defined only once, SPF is set to a simple v=spf1 a mx ip4:xxx.xxx.xxx.xxx ?all, and yet mails from our WooCommerce/Postfix instance defer with a lookup to an unknown host (ospito.net) before eventually bouncing “too many hops.” External senders never hit this problem, only our internal‑sent messages do.
If you—or anyone else—would be willing to review the full configs in private, I can share them right away. Otherwise, any additional ideas on what could trigger Postfix to query a mysterious domain or create a forwarding loop would be extremely welcome.
OK. This wasn’t mentioned before. I know NOTHING about the package but would have to think that the problem lies here. How does WooCommerce connect to Postfix?
Not that I’d trust it but Google’s unasked for but given anyway be default AI answer hurts my head.
Some search results indicate you need a WordPress plugin of some sort? If so, what plugin did you use?
It continues to be true that you need to check your DNS. Are all MX and A records resolving correctly for all hosts involved?
It seems obvious that one of the destinations has an MX record pointing to ospito.net, either directly or indirectly. That may have nothing to do with the too many hops errors.
And, any changes you have made to those my entries is almost certainly wrong.
You really need to stop repeating the same questions without specific details because we can’t do any of the lookups without seeing the exact/whole relevant log entry. So you’ll need to do those lookups.
What I would do, if I had anything to look up, is:
host -t MX domain.tld
And then follow up by looking up the name that resolves to, and so on. That gives you the path the mail is taking, and you can start narrowing down where the problem is. You need to isolate the problems and trace them to their root. That involves reading the logs, and checking your priors (you are assuming DNS is right, you need to check every record related to mail, you’re assuming nothing is supposed to be going to that name you don’t recognize without checking the MX records to know where it is coming from…none of this stuff is a mystery, you can know why mail is trying to go somewhere, you don’t have to guess and you should not waste your time guessing).
root@woozyface:/home/woozyface# host -t MX inkoop.mijnwefact.nl
inkoop.mijnwefact.nl mail is handled by 10 mail.wefact.nl.
inkoop.mijnwefact.nl mail is handled by 20 fallback2.ospito.net.
root@woozyface:/home/woozyface#
There you go. You found the explanation for ospito.net.
That is probably unrelated to the too many hops problem, but now you’ve removed one mystery from the situation and you can move on to figuring out the real problem.
I had the same problem at some stage. Here are notes to myself from then:
"I have reconfigured mail forwarding to use Usermin not Virtualmin because that uses Spamassassin (Virtualmin doesn’t, says a forum person). Forwarding works BUT also generates “too many hops”. My fix is to:
Use the virtual server owner
Add additional email addresses
Deliver to mailbox
In mailbox Usermin, check [Y] Yes, forward to @gmail.
Additional info you didn’t ask for: before this, I was having problems with gmail rejecting SOME of the emails with 550-5.7.1 low reputation.
I fixed this by rewriting the headers, see this thread:
“It is a hop itself to must do this but it worked!”
Absolutely — it took a few hops of its own to get here, but your workaround did the trick!
We ran into the same “too many hops” issue due to a fallback MX (fallback2.ospito.net) being triggered by delayed responses from the target domain (inkoop.mijnwefact.nl, part of a bookkeeping system). Even though our SPF and forwarding were correctly configured, Postfix would still enter a loop due to the external routing logic.
We tested your fix — and it worked!
Following your suggestion, we:
Switched from Virtualmin-level alias forwarding to direct delivery into the mailbox of the virtual server owner.
Configured forwarding from within Usermin instead (Settings > Mail Forwarding).
Left “Deliver to local mailbox” enabled and added the target address (in this case, the WeFact mailbox).
Since doing this, the messages are forwarded correctly, and the “too many hops” issue is gone. No more mail queue deferrals or unexpected DNS lookups.
Why it likely works:
Usermin-based forwarding introduces a proper delivery step before re-sending, which effectively resets the hop count and avoids header recursion. This likely bypasses the conditions that previously caused Postfix to loop.
Thanks again — sometimes community-shared workarounds are more effective than official docs. Your post helped us get our client’s invoicing back on track
We tested your fix — and it worked!