Demo
Demo

Knowledge base

PMTA knowledge base›Block <rewrite-list>›Directive§ 3.3.18.2

from-domain

<rewrite-list>

A rule for replacing the domain in the From header
in the configuration this is a linefrom-domaininside the block <rewrite-list>
What domain the recipient sees

A line of two domains: a pattern and a replacement. It changes the domain in the From header — the only one of the two addresses the recipient sees in their mail program.

On the left is a domain pattern, on the right a specific name. from-domain *.port25.com bouncedomain.com turns foo@mail.port25.com into foo@bouncedomain.com: the local part is kept, the domain is replaced entirely.

This line does not touch the local part at all — unlike mail-from, where the whole address is rewritten.

The main trap is DMARC alignment. The DKIM signature and the SPF record are tied to a domain; by changing the domain in From, you changed the side DMARC checks alignment against. A message signed with an example.com key and presented to the recipient as bouncedomain.com fails alignment — and looks like someone else’s forgery.
What the Hub does. It does not write it: the Hub does not replace the From header at all. Only the envelope is rewritten — to receive bounces at its own processor — while the visible address remains the sender’s address. This is deliberate: replacing From pulls along the signing key and the SPF record of the new domain, that is, it moves all authentication onto it.
Recommended values

On the left a domain pattern, on the right a specific name. What will have to be done along with the replacement:

What Why
a signing key for the new domain otherwise DKIM is signed with the wrong domain, and DMARC will not align
an SPF record for the new domain if the envelope is rewritten to it too
a DMARC record for the new domain the policy is read by the domain in From

The rule is simple: the domain the recipient sees must be a domain you are responsible for in DNS. Otherwise the replacement turns your own message into someone else’s.

The form of the rule and the example come from the manual (§ 3.3.18.2). The list of what has to be done in DNS along with the replacement is ours.
Example configuration
# the recipient will see a different domain — with all the consequences for DMARC
<rewrite-list foo>
    from-domain *.port25.com  bouncedomain.com</rewrite-list>
An example from the manual: foo@mail.port25.com becomes foo@bouncedomain.com. That means both the DKIM signature and the DMARC policy must be on bouncedomain.com, not on the original domain.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Changing the domain in From while keeping the old signing key

our experience

What it costsDMARC checks the alignment of the signing domain with the domain in From. The old key signs with the old domain — alignment fails, and the message looks like a forgery of someone else’s domain.
How to spot itIn DMARC reports messages pass DKIM and fail alignment.
How to do it rightIssue a signing key for the new domain and sign with it — or do not replace From at all.

Expecting the rule to change the envelope too

§ 3.3.18.2

What it costsThe line touches only the header. Bounces keep arriving at the old return address, and the processor will not see them.
How to spot itFrom is new, but bounces arrive the old way.
How to do it rightThe envelope is rewritten with a mail-from line — a separate rule in the same list.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
from-domain <rewrite-rule>
Values
a domain pattern and a specific replacement domain name
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<rewrite-list>
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The rule has no inheritance: it applies inside its <rewrite-list> block. What is inherited is the reference to the list — the manual attaches it to <source>; references from <virtual-mta> and <virtual-mta-pool> are inherited in the usual order, where a member’s own line overrides the pool one.
⇄

Related directives

2 relations

Works together with

mail-from<rewrite-list>The neighboring line changes the envelope; this one what the recipient sees. § 3.3.18.2

Affects

domain-keyGlobalThe signature must match the domain the recipient sees — so after the replacement a key is needed for the new domain. § 3.3.1.55.1

How to check on the node
The header is not written to accounting — check it in a delivered message. Whether the signature matched the visible domain shows in DMARC reports:
dig TXT _dmarc.bouncedomain.com +short
The domain the recipient sees must have its own DMARC record — its policy is what the receiving server will apply. A missing record means the message is checked by default rules, not by yours.
◇

What else to read

3 articles

◇Do not send what will fail the check at the receiverThe node checks the SPF of its own mail before sending: if it fails, it bounces the message without waiting for someone else’s refusal.◇How the node signs messages and chooses a keyThe key is chosen by the sending domain from the headers, going through the declarations from top to bottom.◇A message header with which the submitting side adjusts the signatureFive parameters in X-DKIM-Options: selector, domain, signing identity, query method and key list.

In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Message signing and authentication
Neighboring settings of the block <rewrite-list>:mail-fromAll 2 directives of the block →