Why Your Forwarded Emails Land in Spam (And How ARC Fixes It)

So lets say you have a side project on a freshly acquired domain name, and you've set up email forwarding for the new domain. MX records pointed, aliases created, test email sent. Everything arrived in your Gmail inbox. So you thought the job was done.

Three months later, a registrar renewal notice did not show up. You checked the sender's logs. The email was sent. It was not bouncing. It was simply not arriving in your inbox. You searched Gmail, checked the spam folder, and found it there, along with a dozen other forwarded emails that had quietly been sinking for weeks.

This is not a configuration error. It is not a broken MX record. It is a structural problem with how email forwarding interacts with modern authentication, and it is getting worse.

The Problem: Forwarding Breaks Authentication

When someone sends an email to your custom domain, it passes through two mail servers before it reaches your inbox. The original sender's server sends it. Your forwarding service receives it. Your forwarding service then sends it again, this time to your Gmail, Yahoo, or Outlook address.

The second send is the problem. Modern email authentication has three pillars: SPF, DKIM, and DMARC.

1. SPF checks whether the server sending the email is authorised by the domain owner. The original sender's SPF record lists their own servers. When your forwarding service resends the email, the sending IP has changed. SPF fails.
2. DKIM is a cryptographic signature. If the original sender signed the email, and the forwarding service does not modify the body or headers, the signature survives. But forwarding often changes headers, and many senders do not sign at all.
3. DMARC is the policy layer. It tells receiving servers what to do when SPF or DKIM fails. Gmail and Yahoo have been tightening DMARC enforcement since early 2024. A forwarded email that fails SPF and has no surviving DKIM signature is increasingly treated as suspicious.

The result: your forwarding service did nothing wrong, but the receiving server sees an email from an unauthorised IP with broken authentication, and it lands in spam.

Why This Got Worse Recently

In October 2023, Google and Yahoo announced new requirements for bulk senders. Enforcement began in February 2024, with Gmail introducing temporary errors for non-compliant traffic in February, gradually increasing rejections from April 2024, and requiring DMARC records with a minimum policy of p=none from June 2024 (M3AAWG, 2023; dmarcian, 2024). Google also updated the DMARC record for gmail.com itself to p=quarantine, meaning any mail claiming to be from a Gmail address but sent outside Google's platform would increasingly be filtered to spam.

Yahoo Japan followed in December 2024, making DMARC, SPF, and DKIM mandatory for users going into 2025 (Security Boulevard, 2025).

The impact was not immediate for everyone. But over the following months, forwarded emails started disappearing more frequently. The reason is that these DMARC enforcement changes affect not just bulk senders — they raise the baseline strictness that receiving servers apply to all email, including forwarded messages.

Based on anecdotal accounts, in early 2024, forwarded emails arrived reliably. By mid-2025, roughly one in ten legitimate forwarded emails was landing in spam. By late 2025, it was closer to one in five for certain senders. The shift was gradual, which is why most people do not notice until something important goes missing. This is not an isolated issue. MailRoute documented in mid-2026 that "a forward that worked fine for years suddenly starts bouncing, or quietly lands every forwarded message in the recipient's spam folder" (MailRoute, 2026). DMARCguard reported Gmail returning 421 4.7.26 Your email has been blocked because the sender is unauthenticated on forwarded messages that originated from legitimate senders (DMARCguard, 2026). TrekMail described the same pattern: "Messages disappear. The sender gets no bounce... To a receiving mail server, a forwarded message looks identical to a spoofed one" (TrekMail, 2026).

What ARC Is and What It Does

ARC stands for Authenticated Received Chain. It is a protocol designed specifically for intermediate mail servers — forwarding services, mailing lists, and gateways — to preserve authentication results across hops.

Here is how it works in practice. When your forwarding service receives an email from the original sender, it checks SPF and DKIM at that point. It records the results: "SPF passed at this hop, DKIM passed for this domain." It then cryptographically signs this record with its own key. When it forwards the email to Gmail, it includes the signed ARC result in the headers.

Gmail receives the forwarded email. SPF fails, because the IP is now the forwarding service's, not the original sender's. DKIM may or may not survive. But Gmail checks the ARC signature. It sees that the forwarding service vouched for the authentication results at the previous hop. If the forwarding service is trusted, Gmail uses the ARC result to inform its DMARC evaluation. The forwarded email is treated as legitimate, not suspicious.

ARC does not fix SPF or DKIM directly. It adds a chain of trust that lets the receiving server understand what happened in between. It is the difference between a package arriving with a broken seal and a package arriving with a note from the courier explaining that the original seal was intact when they received it.

Why Most Forwarding Services Do Not Implement ARC

ARC is not a new protocol. It was standardised in 2019. The reason most forwarding services lack it is straightforward: it is technically complex to implement correctly, and it was not essential before DMARC enforcement became widespread.

The implementation requires:

1. Checking SPF and DKIM results on inbound email and storing those results.
2. Building a valid ARC chain in the message headers, with the correct format and ordering.
3. Signing the ARC result with a rotating key pair, publishing the public key in DNS, and managing key rotation.
4. Handling edge cases: broken ARC chains from upstream sources, malformed signatures, and loops.

Many forwarding services were built before DMARC enforcement became a practical concern. Their architecture assumes that if an email arrives, it can be forwarded, and the receiving server will accept it. That assumption held for decades. It does not hold anymore.

I built KaiMail with ARC from the start because I had already been bitten by this problem. I did not want to forward emails that silently disappeared. But I am aware that I am in the minority. Most services, including some of the largest in the market, still do not implement ARC. Their users are experiencing the consequences without understanding why.

What You Can Actually Do

If you use email forwarding, there are two things worth checking.

First, find out whether your forwarding service supports ARC. The simplest way is to send an email through your forwarding address to a Gmail account, then view the original message headers in Gmail. Look for a header beginning with ARC-Seal:. If it is present, your service implements ARC. If it is absent, it does not. The absence does not guarantee that your emails will land in spam, but it means they are more vulnerable to doing so as DMARC enforcement tightens.

Second, if you control the original sending domain, ensure it has both SPF and DKIM configured. A forwarding service with ARC can only vouch for what it observed. If the original sender had no SPF record and no DKIM signature, there is nothing to preserve. ARC helps when the original email was legitimate. It does not magic authentication into a message that never had it.

If you are choosing a forwarding service today, ARC should be on your checklist. It is not the only factor. Pricing, ease of setup, webhooks, and sending capability all matter. But deliverability is the core promise of email forwarding, and a service that cannot reliably deliver forwarded emails to the inbox is not delivering on that promise, regardless of how cheap or simple it is.

The Longer View

Email is the most reliable messaging system ever built. It predates the web, it outlasted every social network, and it remains the universal identifier for identity, account recovery, and business communication. But its reliability depends on trust mechanisms that were designed for a simpler topology: one sender, one receiver, no intermediaries.

Forwarding services are intermediaries. We sit between the sender and the receiver, and the protocols were not originally designed for us. ARC is the patch that fixes this gap. It is not a theoretical nicety. It is the mechanism that prevents legitimate emails from being misclassified as spam because the architecture changed underneath them.

I am not arguing that ARC makes email forwarding perfect. Spammers will attempt to abuse ARC chains, which is why receiving servers only trust ARC results from services with established reputations. Key rotation, signature verification, and chain validation all add operational overhead. But the alternative, which means silently losing emails that your users expected to receive, well, is not an option.

If you run a forwarding service and you do not have ARC yet, you need it. If you use a forwarding service and yours does not have it, you should know what you are trading away. And if you are forwarding email without understanding why some of it is disappearing, now you know. The emails are not broken. The chain of trust is.