Views:
Modify header address actions rewrite the address headers of a message when a Content policy rule is triggered. They are modify Content Filtering actions, available only in Content policies for Cloud Email Gateway Protection customers. Two actions are available:
Action
Direction
Rewrites
Modify header sender
Inbound
From and Reply-To headers
Modify header recipient
Outbound
To and Cc headers
Each action rewrites only the message header. The delivery envelope and routing are not changed, so the message still reaches its real recipients. You configure the rewrites in a mapping table. The new addresses do not have to belong to a domain you own. These actions rewrite the headers that the global Address modification page does not, so the two features do not conflict.
Note
Note
The rule runs in two stages. First, the Recipients and Senders setting is matched against the message's envelope address and decides whether the rule triggers. Then, once the rule triggers, the action rewrites any targeted header address that matches an entry in the mapping table, regardless of whether that header address belongs to the domain set in Recipients and Senders.
Set Recipients and Senders broadly (for example, Anyone) so the rule reliably triggers, and use the mapping table as the source of truth for which header addresses to rewrite.

Configure an action

  1. Create or edit a Content policy rule. Inbound for Modify header sender, or outbound for Modify header recipient.
  2. In Recipients and Senders, set the envelope match that triggers the rule (for example, Anyone).
  3. In Actions, enable Modify header sender or Modify header recipient.
  4. Add one or more mapping entries. For each entry, specify the Original Header Address and the New address.

Mapping table

Each action uses a mapping table of original and new addresses. For every targeted header address in a message, Cloud Email Gateway Protection looks up the address in the table and, on a match, rewrites it to the new address. Addresses that do not match any entry are left unchanged. The table columns are Original Header Address and New address.
An original entry can be an exact address or a domain wildcard (for example, *@example.com). The following combinations are supported:
Original
New
Result
Example
Exact address
Exact address
Replaces the matched address.
alert@smokescreen.io → dcy.alert@kotak.com
Domain wildcard
Domain wildcard
Keeps the local part; swaps only the domain.
*@sogei.internal → *@sogei.it
Domain wildcard
Exact address
Collapses every address in the domain to one address.
*@smokescreen.io → dcy.alert@kotak.com
An exact address mapped to a domain wildcard is not supported and is rejected when you save the policy.
  • A domain wildcard matches only addresses whose domain is exactly that domain. It does not match subdomains.
  • If an address matches both an exact entry and a domain-wildcard entry, the exact entry is used.
  • Each original address must be unique within the table.
  • The table is applied in a single pass, so a new address produced by one entry is not rewritten again by another entry.
  • You can add up to 50 entries per action. The table is paginated, and a message appears when it is full.

Behavior and limitations

Important
Important
For Modify header sender (inbound): rewriting the From address can cause the message to fail DKIM verification at downstream mail servers, and DMARC alignment against the new domain may also fail. Cloud Email Gateway Protection verifies inbound authentication before the action runs, so its own verdict is not affected, and it does not re-sign inbound messages. This is an expected limitation.
For Modify header recipient (outbound): the rewrite happens before Cloud Email Gateway Protection signs the message, so the signature covers the rewritten To and Cc headers and stays valid. Outbound authentication is not affected.
Reply routing (inbound): because both From and Reply-To are rewritten, replies go to the new address instead of the original sender. Make sure you have a mailbox or forwarding rule for every new address in the mapping table.
To leave digitally signed or encrypted inbound messages unchanged, enable Do not modify digitally signed messages.
These actions rewrite only the targeted headers. Addresses shown in a notification or a stamp are not rewritten; update that content manually if the new address is required there.