Forwarding a catch-all to a Gmail address without SRS is one of those setups that works beautifully for a week and then quietly falls apart. The mail keeps flowing, the logs look clean, and yet Gmail starts dumping messages into spam or quarantining them outright. Everyone blames the catch-all. The real culprit is sender alignment on the forwarded copy, and it is worth understanding before you spend an afternoon rebuilding a mail server that was never broken.

Why the forward breaks alignment even when SPF passes

Here is the trap in plain terms. A message arrives at your domain, the catch-all accepts it, and your server forwards it to your Gmail address. On that forwarded copy, the envelope sender may be rewritten to your server, but the From header still says the original sender’s domain. Gmail checks SPF against the domain it sees in the return path or the HELO identity, finds your server’s IP authorized for your own domain, and passes SPF. Then it checks DMARC alignment: does the authenticated domain match the From domain? It does not. Your server’s IP is in your SPF record, but the From domain belongs to someone else entirely. Without SRS rewriting the envelope sender to your domain in a way that survives the hop, the message arrives authenticated as you and claimed by someone else. Gmail increasingly treats that mismatch as a reason to quarantine, especially on domains publishing strict DMARC policies.

This is why the symptom looks like a broken catch-all. Messages from some senders get through, messages from others vanish, and the pattern seems random. It is not random. It tracks the sending domain’s DMARC policy and Gmail’s reputation for that domain. A catch-all email address that forwards to Gmail without SRS will pass more mail from loosely configured senders and fail more mail from strict ones.

The fix is not to disable the catch-all. Either enable SRS on the forwarding host (Postfix with postsrsd, Exim with its SRS support, or a relay that does it for you), or forward through a service that rewrites the envelope properly. If neither is possible, accept that some forwarded mail will land in spam and check Gmail’s spam folder as part of your routine.

Forwarding types that cause the most delivery trouble

Not every forwarding rule carries the same risk. A catch-all that forwards to a local mailbox on the same server is the safest option: no envelope rewrite, no alignment problem, and the recipient reads mail over IMAP or POP3 directly. A catch-all that forwards to a remote address, like Gmail, is where SRS matters. A catch-all configured as an alias to a single destination behaves the same way and inherits the same risk.

Catch-all differs from alias, forwarding and disposable addresses in ways that matter for troubleshooting. An alias maps one known address to another. Forwarding moves mail to a remote destination. A disposable address is a deliberately temporary inbox. A catch-all is a fallback rule on the mail server that accepts every message sent to a domain when no specific mailbox matches. That last part is the key: a standard mail server replies with 550 no such user when no mailbox matches, and the catch-all is what suppresses that rejection. It is configured on the mail server, not in DNS. MX records route inbound mail to a mail server, and that is the extent of DNS involvement. SPF, DKIM and DMARC govern outbound mail only. None of them make a catch-all work.

A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients. catch all email address has more details on this topic. That is the whole recipe. Everything else is forwarding policy, and forwarding policy is where alignment breaks.

Forwarding method	Envelope handling	Alignment risk to Gmail	Best use
Catch-all to local mailbox	No rewrite, mail stays on server	None	Reading mail over IMAP or POP3
Catch-all forwarded without SRS	Original envelope preserved	High, Gmail quarantines on strict DMARC	Quick tests only
Catch-all forwarded with SRS	Envelope rewritten to your domain	Low, alignment holds	Long-term forwarding to Gmail
Alias to remote address	Same as forwarding	High without SRS	Single known address, not bulk
Disposable address service	Handled by provider	Varies by provider	Sign-ups and short-lived inboxes

Setup mistakes in Cloudflare, cPanel and raw mail servers

In Cloudflare, the mistake is treating Email Routing as a full catch-all replacement without checking what it does to the envelope. It rewrites headers and forwards, which is convenient, but if you also run your own MX records pointing at a server, you have two systems claiming the same domain. Pick one. If you set up catch-all in Cloudflare, disable the conflicting MX records at your host, or mail will bounce between paths unpredictably.

In cPanel, the trap is enabling the catch-all and pointing it at a Gmail address without touching the server’s SRS configuration. cPanel’s default Exim setup does not always enable SRS. Check the Exim configuration before you blame the catch-all. The same applies to a raw Postfix setup: postsrsd is a separate install, and without it every forwarded message carries the original envelope. Dovecot does not solve this. It is a delivery agent, not a forwarder.

Catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups, and that use case is fine. The risk is accepting spam to invented addresses, which a catch-all does by design. If the catch-all forwards that spam to Gmail without SRS, Gmail sees a stream of misaligned mail from your IP and starts treating your whole domain as suspect. That is how a working setup degrades over months.

Catch-all in email verification deserves a mention here too. Verification tools often flag catch-all domains as unverifiable because the server accepts every address. That is correct behavior, not a bug. Do not try to “fix” it by disabling the catch-all; you will lose the automation addresses you actually want.

If you want the full picture of how catch-all behaves across providers, AllMail.one publishes a guide to catch-all email that covers the DNS side and the server side separately. Read it before you change MX records.

Before you touch anything, run one test: send a message from a domain with a strict DMARC policy to a random address on your catch-all, forward it to Gmail, and inspect the headers. If Authentication-Results shows spf=pass but dmarc=fail on the forwarded copy, you have found the alignment trap. Enable SRS, or move the catch-all to a local mailbox you read over IMAP. Then retest with the same sender. If the forwarded copy now shows dmarc=pass, the catch-all was never broken and you have just saved yourself a rebuild.