When a company's name is on freezers in every major supermarket across Pakistan, the last thing it can afford is an email leak.
MENU is the ready-to-cook and ready-to-eat brand from Seasons Foods Pvt. Ltd., part of the Seasons Group of Companies. Seasons spent over two decades building out poultry and cattle feed production, breeder and broiler farms, flour milling, and edible oil before launching Seasons Foods in 2006, completing a supply chain the group had already spent years building. Today, MENU uses that infrastructure to produce halal frozen chicken, ready-to-cook meals, and ready-to-eat products for households across the country.
Running a business at that scale means running a lot of email. And that's where MENU came to us with a very specific problem: only pre-approved addresses should be able to send messages outside the company's domain, and their existing setup couldn't hold that line.
A Policy Their Old Setup Couldn't Enforce
MENU reached out through a referral from an existing customer, already hosting with us on a VPS. Their request wasn't about uptime or speed. It was about drawing a firm boundary between internal and external email.
Only specific, authorized employees should be able to send email to recipients outside the organization. Everyone else needed to be restricted, and not only in the To field. An unauthorized employee could just as easily add an external address in CC or BCC, quietly bypassing a rule that only checked the primary recipient. MENU needed the same restriction to hold across all three fields.
Their existing configuration had no way to make that distinction. It could accept or reject a message, but it couldn't tell an approved sender from an unapproved one trying to reach an outside address through a side door. For a food brand handling supplier contracts, distributor communications, and internal data, that gap was a genuine security exposure, not a hypothetical one.
Implementing the Policy at the Server Level
Once we understood exactly how MENU wanted their email to behave, our technical team went into the email server configuration already running on their VPS and built the policy directly into it, rather than layering another tool on top. That meant:
Creating an allowlist of the specific email addresses cleared to send outside MENU's domain
Writing custom scripts to enforce that allowlist at the server level, instead of relying on manual oversight
Extending the same restriction to the CC and BCC fields, closing the loophole their old system left open
Testing the configuration against real sending scenarios to confirm authorized users could still communicate externally while everyone else was blocked, in every field
None of this came off a shelf. A standard mail server doesn't know which employees at a given company should be authorized to communicate outside the organization; that distinction had to be built specifically around MENU's own team structure. The result is a policy that runs automatically, without anyone in IT manually checking outgoing messages.
What Changed Once it Went Live
With the new configuration in place, MENU can say with certainty who is allowed to send email outside the organization and who isn't. Authorized users send externally as they always did; everyone else is blocked, across To, CC, and BCC alike. The rule holds everywhere at once, and it holds on its own; no manual monitoring required to keep it that way.
MENU shared their feedback after the rollout:
"The team quickly understood our requirements and delivered a customized solution that worked exactly as expected. Their technical expertise and prompt support helped us resolve our email restrictions efficiently."
Why the Custom Route Was the Right One
We could have pointed MENU toward a generic mail security add-on and called it done. It would have been faster to set up. But it wouldn't have solved their actual problem, because their requirement; precise, field-by-field control over who can send externally isn't something a standard mail security solution is designed to handle.
Instead, we treated it as what it was: a business-specific policy that needed to live inside the server itself. Combining the VPS infrastructure MENU already had with custom scripting and an authorized-sender allowlist gave them a solution built around how their organization actually works, not around what a generic template assumes every company needs.
For a company processing food at MENU's scale, with contracts, suppliers, and internal data to protect, that difference is the whole point of custom infrastructure work: it should adapt to the business in front of it, not the other way around.
