If you’ve ever run a multi-company Odoo database, you’ve probably dealt with the email server problem. Company A sends an invoice to a customer, but the message routes through Company B’s SMTP server because Odoo doesn’t know any better. The recipient’s mail provider sees a mismatch between the sender’s domain and the authenticated server, and the message lands in spam — or gets rejected outright. It’s a quiet infrastructure failure that erodes trust with every misrouted notification.
Odoo has addressed this with a new field on outgoing email servers called the From Filter. It’s a deceptively simple addition — a single text field — but it rewires how the entire outgoing mail system selects which server to use. The result is a five-step matching algorithm that automatically routes each email through the correct SMTP server based on the sender’s address, no manual intervention required.
The From Filter Field Explained
Every outgoing email server in Odoo now includes a From Filter field. You can populate it with either a full email address (like sales@company-a.com) or just a domain (like company-a.com). When Odoo prepares to send an email, it reads the “From” address on the message and compares it against the From Filter values configured on each available SMTP server. The server whose filter matches the sender address wins.
This means you no longer have a single global SMTP server handling all outbound mail regardless of who sent it. Each server can declare which addresses or domains it’s responsible for, and Odoo respects that declaration automatically. For organizations running two, five, or twenty companies in one database, this is the difference between emails arriving in inboxes and emails arriving in spam folders.
The field is optional. Servers with no From Filter set are treated as “unfiltered” — available to handle any email that doesn’t match a more specific server. This backward compatibility means existing single-company installations don’t need to change anything. The new behavior only kicks in when you start populating filters.
The Five-Step Matching Algorithm
Odoo doesn’t just check the From Filter and call it a day. It runs a hierarchical matching process with five distinct steps, ordered from most specific to least specific. Understanding this sequence is critical for anyone configuring a multi-company mail setup, because the order determines which server gets chosen when multiple candidates exist.
Step 1: Exact email match.Odoo first looks for a server whose From Filter matches the sender’s full email address exactly. If you’ve configured a server with the filterceo@company-a.com, and the outgoing message is from that exact address, Odoo picks that server immediately. This is the highest-priority match and overrides everything else.
Step 2: Domain match.If no exact email match exists, Odoo checks for servers whose From Filter matches the domain portion of the sender’s address. An email fromanyone@company-b.com will match a server filtered to company-b.com. This is the workhorse step for most multi-company configurations. Step 3: Unfiltered servers.If neither exact nor domain matching produces a result, Odoo falls back to servers that have no From Filter set at all. These “catch-all” servers handle whatever the filtered servers don’t claim. Step 4: Default fallback. If there are no unfiltered servers either, Odoo consults the mail.default.from system parameter and attempts to match that address against available servers. Step 5: First server by priority.When all else fails, Odoo simply picks the first available server based on priority ranking. This is the last resort, and it’s the scenario most likely to cause deliverability problems.
Why Domain Authentication Matters Here
The technical motivation behind this feature isn’t just organizational tidiness. It’s about email authentication protocols — specifically SPF, DKIM, and DMARC. When an email claims to be from sales@company-a.com but actually routes through an SMTP server authenticated for company-b.com, the receiving mail server runs its checks and finds a mismatch. The SPF record for company-a.com doesn’t list company-b.com’s SMTP server as an authorized sender. The DKIM signature, if present, is signed with the wrong domain’s key. DMARC alignment fails.
The result is predictable: the message gets flagged, quarantined, or rejected. In a multi-company environment without From Filter routing, this happens silently and repeatedly. Sales quotes don’t reach prospects. Invoice reminders vanish. Password reset emails never arrive. The business blames “email issues” without understanding that the root cause is a server selection problem inside the ERP.
With the From Filter in place, each domain’s emails route through the SMTP server that’s properly authenticated for that domain. SPF passes. DKIM aligns. DMARC reports come back clean. The emails land where they should.
Configuring a Multi-Company Setup
The practical configuration is straightforward. For each company in your database, you create a dedicated outgoing email server and set the From Filter to that company’s domain. Company A operates under company-a.com, so its SMTP server entry getscompany-a.com as the From Filter. Company B usescompany-b.com, and its server entry gets the corresponding filter. Repeat for every entity.
If a particular user or role needs a dedicated sending path — say the CEO’s emails must route through a server with different authentication or compliance logging — you can create a server with an exact email filter like ceo@company-a.com. That filter takes precedence over the broader domain filter due to the matching hierarchy. Every other user at company-a.com still routes through the domain-level server, while the CEO’s messages use the specialized one.
Priority matters when multiple servers share the same filter level. If you have two servers both filtered to company-a.com(perhaps a primary and a backup), Odoo selects the one with the lower priority number first. This mirrors how MX records work in DNS — lower numbers mean higher priority.
The Default Fallback and Why It Exists
Step 4 in the matching algorithm references the mail.default.fromsystem parameter, and it serves a specific purpose. In some configurations, Odoo rewrites the sender address on outgoing emails to a canonical address — particularly for notifications, automated messages, and system-level communications that don’t originate from a specific user. The mail.default.from parameter defines what that canonical address looks like.
When the original sender’s address doesn’t match any filtered server and no unfiltered server is available, Odoo uses the default from address as a second attempt at matching. This catches scenarios where automated workflows generate emails with addresses that don’t correspond to any configured filter. The system effectively asks: “If I rewrite this to the default sending address, does a server exist for that?”
If this fallback also fails, the system drops to Step 5 and grabs whatever server has the lowest priority number. This is intentionally the weakest match — a safety net to ensure emails still go out even if the configuration is incomplete. But administrators should treat a reliance on Step 5 as a configuration problem to fix, not an acceptable steady state. Emails sent through a mismatched server will continue to face deliverability issues regardless of how the content is written.
What Happens When Configuration Goes Wrong
The most common misconfiguration is forgetting to set From Filters entirely. In that case, all servers remain “unfiltered,” and Odoo picks the one with the lowest priority number for every outgoing email. This is functionally identical to the old behavior before From Filters existed — a single server handles everything. For single-company databases, this is fine. For multi-company databases, it’s the root cause of the deliverability nightmares described earlier.
Another subtle mistake is setting overlapping filters without considering priority. If two servers are both filtered to company-a.comwith the same priority, the selection becomes nondeterministic. Odoo will pick one, but you can’t predict which. This matters if the two servers have different capabilities — perhaps one supports TLS and the other doesn’t, or one has rate limiting that the other lacks. Always assign distinct priority values to servers sharing a filter scope.
A third issue arises when companies share a domain but use separate SMTP servers. If Company A and Company B both send from shared-domain.com, a single domain-level filter can’t distinguish between them. In this case, you need exact email filters for specific senders or a shared server that both entities can use without authentication conflicts.
The Broader Impact on Multi-Company Operations
Email routing might sound like a narrow infrastructure concern, but in a multi-company ERP, it touches everything. Sales teams send quotes. Accounting sends invoices and payment reminders. HR sends onboarding documents. Project managers send task notifications. Every one of these automated communications carries a sender address tied to a specific company, and every one needs to route through the correct server to arrive reliably.
Before this feature, administrators often resorted to workarounds — running separate Odoo instances per company, using a single catch-all domain for all entities, or manually configuring relay rules in external MTAs to compensate for Odoo’s inability to route intelligently. The From Filter eliminates the need for all of these. The routing logic lives inside Odoo, configured alongside the rest of the mail server settings, visible and auditable by anyone with system administration access.
For organizations evaluating whether to consolidate multiple companies into a single Odoo database, the From Filter removes one of the most persistent objections. The email infrastructure can now scale with the number of entities without degrading deliverability. Each company gets its own authenticated sending path, managed centrally, with clear priority rules governing how conflicts are resolved. It’s the kind of feature that doesn’t make headlines but quietly makes multi-company ERP deployments actually work.