Forwarded mail usually fails at the destination because forwarding breaks SPF, and the receiving server (Gmail or Outlook) is applying DMARC strictly against a domain whose only surviving authentication is a weak or broken DKIM signature. The fix isn't on your sending domain at all: it's making sure DKIM signs headers that survive the forward unmodified, and that your DMARC policy doesn't demand SPF alignment on a message that structurally cannot have it.
Why forwarding breaks SPF specifically
SPF checks the IP address a message arrives from against the list of servers your domain authorizes to send mail. When someone forwards your email, the message leaves from the forwarding server's IP, not yours. The receiving mailbox provider does an SPF lookup on your domain, sees a mismatch, and SPF fails. It was never designed to survive a middle hop.
DKIM is built differently and generally survives forwarding, because it signs the message content and specific headers with a cryptographic signature tied to your domain's public key, rather than checking the sending IP. As long as the forwarding server doesn't rewrite the subject line, body, or signed headers, the DKIM signature still validates at the final destination.
SPF breaks on forward, DKIM usually doesn't. Whether the forwarded message lands in the inbox depends almost entirely on DKIM staying intact and on how the destination provider's DMARC evaluation is configured to react to a partial pass.
What actually causes the bounce or spam-folder landing
Three things typically go wrong, and they compound:
- DMARC alignment failure. If your domain publishes a DMARC policy of
p=quarantineorp=rejectand the forwarded message fails SPF (expected) while DKIM also fails or is missing, DMARC fails outright. Gmail and Outlook both honor a strict DMARC policy, and a hard failure on a forwarded message frequently means it's rejected or dropped rather than just spam-foldered. If you haven't set up DMARC yet, start with the guide on DMARC setup, policies, and the Gmail/Yahoo rules. - The forwarding service rewrites the message. Some forwarding setups (older mailing list software, some corporate relays, certain "forward and CC" tools) modify the subject line, add a footer, or alter headers. Any of that invalidates the DKIM signature, because DKIM signs the exact bytes of the headers and body it covers. Once DKIM breaks too, there's nothing left for DMARC to pass on, and the message is judged purely on reputation, which is usually poor for an unfamiliar relay IP.
- No SRS (Sender Rewriting Scheme) on the forwarding hop. SRS is a workaround where the forwarding server rewrites the envelope sender address to one on its own domain before re-sending, so SPF can actually pass for that hop. Without SRS, the envelope sender still points at the original domain while the message physically comes from a different IP, guaranteeing an SPF fail. Not every forwarding setup implements SRS; ask whoever operates the forwarding step (in Flashcloud's case,
Email Forwardersunder your hosting service) whether it's applied, since that's the single biggest lever for fixing forwarded-mail deliverability.
How to check what's actually failing
Don't guess, look at the message headers on a message that landed in spam or bounced:
- Open the message and view its full source or raw headers (in Gmail: the three-dot menu → "Show original"; in Outlook: the message options → "View message details" or similar depending on version).
- Find the
Authentication-Resultsheader. It listsspf=,dkim=, anddmarc=with a pass or fail for each. - If you see
spf=failbutdkim=passanddmarc=pass, the forward worked correctly and DKIM alignment carried it through. Ifdkim=failtoo, something in the forwarding path modified the message, or the original message wasn't DKIM-signed in the first place.
If the original message left your domain without a valid DKIM signature at all, forwarding was never going to save it. Confirm DKIM is actually configured and signing correctly at the source before troubleshooting the forward itself.
Fixing it from the receiving end
If you're the one whose forwarded mail isn't arriving, and the domain doing the forwarding isn't yours to reconfigure, there are a few practical options:
- Ask the sender or the forwarding operator whether SRS is enabled. If not, that's the fix, not a workaround.
- Ask the original sender's domain owner whether their DMARC policy can be relaxed while you diagnose, then moved back to full enforcement once the forwarding path is confirmed to align. See DMARC setup, policies, and the Gmail/Yahoo rules for how DMARC policies work.
- Where possible, avoid chained forwarding (A forwards to B, which forwards to C). Every additional hop is another chance for a header rewrite to strip the DKIM signature, and DMARC alignment gets harder to preserve with each one.
- If this is actually a WordPress site sending contact-form notifications rather than a true forward, the underlying problem is usually unrelated and worth ruling out separately: see Contact form emails not arriving (WordPress SMTP fix).
When to contact support
If you've confirmed DKIM is passing at the source but forwarded mail still isn't reaching Gmail or Outlook, or you're not sure whether your domain's forwarding setup applies SRS, open a ticket from the portal under Support. A real person can check your domain's DNS Zone Editor records and forwarding configuration directly rather than you working blind from header dumps.