What is Email Forwarding? How It Works and Best Practices

Email forwarding is one of the most common causes of delivery failures, and most domain admins have no clear signal that anything is wrong. Forwarding alters the message data in a way that breaks modern authentication protocols, and this often goes unnoticed. Because the data no longer matches, receiving servers treat the forwarded mail as suspicious and often send it to spam or block it outright.

What Is Email Forwarding?

Email forwarding is a server-side process that redirects incoming email from one address to another. Because this happens on the mail server, it is completely transparent to the original sender and requires no manual effort from the recipient. 

But first, let’s differentiate manual and automatic email forwarding. To clear up any confusion, it helps to look at where and when the forwarding happens:

• Manual Email Forwarding: This happens after a message lands in your inbox. You open the email, click “Forward,” type in a new recipient’s address, and hit send. It requires human action for every single email.
• Automatic Email Forwarding: This is a set-it-and-forget-it rule. You configure it once (either in your email settings or on the server), and the system instantly routes incoming messages to another address before you even see them.

Organizations use automatic email forwarding for several common scenarios: 

• Domain Aliases: Routing general business addresses directly into an employee’s personal inbox.
• Auto-Forward Rules: Creating user-level or system-level filters to pass mail to separate accounts. 
• Mailing Lists: Distributing a single incoming message to a large group of subscribers at once. 
• Third-Party Routing: Sending transaction logs or support tickets into external systems for processing. 

Email Forwarding vs. Redirecting

While people often use these two terms interchangeably, they mean different things to a mail server. 

When an email is forwarded, your mail server essentially duplicates the message and starts a new transaction. It wraps the email in its own background routing information but keeps the original sender’s name visible in the From line you see in your inbox. This difference is what makes receiving servers suspicious. 

A true redirect is more passive. Instead of rebuilding the message, your server simply sends the original email to a new destination without changing the background envelope or transmission properties. To the receiving server, a redirected email appears as if it traveled straight from the original sender’s inbox to theirs; no middleman, no changed data, and no broken authentication. 

Quick Glance: Forwarding vs. Redirecting

How Does Email Forwarding Work?

Here is a step-by-step description of how a message travels across the internet: 

• Step 1: The original sender sends the email to the recipient’s initial mail server. 
• Step 2: The original server gets the incoming message and checks it against a set of forwarding rules. 
• Step 3: The forwarding intermediary starts a new connection to send the message to the final destination server, routing the traffic through its own system and IP address. 
• Step 4: The destination server gets the message from an unexpected intermediate IP address. 

The Conflict 

During this process, three big changes occur: 

1. The connecting sending IP address changes to that of the forwarding server, 
2. The From header stays the same as the original sender’s domain, and 
3. The message body or headers may be altered, like adding mailing list footers or transit headers. 

These structural changes break email authentication. 

How Email Forwarding Affects Authentication

When automatic email forwarding happens, it causes changes that disrupt how email authentication protocols check a message. 

SPF (Sender Policy Framework) 

SPF checks inbound mail by seeing if the connecting server’s IP address is listed in the DNS record of the domain found in the envelope sender Return-Path. 

• The Problem? When an email is forwarded, the forwarding intermediary starts a new connection to send the message and routes the traffic through its own infrastructure and IP address. 
• The Result? Since the forwarding server’s IP address is not listed in the original sender’s SPF record, the envelope sender check fails at the final destination. So, SPF will almost always fail during forwarding. 

DKIM (DomainKeys Identified Mail) 

DKIM uses a cryptographic signature linked to the domain to verify that the message content wasn’t changed in transit. 

• The Problem? This cryptographic signature usually survives basic forwarding unchanged if the intermediary server sends the message along passively. However, if the forwarding server alters the message body or adds tracking pixels or headers, the underlying data changes. 
• The Result? Once the content is changed, the DKIM signature no longer matches, which completely invalidates the authentication. 

DMARC 

DMARC acts as a policy layer that requires an email to pass either SPF alignment or DKIM alignment to clear authentication. 

• The Problem? Because forwarding inherently breaks SPF, your email relies on DKIM to pass DMARC. If the forwarding intermediary also modifies the message body or headers, DKIM fails along with SPF. 
• The Result? When both protocols fail, DMARC validation fails as a direct consequence. If the original sender’s domain has a strict DMARC policy (p=reject), the legitimate forwarded email is blocked by the destination server.

The Evolution of Forwarding: From ARC to DKIM2

To solve the inherent flaws forwarding introduces to traditional email authentication, the internet community originally designed ARC (Authenticated Received Chain) to let intermediaries cryptographically vouch for a message.

What is ARC?

To put in simple terms, ARC is an email protocol that acts like a sequence of notary stamps. As an email travels through forwarding intermediaries (like a mailing list or an auto-forwarding inbox), each server cryptographically signs the message and vouches for its original authentication results. This allows the final receiving server to look back through the validated chain and see that the email was legitimate before it was forwarded.

The Shift to DKIM2

However, the email security landscape is shifting. According to the May 17, 2026, IETF draft (draft-ietf-dkim-dkim2-spec-02), the industry is actively transitioning to DKIM2.

Because the operational lessons of ARC are being folded into this cleaner, native solution, a separate April 2026 IETF draft has proposed officially reclassifying ARC as a historic standard.

How DKIM2 Natively Fixes Forwarding

While ARC operated as an experimental workaround, DKIM2 fixes broken forwarding directly within the core protocol. When mailing lists or forwarders alter an email, DKIM2 handles it by building an ordered chain of custody across every step the message takes.

Each intermediary system records its specific changes and appends its own signature. This allows receiving servers to seamlessly trace the mail back to the original sender without breaking the authentication chain.

Key Refinements in the May 2026 Update:

• Excluded Headers: Authentication-Results headers will now be excluded from signing to prevent unnecessary verification failures as mail crosses boundaries.
• Stricter Control Flags: Senders can use enhanced donotmodify and donotexplode flags to prevent unauthorized message alterations or split routing.
• Streamlined Code: The specification will remove the unnecessary z body recipe to simplify how compatible implementations are built.

Important Note: DKIM2 is still an active IETF draft and has not been officially rolled out yet. The specification is expected to undergo further technical changes and refinements before it is formally published as a finalized Internet standard. 

Email Forwarding Best Practices

Here are the best email forwarding practices that domain administrators should follow:

• Prioritize DKIM Alignment: Use DKIM as your main alignment method. Since SPF is likely to fail during forwarding, a valid, unmodified DKIM signature is often your best defense for passing DMARC validation. 
• Configure Relaxed Canonicalization: Set your mail server’s DKIM canonicalization to c=relaxed/relaxed. This allows minor changes in whitespace or header case during transit without breaking the cryptographic signature.  
• Maintain Existing ARC (But Look to DKIM2): If your internal mail infrastructure already utilizes ARC protocol signing, keep it active to assist legacy gateways. However, do not invest heavily in new ARC engineering. According to the latest 2026 IETF drafts, ARC may be reclassified as a historic standard as its operational lessons are being folded into DKIM2.
• Configure Trusted ARC Sealers (For Now): For Microsoft 365 environments, continue to manually add known, reputable forwarding intermediaries to your Trusted ARC Sealers list inside the Microsoft Defender portal. This ensures legitimate forwarded mail isn’t discarded while the industry transitions to DKIM2.
• Monitor DMARC Aggregate Reports: Review your aggregate XML data to see where forwarding failures occur as SPF-only alignment issues. Use these reports to identify and measure the exact impact forwarding has on your delivery rates. Reviewing DMARC policy overrides can help interpret how receiving networks treat these flows.
• Transition to Shared Mailboxes: For internal routing, consider using shared mailboxes instead of automatic inbox forwarding rules. Shared mailboxes let multiple users access the same email streams directly, which avoids the authentication issues caused by server-to-server forwarding.  
• Enforce Policies Gradually: Start with p=none if you have active forwarding pathways. Only move your policy to stricter levels (p=quarantine or p=reject) after confirming your forwarded flows through your monitoring reports. 

Check our comprehensive mail forwarding guide or review the Google ARC sender guidelines to ensure your configurations align with current industry standards.

Types of Email Forwarding

Understanding the different operational levels of forwarding helps identify where authentication problems arise. 

Server-Level Forwarding

Configured at the Mail Transfer Agent (MTA) or corporate mail server level, this type applies global routing rules to all incoming messages that meet specific domain criteria. It happens instantly upon receipt and is very efficient for corporate aliases. 

Client-Level Forwarding

This is set up by individual users within their email clients, such as Gmail or Outlook. It relies on user-defined inbox rules and filters to send incoming messages to external, personal, or secondary accounts. 

Domain Aliases

A structural setup where an entire domain or specific address automatically redirects all inbound traffic to a separate destination inbox. This is commonly used in corporate settings to maintain clean, public identities. 

Mailing Lists

A broadcast system where an email sent to a single centralized address is automatically copied and sent out to a large number of individual subscribers. Mailing lists have the highest risk of DKIM failure. 

Email Forwarding in Gmail and Outlook

Gmail and Microsoft 365 deal with email forwarding with distinct cloud frameworks.

Email Auto-Forwarding in Gmail

Here is how to forward emails in Gmail:

Step 1: Head to Settings

Click the Gear icon in the top right of Gmail, hit See all settings, and jump over to the Forwarding and POP/IMAP tab.

Step 2: Link the New Address

1. Click Add a forwarding address and type in the destination email.
2. Head over to that destination inbox, open the confirmation email from Google, and click the verification link.

Step 3: Pick How to Forward

• To forward everything: Check Forward a copy of incoming mail to…, decide if you want to keep or delete the copy in your original inbox, and hit Save Changes at the bottom.
• To forward specific emails: Click creating a filter (or use the search bar dropdown), set your criteria (like a specific sender), check Forward it to, and hit Create filter.

What’s Happening Behind the Scenes?

When Google forwards a message, it sends it through its own servers. Here is how that affects email security at the final destination:

• SPF will likely fail: Because the email is coming from Google’s servers instead of the original sender’s, standard SPF checks usually break.
• DKIM usually passes: Gmail doesn’t touch the email body, so the original sender’s DKIM signature stays intact.
• Gmail automatically adds ARC headers to forwarded mail (for now), which helps the receiving server see that the email is legitimate despite the SPF failure.

Quick tip for Workspace Admins: Keep an eye on your DMARC aggregate reports to track and manage any of these SPF issues caused by forwarding.

Email Forwarding in Outlook / Microsoft 365

Microsoft 365 (M365) provides a broad range of email routing options, but navigating their interaction with mail security filters requires careful configuration.

1. Types of M365 Email Forwarding

Administrators and users can set up forwarding using three distinct methods:

• Inbox Rules: Individual user-level rules created within Outlook.
• Transport Rules: Detailed, admin-level rules configured in Exchange Online.
• SMTP Mailbox Forwarding: Direct Simple Mail Transfer Protocol forwarding setups applied to specific mailboxes.

2. The Authentication Problem: SPF and ARC Failures

Because forwarding alters the email’s path, it inherently conflicts with standard email authentication protocols:

• SPF Breaks: During a forward, the connecting IP address changes to Microsoft’s network. Consequently, the original sender’s Sender Policy Framework (SPF) check will fail at the final destination.
• ARC Header Default: By default, M365 transport rules add Authenticated Received Chain (ARC) headers to outbound forwarded emails to help validate the message’s history.
• The Result: Despite the ARC headers, the shift in IP addresses often leads to arc=fail status errors for Microsoft tenants at the receiving end.

3. Administrative Solutions and Policies

To ensure email deliverability and prevent security blocks, enterprise M365 administrators must manage two critical settings:

• Define Trusted ARC Sealers: Admins should explicitly list trusted external intermediaries as Trusted ARC Sealers in their Microsoft Defender portal to improve deliverability.
• Permit External Forwarding: Microsoft enforces a global security policy that blocks external automatic forwarding by default in newer tenants. Because of this security measure, user-created forwarding rules will silently fail until an admin explicitly permits external forwarding.

Summing Up

The internet’s basic security tools were not designed for messages that switch hands. When one server passes an email to another server, it changes the sender IP and removes your SPF protections.

But you don’t have to sacrifice email routing for good security. Strong DKIM setups and ARC protocols can help ensure your forwarded emails reach their intended inboxes. 

With PowerDMARC, you can see your entire email forwarding setup at a glance. Our platform lets you track DMARC aggregate data, manage complicated email alias issues, and implement perfect outbound ARC signing across your network. 

Stop guessing if your emails are arriving. Sign up for a free PowerDMARC trial today and secure your mail flow from start to finish.

Frequently Asked Questions 

Does email forwarding break SPF? 

Yes. SPF checks if the sending server’s IP address matches the authorized IPs in the sender’s DNS records. Because forwarding sends the message through an intermediary server, the connection will not match the original sender’s SPF record. So, the check will fail! 

Does email forwarding break DKIM? 

Under Legacy DKIM, forwarding breaks if a mailing list or intermediary alters the email text, appends footers, or modifies headers. Because the cryptographic hash changes, the original signature breaks, causing DMARC failures. According to the May 17, 2026, IETF draft, the upcoming DKIM2 will handle forwarding by establishing a built-in chain of custody.

Instead of breaking the authentication, each system that touches the email records its modifications and appends its own signature. This allows receiving servers to seamlessly trace the message back to the original sender.

Why are my forwarded emails going to spam? 

Forwarded emails often end up in spam folders because the change in sending IP breaks SPF validation. When this failure causes downstream DMARC authentication to fail, receiving mail systems mark the incoming message as unauthenticated or spoofed. 

What is the difference between email forwarding and email redirect? 

Email forwarding changes the mail transmission path by routing it through an intermediary server with a new IP address, while keeping the original sender details in the visible headers. An email redirect instructs the system to send the original message directly to a secondary address without changing the envelope sender properties or breaking authentication alignment. 

Is email forwarding secure? 

Standard email forwarding reveals original message routing headers to third-party systems, complicating tracking and disrupting authentication protocols like SPF and DMARC. This makes it easier for bad actors to exploit unaligned streams unless protections like ARC are properly set up.

• About
• Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Latest posts by Ahona Rudra (see all)

• How to Block High-Risk AI Agents in Microsoft Entra - June 15, 2026
• Office 365 Anti-Phishing Policy: How to Configure It - June 3, 2026
• AI Agent Security: Risks, Best Practices, and Email Authentication - June 2, 2026