Email Forwarding
Route incoming email from official addresses to officers, shared mailboxes, or department systems.
Email forwarding lets you receive email at addresses on your government domain and automatically route it to one or more destinations. For example, forward support@health.go.ke to a help desk mailbox and a case-management webhook.
Prerequisites
Two things must be true before you can create a forward:
- The domain is verified for sending. See Domain Setup.
- The domain's MX record points to Taifa Mail. Verifying a domain for sending does not add an MX record, so you usually need to add this separately.
| Record Type | Name | Value | Priority |
|---|---|---|---|
| MX | @ (root domain) | mx1.govconnect.ke | 10 |
Changing MX records affects where all email for your domain is delivered. If you currently receive email through another provider such as Google Workspace or Microsoft 365, adding Taifa Mail MX records will redirect incoming mail away from that provider. Plan your migration carefully.
Setting up a forward
- Go to Forwarding in the sidebar.
- Click Add Forward.
- Choose the domain the forward belongs to. It must be a verified domain on your account.
- Enter the source address - the address on that domain that receives mail, for example
support@health.go.ke. The address's domain must match the chosen domain. - Enter one or more destinations (see below).
- Click Save.
The source address does not need to be an allocated mailbox - it only needs to be on a verified domain. Each source address can have one forwarding rule; adding a second rule for the same source is rejected.
Forwarding rules take effect once your MX record has propagated.
You cannot create a forwarding rule until the domain's MX record points to Taifa Mail. The app checks this when you add a forward and blocks the rule if no MX record routes the domain's mail to Taifa Mail - incoming mail would never reach Taifa Mail otherwise.
Destinations
A forward can deliver to two kinds of destination:
- Email address - the message is relayed on to that mailbox with the original headers preserved.
- HTTPS URL - the message is delivered to a URL as an HTTP request, so your application can process inbound mail programmatically (webhook-style).
A forward needs at least one destination, and a single rule can mix both kinds; every destination receives a copy. A rule can list up to 5 email addresses (case-insensitive duplicates are dropped) plus any number of HTTPS URLs. HTTPS destinations must be public URLs: internal or private addresses are rejected.
How it works
When an email arrives at support@health.go.ke:
- Taifa Mail's mail server accepts the incoming message.
- The forwarding rule matches the recipient address.
- The message is forwarded to each destination address with the original headers preserved.
- A forwarding log entry is created.
Managing a forward
You can update a forward's destinations or toggle it on or off without deleting it. A forward must always keep at least one destination - clearing every destination is rejected. Deleting a forward removes the rule entirely.
Forwarding vs. the inbox
Forwarding relays incoming mail on to an external destination. If instead you want to read incoming mail inside Taifa Mail, use the Inbox. Both can run at once - a message can be stored in the Inbox and forwarded.
Viewing forwarding logs
On the Forwarding page, open the logs to see a list of all forwarded emails. Each log entry records:
- The original sender (
from) - The source address the mail arrived at (
original to) - The destination it was forwarded to (
forwarded to) - The subject line
- The message size
- The timestamp
You can filter the logs by a specific forwarding rule. Logs are paginated.
Forwarding stats
The Forwarding page also shows stats for the last 30 days: the total number of emails forwarded this month, and a breakdown of how many each forwarding rule handled.