solution proposed

The solution proposed by this site aims at fixing email forwarding by introducing forwarding agreements as a counterpart of forwarding recipes.

Outline

On the receiver side, an agreement is a record keyed on the pair <recipient, list-id>. On the sender side, this can correspond to a static dot-forward file, or to a recipient record of a newsletter or mailing list. Note that dot-forward recipes traditionally don't provide for setting a List-Id:. This involves synthesizing a list-id value and inserting it in a List-Id: header field in each forwarded message, replacing any such field already present.

One agreement is required for each recipient and for each subscription. For example, if sender A manages one mailing list and two newsletters, and two recipients of receiver B subscribe to each, then B will store six agreements for A, just like A has six recipes for B.

Senders authenticate via ARC or DKIM. After verifying the signature, receivers verify the existence of <recipient, list-id> in the agreement database and exempt the message from DMARC disposition requests.

Agreements can be obtained fully automatically. This means that a compliant sender can determine whether the destination MTA supports this solution and, if possible, automatically use it.

Agreements can be renegotiated by the recipient at any time. Renegotiation and user queries can be made fully automatic and (where applicable) recursive.

Implementing this solution requires changes on both the sender and the receiver sides. Senders must modify the settings to add new destination addresses. Mailing lists can then suppress the rewriting of the From: field for authorized mail flows. Dot-forwarders must set a List-Id: on forwarded messages.

Authorizing a sender

A receiver sets up a DNS TXT resource record and a web form in order to receive authorization requests.

DNS resource record

An underscored _fixforwarding record, in the tag=value syntax defined by DKIM (RFC 6376).

It has two mandatory tags:

v=fixforwarding

Used to verify the type of TXT record.

post=http url

Pointer to the web form.

And two optional tags:

auth=sig type

The authentication method, arc, dkim, or some other signature type. The default is arc.

dnswl=list

Either a comma-separated list of DNSWLs (see RFC 5782) that the receiver's MXes consult before rejecting SPF failures at the early stages of SMTP transactions, or one of the keywords none, which means forwarders must change the bounce address to an SPF valid one, and all, which means forwarders may leave the original bounce address intact because the receiving domain's MXes never reject messages before verifying their signatures. The default is none.

Web form

Web form pointed by the post tag

Forwarders request authorization by sending the receiver a web form. The form contains nine mandatory fields.

domain

The requesting domain. This domain is expected to match the d= tag of the DKIM-Signature: or ARC-Seal: and ARC-Message-Signature: header fields. It must also match the final labels of the list-id.

abuse

Email address of the anti-abuse team or similar entity, to which complaints can be sent regarding behavior by the forwarder that the recipient considers inappropriate.

agreement-id

A globally unique string that identifies a request and its associated agreement. It has the same syntax as a Message-ID header field, ag-id-left@ag-id-right, where ag-id-right ends with the requesting domain.

list-id

The value of this field must appear in the List-Id: header fields of forwarded messages. Recall that the format is List-Id: Description of the purpose <list-id>, where list-id also ends with the domain name (see RFC 2919)

The transistor metaphor likens a message path controlled by the forwarder

base

Email address for managing this agreement. It will receive messages indicating whether authorization has been granted, requests to verify whether forwarding is still active, and similar administrative functions. This is the first of three fields named after the transistor metaphor.

collector

The address to which the forwarder receives messages to be forwarded. This is the List-Post: address for mailing lists or the forwarded address leading to a dot-forward recipe. Newsletters or backup MXes populate this field with the keywords type=news or type=mx respectively.

emitter

The target email address. This is the subscribed address of a mailing list or newsletter or the destination address of a dot-forward recipe. MXes use an asterisk, like *@example.com.

text

Free text describing the reasons or circumstances of the forwarding. It is intended to be presented to the user by the receiving domain when asking for confirmation. It must not exceed 4K and must not contain HTML tags or HTTP or HTTPS links.

Agreement management

The receiver controls the forwarding by sending messages to the base address. These messages define the status of the forwarding agreement, as determined by the receiving domain. The forwarder must respond, affirmatively or negatively, to the messages. If the message is undelivered or not responded to, the receiving domain should resend the message one or two more times. After a few days without a response from the forwarder, the agreement can be considered stale and removed.

A forwarder has no other way to communicate cancellation other than replying negatively or not at all to a renewal request.

Messages are regular text/plain messages with the subject and the first two lines of the body formatted like this example:

DKIM-Signature: v=1; a=rsa-sha256; d=receiver domain; ...
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 24 Oct 2025 03:00:51 -0700
Message-ID: <d25e28865.35e4bf86@receiver.domain>
MIME-Version: 1.0
From: Mailbox provider of subscriber <agreement-id@receiver.domain>
To: Base address for this agreement <whatever@forwarder.domain>
Subject: [FixForwarding] <ag-id-left@ag-id-right>: message-type
 
agreement-id: <ag-id-left@ag-id-right>
deal: message-type
Any other text...

where message-type is one of five possible deals:

base-check

The receiver simply verifies that the address exists.

acceptance

The receiver accepts the agreement. From the moment this message is received, messages can avoid From: munging and, if allowed by the receiving domain, avoid rewriting the bounce address.

rejection

The receiver rejects the agreement. The forwarding itself should be questioned. The forwarder should interact further with the user before attempting a new request.

renewal

The receiving domain needs confirmation that this forwarding mechanism is still active.

cancellation

The agreement is cancelled. For mailing lists, the user should be unsubscribed if not already done. For dot-forward, the alias should be removed.

Forwarder responses are also plain text messages, sent according to the From: or Reply-To: fields as usual. There are positive or negative responses. Negative responses have NO as the first line of the body and the first word of the subject. No responses or bounces are considered negative responses. Any other response is a positive acknowledgements of the message.

Cancellation and rejection responses have the same effect, regardless of whether they are positive or negative; that is, either party can remove any reference to the agreement. Negative acceptance responses should not occur unless the web request was a forgery. Renewal messages, on the other hand, expect a negative response to eventually end terminate agreement.

Both forwarders and receivers can manage agreements manually or automatically, depending on their volumes.