A client's forwarder usually works fine for months, right up until their domain's DMARC policy moves to enforcement, or a destination inbox provider tightens its own rules, and the same forwarded message starts bouncing or landing in spam. The forwarding setup didn't change. SPF and DKIM were never built to survive a message passing through a second mail server before it reaches the final inbox, and that's just as true whether the forwarding mailbox sits on Atriomail, a client's old cPanel server, or anywhere else. The problem lives in how SPF, DKIM and DMARC evaluate a message, not in which platform hosts it.

This guide works through why forwarding breaks each piece, what the standard fix, SRS, actually repairs and what it never will, how ARC lets a receiver award a pass anyway, and the steps for configuring trusted ARC sealers when the destination is Microsoft 365. It ends with what this looks like for a forwarder set up inside Atriomail specifically, since a reseller running client mailboxes there hits this exact problem too.

Table of Contents

Key Takeaways

Point Why it matters
Forwarding breaks SPF by design, not by accident SPF checks the connecting server's IP against the domain in the envelope sender (RFC 7208). A forwarder relays from its own IP while leaving that domain untouched, so the check fails unless something corrects it.
DMARC then rides on DKIM alone With SPF already broken, a DMARC pass depends entirely on an aligned DKIM signature surviving the hop. Plenty of forwarders quietly invalidate that too.
SRS fixes the bounce, not the alignment Sender Rewriting Scheme stops SPF from failing outright, but it rewrites the envelope to the forwarder's own domain, so it can never produce the alignment DMARC is actually checking for.
ARC is the real DMARC fix, where it's supported Authenticated Received Chain (RFC 8617) lets a receiver trust a specific intermediary's own authentication assessment. Microsoft 365 requires an admin to name that intermediary explicitly.
What Atriomail does for this Atriomail's own forwarders move mail from a mailbox on your domain to an outside address like Gmail, but whether that preserves SPF or adds ARC headers isn't documented, so test the actual headers rather than assuming either way.

The original domain's own records are the baseline every fix below depends on. Atriomail generates SPF, DKIM and DMARC records for a domain, and on a connected Cloudflare or Namecheap account can publish them, so that half of the problem is one less thing to configure by hand before you start chasing a forwarding failure.

Create your account   See pricing

Before You Start

  • A real forwarded message to examine, with access to the full headers at the final destination. A description of the problem from the client isn't enough; you need the actual Authentication-Results header.
  • Know which kind of forward you're dealing with. A true SMTP-level domain forward (a mail server or control panel relaying to an outside address) and a mailbox-level "forward a copy" rule inside an existing inbox behave differently, and the fixes below aren't interchangeable between them.
  • A clean baseline on the original domain. Check its current SPF, DKIM and DMARC records before touching anything downstream, ideally with Atriomail's free DNS checker, so you're not troubleshooting a forwarding problem that's actually a broken source record.
  • Admin access to the final destination, if it's Microsoft 365. Configuring a trusted ARC sealer needs either the Microsoft Defender portal or Exchange Online PowerShell.
  • Patience for propagation. A DNS change and an ARC sealer addition both take time to apply; retest with a fresh message rather than re-reading an old one.

Why Forwarding Breaks SPF

SPF, defined in RFC 7208, checks exactly two things: the domain portion of the envelope sender (the MAIL FROM or HELO identity) and the IP address of the SMTP client making the connection. When a forwarder relays a message, the connecting IP is the forwarder's own server, but the envelope sender still shows the original domain. Unless the forwarder's IP happens to be listed in that domain's SPF record, which it almost never is, the check fails at the next hop. A strict policy (-all) lets the receiving server reject the message outright, producing exactly the kind of non-delivery report covered in reading an email bounce message, rather than quietly filing it as spam.

The instinctive fix, adding the forwarder's IP directly to the original domain's SPF record, works for that one forwarder and breaks the moment a different recipient forwards the same domain's mail somewhere else. Every destination added that way is another entry pushing toward the 10-lookup ceiling covered in fixing an SPF record with too many DNS lookups, and it still does nothing for DKIM or DMARC, checked independently.

Don't patch SPF per forwarder. Hand-adding a forwarding server's IP to a client's SPF record is the fix that looks like it worked and quietly doesn't scale past one destination.

Create your account   Read the setup guide

Why DMARC Still Fails Even When DKIM Should Survive

DMARC, defined in RFC 7489, doesn't accept a bare SPF or DKIM pass. It requires an aligned pass: the authenticated domain has to match the domain shown in the message's visible From: header, at least at the organizational-domain level in the common relaxed mode. With SPF already broken by the forwarding hop, a DMARC pass now depends entirely on DKIM, the mechanism that travels inside the message rather than being checked against the connection.

That's where forwarding causes the second failure. DKIM signs the body and a defined set of headers at the moment a message is sent; anything a forwarder does afterward, a footer, a "via" banner, a security-gateway stamp, even re-wrapped line endings, invalidates that signature. Microsoft's own documentation gives the literal symptom: a message can arrive showing dkim=fail (body hash did not verify) even though the signature validated cleanly when it left the original sender. Once both SPF and DKIM have failed, DMARC fails outright, and depending on policy the message bounces, lands in quarantine, or gets rejected, the enforcement mechanics covered in moving a client's DMARC policy to p=reject without breaking their mail. Reading a domain's own DMARC aggregate reports, covered in reading a DMARC aggregate report, is usually how a reseller first notices a forwarding problem exists.

Stop the SPF Bounce With SRS, Know Its Limit

Sender Rewriting Scheme solves the specific SPF problem above by rewriting the envelope sender before the forwarder opens its outbound connection. Instead of relaying the message with the original domain still in MAIL FROM, the forwarding server substitutes an address on its own domain, encoding the original sender inside it so a bounce can still find its way back. The receiving server at the next hop then checks SPF against the forwarder's own domain, one the forwarder's IP is actually authorized for, and the check passes.

What SRS does not do is produce DMARC alignment, and it's worth being direct about that limit before relying on it: rewriting the envelope to the forwarder's own domain means the authenticated domain is no longer the original sender's domain at all, so it can never match the visible From: header for DMARC's purposes. SRS stops the bounce. It does not, by itself, get a forwarded message to a DMARC pass. SRS is typically configured on the forwarding mail server itself, not per message, so it's the domain or mail-server admin doing the forwarding who needs to enable it, the same administrative layer that owns a domain's DNS setup and branding generally.

Get DMARC Passing With ARC and Trusted Sealers

Authenticated Received Chain, defined in RFC 8617, is the mechanism built for this. It lets a legitimate intermediary attach a signed record of the authentication results before it made any changes, built from three fields: ARC-Authentication-Results records the assessment at arrival, ARC-Message-Signature proves which intermediary had custody, and ARC-Seal binds both into a verifiable chain. A receiver that trusts the named intermediary can then award a DMARC pass despite a local SPF or DKIM failure caused by that intermediary's own changes.

Gmail and Google Workspace read and validate ARC chains without any admin configuration. Microsoft 365 requires an admin to name the trusted intermediary explicitly, the concrete, repeatable task most resellers will actually run into. Per Microsoft's own documentation (checked October 2026):

  • Send a real test message through the forwarder into a Microsoft 365 mailbox.
  • Open the message's full headers (Outlook: File, Properties, Internet headers) and find the ARC-Seal header.
  • Note its d= value, the forwarder's own signing domain, not yours and not the client's, the most common setup mistake per Microsoft's own troubleshooting guidance.
  • In the Defender portal at security.microsoft.com/authentication, or via PowerShell with Set-ArcConfig -Identity Default -ArcTrustedSealers "thatdomain.com", add that domain.
  • Allow up to 30 minutes, then send a fresh test message rather than re-checking the old one.

A successful result shows arc=pass and oda=1 in the final ARC-Authentication-Results header, and compauth=pass reason=130 in the Authentication-Results header, the tokens Microsoft's own documentation uses to confirm a trusted-sealer override took effect. Two limits: ARC only helps when the intermediary adds ARC headers at all (arc=none means nothing to trust, and the fix moves back to SPF and DKIM at the source), and an override only affects the DMARC and spoofing determination, not spam-content filtering, so a message can show arc=pass and still land in Junk for unrelated reasons.

Decide When Forwarding Shouldn't Be the Answer

Live, cross-domain forwarding is inherently fragile for authentication, since every hop is another place SPF or DKIM can break again. For a client forwarding permanently rather than temporarily, often because they never fully left an old provider, the more durable fix is to stop forwarding and migrate the mailbox itself, so there's one authenticated mailbox instead of a source domain, a forwarding hop and a destination to keep aligned indefinitely. That's different planning work, closer to managing multi-client email at scale, and worth raising through whatever support process already covers domain-level changes. One exception: if the forwarded mailbox is itself on Microsoft 365, Exchange Online or Outlook.com, a standard password-based IMAP migration tool isn't an option, since Microsoft no longer allows that kind of sign-in; that move needs a different route entirely.

How to Verify It Worked

  • Send a real message through the actual forward, not a guess based on the records alone. Headers are the only reliable evidence here.
  • In Gmail, open the message and choose Show original (Google's own instructions for checking message authentication, support.google.com/mail/answer/180707, checked October 2026), then read the Authentication-Results header for spf=, dkim=, dmarc=, and arc= if present.
  • In Microsoft 365, pull the internet headers the same way described above, and look for arc=pass, oda=1 and compauth=pass reason=130 if a trusted ARC sealer is configured.
  • Separately confirm the original domain's own records are clean with Atriomail's free DNS checker. It reads the domain's public SPF, DKIM and DMARC records directly, not the forwarded copy, so a PASS there rules out the source as the problem.
  • Don't move a domain to DMARC enforcement until a message through every forwarding path you know about actually shows a pass in the headers, not just clean records in isolation.

Common Mistakes and How to Avoid Them

  • Adding the forwarder's IP straight into the original domain's SPF record. Symptom: that one path starts passing, while any other address the same domain's mail gets forwarded to still fails, and the record creeps toward the lookup ceiling that also undermines DNS-driven deliverability generally.
  • Treating "I set up SRS" as "DMARC now passes." Symptom: the bounce stops, but DMARC aggregate reports keep showing the same volume of failures, because SRS was never going to produce alignment in the first place.
  • A content-modifying intermediary breaks DKIM without anyone noticing. Symptom: dkim=fail (body hash did not verify) on a signature that validated perfectly before that hop, the same failure mode covered from the migration angle in fixing a DKIM signature failing after a migration.
  • Naming the wrong domain as a Microsoft 365 trusted ARC sealer. Symptom, straight from Microsoft's own troubleshooting reference: Get-ArcConfig shows your own domain instead of the intermediary's actual signing domain, and arc=fail or oda=0 keeps appearing.
  • Moving a domain to DMARC enforcement without checking who forwards its mail elsewhere. Symptom: everything looks clean against your own test inbox, then real client mail starts bouncing the week enforcement goes live, for recipients nobody tested.
  • Confusing an SMTP-level domain forward with a mailbox's own "forward a copy" rule. Symptom: time spent configuring SRS on a mail server when the actual forward is a setting inside one mailbox, or the reverse, and neither fix touches the real cause.

Doing This on Atriomail

Atriomail's own forwarders live inside the panel rather than on a mail server you administer directly, which changes which half of this guide applies. A forwarder can only be created once the domain already has a paid mailbox on it, and it passes mail on to an outside address such as Gmail; the forwarded message shows the original sender's name followed by "via" your domain, and a reply goes back to the original sender, not to you, per Atriomail's own documentation at system.atriomail.com/kb/advanced-features/email-forwarding-aliases (checked October 2026), covered in more depth in Atriomail's guide to aliases, forwarders and catch-alls.

That documentation doesn't say whether forwarding rewrites the envelope sender the way SRS does, or attaches ARC headers the way Gmail and Microsoft 365 do. Rather than assume either way, treat an Atriomail forwarder like any forwarder you didn't configure yourself: send a real test message and read the Authentication-Results header at the destination, the check described above. Where Atriomail does help directly is the original domain's own baseline: its automatic DNS setup on a connected Cloudflare or Namecheap account generates and can publish that domain's SPF, DKIM and DMARC records, one less thing to get wrong by hand. For a client who wants to stop forwarding permanently, Atriomail's free IMAP migration moves the mailbox itself instead, leaving one authenticated mailbox rather than a source domain, a forward and a destination.

None of this changes what a mailbox costs: $1.39 per mailbox with 15 GB included, the same published price whether or not that domain has ever had a forwarder on it. Create your account, add the domain, and work through the headers above before deciding a client's forwarding problem needs anything more than that.

Fix the source record before chasing the forward. A domain's own SPF, DKIM and DMARC records are the foundation every fix in this guide builds on, and Atriomail generates them for you on every domain in the panel.

Create your account   Talk to the team

Frequently Asked Questions

Does SRS fix DMARC for forwarded mail?

No. SRS rewrites the envelope sender to the forwarder's own domain, which stops SPF from failing outright, but that rewritten domain can never align with the original sender's From: header. SRS prevents the bounce; getting to an actual DMARC pass depends on DKIM surviving the hop, or on the receiver trusting an ARC chain instead.

What's the real difference between an SPF pass and SPF alignment?

A pass just means the connecting IP was authorized for whatever domain was in the envelope sender, which after SRS is the forwarder's own domain. Alignment, which DMARC actually requires, means that authenticated domain also matches the organizational domain of the visible From: header. A message can pass SPF and still fail DMARC if the two domains don't line up.

Does Atriomail's own forwarding rewrite the envelope sender or add ARC headers?

That's not documented either way. Atriomail's forwarders move mail from a mailbox on your domain to an outside address and show it as sent "via" your domain, but whether that mechanism preserves SPF or attaches an ARC chain isn't something to assume. Test a real forwarded message's headers at the destination before relying on it.

Can I just add the forwarding server's IP to my SPF record?

It stops the bounce for that one forwarding destination, but it doesn't scale once more than one recipient forwards the domain's mail elsewhere, and every address added pushes the record toward the 10-lookup ceiling that causes a separate SPF PermError.

Does Atriomail support forwarding mail to an outside address like Gmail?

Yes, once the domain already has a paid mailbox on it. The forwarded message displays the original sender's name followed by "via" your domain, and replies route back to the original sender.

What if a client wants to stop forwarding and just move the mailbox instead?

Atriomail's built-in IMAP migration copies mail and folders into a mailbox on Atriomail directly, with no charge beyond the mailbox itself. The one exception: if the source mailbox is on Microsoft 365, Exchange Online or Outlook.com, Microsoft no longer allows password sign-in over IMAP, so that specific move needs a different route; talk to us before quoting it.

Latest from the blog