Email Forwarding Not Working: 6-Step Debug Checklist

Your email forwarding is not working. Messages disappear. The sender gets no bounce. The forwarding rule looks correct in every control panel you've checked. You're debugging silence — the hardest kind of failure because there's no error pointing you anywhere.

Email forwarding not working almost never means the rule itself is wrong. It means SPF, DKIM, and DMARC are working exactly as designed. To a receiving mail server, a forwarded message looks identical to a spoofed one: a server that doesn't own the original domain is delivering mail on its behalf. The receiving server drops it quietly. No notification to the sender. No notification to you. Both sides wait indefinitely for mail that was rejected within seconds of being sent.

Work through this checklist before touching your DNS. For the full protocol breakdown — why forwarding fails at the SPF layer and how SRS and ARC address it at the architecture level — see the complete email forwarding setup and fix guide. This article is the fast-triage workflow for when email forwarding is not working right now.

Why Email Forwarding Not Working Produces No Error

Email forwarding not working produces silence, not bounces, because the rejection happens at the receiving server — not at your forwarding server. Your forwarder relayed the message successfully. The receiving server rejected it and sent the failure notice back to your server, not the original sender. Both parties are now waiting for mail that was dropped within seconds of being sent.

This is why email forwarding not working is so difficult to diagnose without reading email headers. You have no visible error. The forwarding rule appears active. The message is gone. There are six root causes, ordered by how often each one is actually responsible. Work through them in sequence — jumping to DNS before checking the spam folder wastes 45 minutes solving the wrong problem.

60-Second Triage: Name the Failure Before You Fix It

When email forwarding is not working, the failure behavior tells you exactly where to look. Spend 60 seconds categorizing the symptom before touching any configuration — fixing the wrong root cause creates new problems and costs more time than the original failure. There are four distinct patterns, each pointing to a different culprit.

The Email Forwarding Not Working Checklist

Email forwarding not working is fixed at Step 1 or Step 2 in the majority of cases. Most operators skip both and spend 45 minutes adjusting DNS records that aren't causing the problem. Work through these steps in order and stop when you find the failure.

Step 1: Check the Destination Spam Folder

Probability: High  |  Symptom: No email, no bounce

When email forwarding is not working and there's no bounce, the message is almost certainly in the destination spam folder. Forwarding breaks the chain of custody that SPF verification tracks. When you forward from client@gmail.com to you@outlook.com, Outlook sees your forwarding server's IP delivering mail that Gmail's SPF record never authorized. Outlook treats it as a probable spoof and files it to Junk — silently, with no notification to either party.

Action: Log into the final destination mailbox and check Junk or Spam.

Fix: Mark as “Not Junk” to recover the message. To prevent recurrence, the forwarding server needs Sender Rewriting Scheme (SRS) to rewrite the envelope sender. Without SRS, forwarding to Gmail, Yahoo, or Outlook is structurally broken — not just unreliable.

Step 2: Read the Bounce Message (NDR Error Codes)

Probability: High  |  Symptom: Sender receives an “Undeliverable” notification

When email forwarding not working produces a bounce, the SMTP error code is the exact diagnosis you need. The bounce body contains the truth — read it before doing anything else. Don't guess at the cause from the subject line alone.

Step 3: Check DMARC Alignment — The Real Culprit

Probability: Critical for Gmail, Yahoo, and Outlook destinations  |  Symptom: Silent drop or rejection

Email forwarding not working at any scale almost always traces back to DMARC. If the original sender publishes a strict DMARC policy (p=reject), simple forwarding fails 100% of the time without SRS or ARC. This isn't a misconfiguration on your end — it's the protocol correctly blocking what looks like a spoofed relay. Every major inbox provider enforces this.

Check the sender domain's DMARC policy from a terminal:

dig _dmarc.originalsender.com TXT +short

If you see p=reject, your forwarded messages are being rejected because the forwarding server's IP isn't in the original sender's SPF record, and the envelope sender doesn't match the DKIM signature. Both alignment checks fail simultaneously.

Fix: You need server-side forwarding with SRS-enabled relaying and ARC (Authenticated Received Chain) support. ARC allows a receiving server to verify the original authentication results before your forwarding server re-signed the message. Client-side rules — Gmail filters, Outlook rules, cPanel redirects — cannot implement either. They'll keep failing for any sender with a strict DMARC policy, which now includes virtually every business domain.

Step 4: Enable Microsoft 365 Outbound Forwarding

Probability: Very High for Office 365 users  |  Symptom: 550 5.7.520 NDR

Email forwarding not working from Microsoft 365 is often a deliberate policy block, not a misconfiguration. Microsoft disables external automatic forwarding by default to prevent compromised accounts from acting as spam relays. User-level forwarding rules cannot override a tenant-level policy lock.

1. Log in to Microsoft 365 Defender
2. Go to Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Select Anti-spam outbound policy (Default)
4. Click Edit protection settings
5. Set Automatic forwarding rules to On — Forwarding is enabled

If the option is greyed out, your tenant admin has locked it at the organization level. No user-level setting will override it — you need admin access to the tenant.

Step 5: Check for Routing Loops

Probability: Medium  |  Symptom: 5.4.14 error or multiple copies received

A routing loop happens when Server A forwards to Server B and Server B forwards back to Server A. Both servers relay the same message indefinitely until the hop count limit triggers a bounce. Common pattern: a catch-all on Domain A routes all mail to Domain B, but Domain B has a rule forwarding specific addresses back to Domain A.

Inspect headers on any delayed or duplicate message for these tags:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To (appearing more than once with the same address)

If you're using catch-all routing, the domain catch-all routing guide covers how to structure this without creating loops. The destination of every forwarding rule must be a final mailbox — not another alias or forwarder.

Step 6: Gmail Destination Verification

Probability: Medium  |  Symptom: Rule exists but forwarding never activates

Email forwarding not working from personal Gmail often comes down to one skipped step: Google requires you to verify ownership of the destination address before activating forwarding. The rule exists. Gmail is ready to forward. It won't until you click a confirmation link in the destination inbox.

Action: Log into the destination inbox and find the “Gmail Team” forwarding confirmation email. Check Spam if you don't see it in the inbox. Click the confirmation link — the rule stays dormant until you do. If the email expired or never arrived, go to Gmail Settings → Forwarding and POP/IMAP and regenerate the verification.

Reading Email Headers to Diagnose Email Forwarding Not Working

Email forwarding not working but messages arriving in spam means the email is getting through but failing authentication checks. The Authentication-Results header is where every forwarding failure leaves its fingerprint. Read it before guessing at the fix — it tells you exactly which check failed and why.

How to view headers:

• Gmail: Open email → Three dots menu → “Show original”
• Outlook: File → Properties → Internet headers

What a healthy forwarded message looks like with SRS and ARC active:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

The SRS0= prefix in Return-Path confirms SRS is active on your forwarding server. If you don't see it, your forwarding setup is operating without envelope rewriting and will keep failing for any sender with a strict DMARC policy. That includes Gmail, Yahoo, Outlook, and the vast majority of business domains following Google's 2024 bulk sender enforcement.

When Email Forwarding Not Working Is a Business Problem

Email forwarding not working is invisible until it costs you something. A missed client email, an undelivered contract, a support request that arrived nowhere — every silent drop is an interaction that never happened. You don't know what you missed until someone follows up asking why you never responded.

Manual troubleshooting works once. It doesn't scale. Every new domain, every new client mailbox, and every upstream DMARC policy tightening can break forwarding again. When authentication failures spike your spam complaint rate, Google Postmaster Tools records it against your domain reputation — and that affects deliverability across everything you send, not just the forwarded messages.

Stop Running This Checklist Every Month

If email forwarding not working is a recurring problem, the answer isn't better debugging. It's forwarding infrastructure that handles SRS and ARC correctly from the start — so you never need to run this checklist again.

Old way: Set up forwarding rules in Gmail or cPanel, debug SPF failures per domain, log into M365 tenants to configure outbound policies, repeat when the next domain breaks.

TrekMail way: Define the route in the dashboard. ARC re-signing and SRS envelope rewriting happen automatically at the MTA level on every relay. Delivery works.

TrekMail's forwarding runs at the Postfix level — not as a client-side rule. When a message comes in, TrekMail rewrites the envelope via SRS, re-signs with ARC before re-delivery, and preserves the original sender's DKIM signature in the authentication chain. The receiving server — Gmail, Outlook, Yahoo — sees a clean, authenticated relay instead of a suspicious spoof.

For agencies managing email forwarding not working across dozens of client domains, this difference compounds fast. Instead of logging into 30 control panels and running this debug checklist per client, you configure forwarding once per domain in TrekMail's dashboard and it applies across the board. The client email management guide covers how to structure multi-domain forwarding without creating the A→B→A loops that trigger Step 5 above.

TrekMail's forwarding feature — including ARC signing and SRS rewriting — is available on the Pro plan at $10/month (100 domains, 50GB) and the Agency plan at $23.25/month (1,000+ domains). Both come with a 14-day free trial. If you need to test the forwarding setup before committing, the trial gives you full access — compare plans at trekmail.net/pricing.

Email forwarding not working shouldn't be a recurring support ticket. Get forwarding infrastructure that handles SRS and ARC automatically.