Every forwarding rule looks the same in a control panel: a source address, a destination, a toggle. The difference that matters lives one layer down, in what happens to the SMTP envelope when the message is relayed. Alias forwarding, which rewrites the address within the same domain, keeps the original envelope sender intact and stays DMARC-safe. Remote forwarding to another provider rewrites the path, breaks SPF alignment, and usually needs SRS to survive. The forwarding type, not the destination, decides whether your setup passes authentication.

How the SMTP envelope decides whether forwarding breaks SPF

SPF authenticates the envelope sender, the address given in MAIL FROM during the SMTP conversation, not the From: header the recipient sees. When a message arrives at your server for sales@example.com and you forward it to a Gmail inbox, the receiving provider checks SPF against the domain in that envelope sender. If your server relays the message unchanged, Gmail sees MAIL FROM:<someone@origin-domain.com> arriving from your server’s IP. The origin domain’s SPF record almost certainly does not authorize your IP, so the check fails. DKIM may still pass if the original signature survives, but a rewritten subject line, an added footer, or a mailing list tag can invalidate it.

Alias forwarding works differently because the rewrite happens inside the same domain. A message to info@example.com gets delivered to the mailbox jane@example.com, still on your server, still under your control. The envelope sender is untouched. The receiving mail server sees a message from the original sender, and the final delivery to Jane’s mailbox is a local handoff that never crosses an SPF check. This is why alias forwarding is DMARC-safe: the From: domain stays aligned with the envelope, and DKIM signatures are not disturbed by a relay hop.

The distinction gets muddy because mail clients and hosting panels use “alias” loosely. A true alias is a server-side rewrite to another local mailbox, common in Postfix virtual alias maps, Exim redirect routers, and cPanel’s forwarders when the target is local. A remote forwarder is a relay to an external host, and that extra hop is where SPF breaks. If you are unsure which one you configured, check the destination domain. Same domain means alias. Different domain means remote forwarding, and remote forwarding needs a plan for authentication.

Where SRS fits and why it is not optional for remote forwarding

Sender Rewriting Scheme solves the remote forwarding problem by rewriting the envelope sender at the forwarding hop. Instead of relaying MAIL FROM:<someone@origin-domain.com>, your server rewrites it to something like SRS0=HHH=tt=origin-domain.com=someone@example.com under your own domain. The receiving provider now checks SPF against your domain, which authorizes your server, so the check passes. When a bounce comes back, SRS decodes the address and routes the failure to the original sender rather than dumping it on your postmaster.

SRS is not free of side effects. It breaks DMARC alignment on the envelope, though the From: header remains the original sender, and DMARC alignment is evaluated against that header domain with DKIM or SPF. Since SRS rewrites SPF, only DKIM keeps the message DMARC-compliant on the SPF path. If the original message was not DKIM-signed, remote forwarding through SRS can still fail DMARC at strict receivers. That is the trade-off most guides skip: SRS fixes SPF, but it does not fix a message with no DKIM signature and a strict DMARC policy at the origin.

Postfix users enable SRS through postsrsd, a daemon that hooks into the cleanup and smtp stages. Exim has native SRS support in recent versions via the srs ACL condition. cPanel does not ship SRS by default, which is why remote forwarders configured there often land in spam at Gmail and Outlook. catch all email address covers this in more depth. Cloudflare Email Routing handles the rewrite internally and is generally reliable for simple forwarding, but it is not a substitute for a full mail server if you need catch-all behavior with custom routing logic. A catch-all email address that forwards remotely inherits every one of these problems, multiplied by the volume of mail it accepts.

Catch-all domains, verification, and the practical cost of accepting everything

A catch-all email accepts every message sent to a domain, whether or not a mailbox exists for the recipient. That behavior is configured on the mail server, not in DNS. MX records route inbound mail to a mail server, and the server decides what to do with unknown recipients. A standard mail server replies with 550 no such user when no mailbox matches, which is exactly what senders and verification tools expect. A catch-all server instead accepts the message and routes it to a fallback rule, a wildcard mailbox, or a forwarder.

Catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups: per-service addresses like github@example.com or receipts-2024@example.com that you can create on the fly without touching the server. That flexibility has a cost. Catch-all carries the risk of accepting spam to invented addresses, and it corrupts email verification. When a verification tool tests a random address at your domain, a catch-all returns a success, so the tool cannot distinguish a real mailbox from a black hole. Many verification services flag catch-all domains as risky for that reason.

Catch-all differs from alias, forwarding, and disposable addresses, and the differences matter for deliverability. An alias is a named mapping. Forwarding is a relay. A disposable address is typically a subdomain or third-party service. A catch-all is a server-wide policy. If you combine a catch-all with remote forwarding, every message to a non-existent address gets relayed to an external provider, and every relay hop risks SPF failure unless SRS is in place. A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients, and it requires deciding upfront whether those accepted messages stay local or leave the server.

For teams running Postfix or Exim, the safe pattern is a catch-all that delivers to a local mailbox or a local alias, not to a remote forwarder. Dovecot can serve that mailbox over IMAP or POP3, and the messages stay inside your authenticated boundary. If you must forward remotely, enable SRS and confirm DKIM signing survives the hop. AllMail.one publishes a guide to catch-all email that walks through the server-side configuration and the authentication implications in more detail.

Start by auditing every forwarder on your server and classifying it as alias or remote. Same-domain targets are safe by default. Cross-domain targets need SRS, DKIM preservation, and a test against a strict DMARC receiver before you trust them. If your catch-all points at an external inbox, either move it to a local mailbox or accept that a share of forwarded mail will fail SPF and DMARC at the destination. The forwarding type is the variable you control, and it is the one that decides whether your mail arrives or bounces.