Automatic email forwarding is a standing mailbox rule that resends incoming mail to a second address. Forwarding to an account the reader controls is generally safe as a delivery mechanism, but it carries three consequences: a second stored copy under a second provider's rules, delivery of everything unless a filter narrows the rule, and changed results from the SPF, DKIM and DMARC checks on each message. This article covers a rule set by the account holder for personal mail, not a rule planted by an attacker, and not alias use for account recovery.
Forwarding scope and setup
An automatic rule and a manual forward are different operations: a manual forward builds a new message from the forwarder, with the original content quoted inside it, while an automatic rule resends the original message itself to a second mailbox, with the visible From header normally left as the original sender wrote it.
Scope is a separate choice. A blanket rule sends every message that arrives, while a filtered rule sends only messages matching stated conditions, such as a sender address or a subject keyword. Most providers place the blanket setting and the filter settings in different screens, so switching off the blanket setting does not necessarily switch off a filter that also forwards mail.
Stored copies in two mailboxes
Duplication is the most concrete consequence of forwarding: each message ends up stored twice, once in the original mailbox and once in the destination mailbox, each under its own provider's rules for retention, access and handling of legal requests. Sending sensitive mail to a provider with weaker retention or broader scanning moves that mail into a weaker store, so the destination inbox needs the same level of trust as the original.
Forwarding adds no encryption, and it leaves the original copy in place unless the account holder selects an archive or delete option for it. A destination provider can read stored mail under the same conditions as any mailbox provider: transport encryption protects mail while it travels, while stored mail is readable by a provider that holds the storage keys, as described in the AliasFleet article on whether a provider can read stored mail.
Duplication also changes what deletion achieves: deleting a message in one inbox leaves the forwarded copy in the other untouched, so a migration still needs the audit described in the AliasFleet guide to deleting an old account. A forwarded copy is not a backup either, because it sits inside a live account that can be locked, deleted or changed, while a real backup is an export held outside any live account, as described in the AliasFleet backup guide.
Authentication effects
Forwarding alters the verdicts produced by SPF, DKIM and DMARC. SPF checks whether the connecting server is authorised to send for the envelope sender domain, and a forwarder resends from its own IP address, which is not listed in the original sender's SPF record, so SPF fails for the original domain. The failure is a property of the design, not a fault in the forwarder. These indirect-flow problems are documented in RFC 7960 on DMARC and indirect email flows, published in September 2016, which lists forwarding, aliases, mailing lists and gateways as flows where a message does not travel directly from the author's domain to the recipient.
DKIM works differently because it signs content instead of checking a connecting IP: a signature stays valid through a plain forward that leaves the signed headers and body untouched, which lets DMARC pass through aligned DKIM even when SPF fails, but breaks when a forwarder changes signed content, as a subject tag, an added footer or a MIME re-encoding can each invalidate it.
Two repair mechanisms exist, each with a limit. Sender Rewriting Scheme, or SRS, rewrites the envelope sender into the forwarder's domain, so SPF passes for the forwarder's domain and bounces can still be routed back, but the rewritten domain does not match the visible From domain, so SRS on its own does not satisfy DMARC alignment. The Authenticated Received Chain, or ARC, has each handler seal the authentication results it observed before passing the message on, so the final receiver can weigh the earlier result; ARC is defined in RFC 8617 as an Experimental protocol, and a valid ARC chain does not compel delivery, since the receiver decides whether to trust the handlers that sealed it. These mechanics are explained in the Suped analysis of forwarding and authentication, in the SPFwise guide to forwarding and SPF, and in the Bird explainer on ARC.
Most ordinary forwarded mail still arrives, because most senders DKIM-sign their mail and most receivers accept aligned DKIM. The risk concentrates in senders that rely on SPF alone, and in senders with a strict DMARC reject policy whose messages pass through a forwarder that edits content; in those cases forwarded mail can be rejected or filtered, and the failure looks like lost mail. No provider forwarding volume limit is stated here, because no primary provider page was verified for such a figure, and delivery of any given forwarded message stays conditional on the sender's DMARC policy and on receiver trust in the ARC chain. The Authentication-Results header on a delivered sample shows which check failed, and the AliasFleet guide to reading an email header describes where that verdict line sits.
On a plain forward, SPF fails for the original domain because the forwarder sends from its own IP address, while DKIM stays valid when signed content is unchanged and breaks when signed content is edited. ARC records earlier authentication results for the receiver to weigh, but a valid ARC chain does not guarantee delivery.
Gmail forwarding rules
Gmail's automatic forwarding covers all new messages except spam. After a forwarding address is added, Google sends it a verification link, and forwarding to it becomes available only after verification. The setup runs on a computer through Settings, then the Forwarding and POP/IMAP tab, where the account holder selects "Forward a copy of incoming mail to" and chooses what happens to the Gmail copy: keep it in the inbox, mark it as read, or archive it. The full provider flow is set out in Google's Gmail forwarding help. Forwarding applies to new mail only, and Gmail shows a forwarding notice in the inbox for the first week after it is turned on. Where such a notice appears on an account where forwarding was never set up, Google's help page states the password should be changed immediately and forwarding turned off. The blanket setting forwards to one address; further addresses or subsets need filters, with one filter per forwarding address. On work or school accounts, Google Workspace administrators control automatic forwarding: the setting is on by default, but an administrator can limit it to internal addresses only or turn it off entirely.
Outlook forwarding and redirect rules
Outlook handles automatic forwarding through inbox rules, and it separates two operations that Gmail does not separate in the same way. Microsoft's Outlook rules documentation states that forwarded messages appear to be forwarded from the reader, so a reply to a forwarded message goes to the forwarding address rather than the original sender. The classic Outlook flow is described separately in Microsoft's automatic forwarding article. Redirected messages appear to come from the original sender, so a reply goes to the original sender. The choice between "Forward to" and "Redirect to" therefore decides where replies go, and the wrong choice sends replies to the wrong mailbox.
Copies of forwarded or redirected messages stay in the mailbox unless a delete action is added to the rule, and deleted messages still count against the mailbox limit. Microsoft states that exceeding the mailbox limit can block sending and receiving, and that forwarding rules may stop working until enough mail is deleted.
Blanket forwarding and per-address aliases
Blanket forwarding and per-address aliases answer different questions: blanket forwarding asks where mail should be read, while per-address aliases ask which address each sender should hold. Under blanket forwarding, every sender holds the same real address, and the only switch is the whole rule, on or off. With one alias per site, each sender holds a different address with its own switch, so one misbehaving sender can be stopped without stopping the rest. The control difference is the subject of the AliasFleet comparison of forwarding and aliases.
The leak case shows the difference most clearly. Where a shop holding the reader's real address is breached or sells its list, the address keeps working for whoever holds it, and the reader cannot tell which sender leaked it, while where the shop held only one alias, the spam arriving on that alias names the source, and pausing that alias ends it. The per-site habit is described in the AliasFleet article on using a different address for every website. Blanket forwarding has no equivalent: filters can sort mail by sender, but sorting is not an off switch for one sender's address, and reply behaviour differs the same way, since an alias service routes replies through the alias, as described in the AliasFleet article on how email aliases actually work.
AliasFleet forwarding
AliasFleet is an email alias and forwarding service providing managed, persistent alias addresses that forward mail to a destination inbox chosen by the account holder, with one alias per site or purpose, a pause control per alias, and reply routing through the alias. A deactivated alias bounces mail with a standard delivery failure, and switching it back on restores delivery. The free tier covers 10 active aliases, one verified destination inbox, three managed subdomains, and 100 MB of monthly forwarding bandwidth, as stated in the AliasFleet article on alias safety. The AliasFleet homepage describes the alias service in full.
Two limits apply. AliasFleet does not change the destination provider's storage rules: forwarded mail still sits in the destination inbox under that provider's policy, and retention specifics vary by provider and plan. Aliases also do not protect addresses already handed out, and no claim is made here about AliasFleet inbound message retention, because no published inbound retention statement was verified for this article.
Uses of blanket forwarding
Blanket forwarding earns its place in three cases: account migration, where mail sent to an old address needs to reach a new inbox while contacts update their records; consolidation, where a reader with two inboxes wants one place to read mail, provided the destination is trusted as much as the source; and a short-term redirect, such as cover during a holiday or a role handover, where the rule has a known end date.
Before any of those uses, the destination needs confirmation as an account the reader controls and protects with two-factor authentication, the rule scope needs confirmation, and a review date needs setting, because a migration rule left running quietly keeps duplicating mail. Where the goal is control over which address each sender holds, rather than simply reading mail in one place, a per-address alias setup fits the job better than a blanket rule.
Top comments (0)