A catch-all email address accepts every message sent to your domain, including mail addressed to people who never existed. That is the whole point, and it is also where the trouble starts. Sooner or later a catch-all mailbox gets a filtering rule or a forward that pushes mail off-domain, to a Gmail account, a helpdesk inbox, or a CRM. The moment that hop happens, the authentication chain that SPF, DKIM, and DMARC built at the original sender comes under strain, and the failures get logged against your domain rather than the one that actually sent the message.
This is the part of catch-all email explained that most guides skip. A catch-all email is configured on the mail server, not in DNS. MX records only route inbound mail to a mail server; SPF, DKIM and DMARC govern outbound mail only. So when your catch-all domain forwards a message onward, the forwarder becomes the new envelope sender, SPF evaluates the forwarder’s IP instead of the original one, and a DMARC policy of p=reject on the sender’s side can turn a perfectly legitimate message into a rejection you never see. Two mechanisms exist to patch that hop: ARC sealing, which preserves the original authentication verdicts as a signed chain, and SRS, which rewrites the envelope sender so SPF stays valid downstream.
They solve overlapping problems in different ways, and picking wrong leaves you with residual alignment failures that show up weeks later in DMARC aggregate reports, attributed to your catch-all mailbox rather than to the forwarder. What follows is a walk through the forwarding hop as a mail server actually sees it: how the authentication path breaks, how ARC and SRS each intervene, why p=reject senders end up blaming your catch-all domain, and how to configure and verify either fix on a real deployment.
Catch-All Email Addresses and Why They Forward Off-Domain
A catch-all email address accepts every message sent to a domain, whether or not a real mailbox exists behind the recipient string. If someone writes to anything@yourdomain.com and no defined user matches, the catch-all rule catches it instead of bouncing. That is the catch-all email meaning in one sentence: a wildcard mailbox that swallows the leftovers. It is configured on the mail server, not in DNS. MX records only route inbound mail to a mail server; the decision to accept an unknown recipient happens after delivery, when the server checks its alias table and finds a catch-all entry.
Without that entry, a standard mail server replies with 550 no such user and the message dies at SMTP time. With it, the server accepts the message and hands it to whatever destination the rule names. That destination is frequently not local.
Where catch-all mail usually ends up
Catch-all domains are common in automation and sign-ups, where you want unlimited unpredictable addresses without provisioning each one. The patterns that follow are what push mail off-domain:
- Aliases to an external mailbox. The catch-all points at a Gmail, Outlook, or Google Workspace address. Every accepted message is relayed out, and the forwarder becomes an intermediary in the authentication chain.
- Role address consolidation. A company collects sales@, info@, support@, and every misspelling into one catch-all that forwards to a shared ticketing inbox hosted elsewhere.
- Filtering rules on top of the wildcard. The server accepts everything, then a rule set sorts by recipient pattern and forwards only unmatched or suspicious traffic to a security team’s external address for review.
- Migration and legacy domains. An old domain keeps a catch-all that forwards to the current primary domain, which may sit on a different provider entirely.
Each of these is a legitimate configuration. Each also creates a forwarding hop, and that hop is where authentication gets interesting. The original sender’s SPF record lists their own sending IPs, not your forwarder’s IP. When your catch-all mailbox relays the message onward, the receiving server sees a connection from your infrastructure and evaluates SPF against your domain, or against whatever envelope sender survives the relay. DKIM survives only if the forwarder leaves the message body and signed headers untouched, which many do not once they add a footer or rewrite a subject line.
Catch-all differs from alias, forwarding, and disposable addresses in one key respect: an alias maps a known address to another, a forwarder moves mail for a defined recipient, and a disposable address is issued deliberately. A catch-all accepts unknown recipient acceptance as its default posture, which is exactly why it so often sits in front of an off-domain destination. The pattern is convenient. The forwarding hop it creates is the part that needs engineering.
How SPF, DKIM, and DMARC Break at the Forwarding Hop
Picture the path of a single message. The original sender at example.com submits to their own mail server, which signs the body with DKIM and publishes SPF and a DMARC policy at p=reject. The message lands in the catch-all mailbox on your domain, and a fallback rule forwards it to a Gmail address or a support desk. That forward is where every authentication mechanism starts to come apart.
SMTP forwarding preserves the original envelope sender by default. When your server relays the message onward, it connects from your IP, not the sender’s. The receiving MX at the destination looks up the domain in the MAIL FROM (still example.com), fetches that domain’s SPF record, and checks it against the connecting IP. Your IP is not listed, so SPF returns fail. Nothing malicious happened, but the receiver has no way to know that from SPF alone. SPF was designed to authorize the sending IP, and forwarding always changes the sending IP.
DKIM is more resilient but only conditionally. The signature covers selected headers and a hash of the body. A plain relay that passes bytes through untouched keeps the signature valid, and the destination can still verify it against the sender’s published key. The trouble starts when the forwarder modifies anything: adding a footer, rewriting the subject with a tag, stripping a header, or re-encoding the body. Any of those breaks the body hash, and DKIM fails. Even a valid DKIM signature is not enough on its own, because DMARC requires alignment.
DMARC alignment is the part that bites hardest. The receiver checks whether the domain that passed SPF or DKIM matches the From header domain. With SPF broken by the forwarder and DKIM broken by modification, neither passes, so DMARC fails. If the sender published p=reject, the destination is instructed to reject or quarantine the message. Your catch-all domain has just caused a legitimate message from a p=reject sender to be dropped at the final destination, and the failure gets logged against the original sender’s domain.
A concrete example makes it stick. Sender publishes v=spf1 ip4:203.0.113.10 -all and DMARC at p=reject. Your catch-all at mail.contoso.example forwards from 198.51.100.25. Destination SPF check: 198.51.100.25 is not 203.0.113.10, so fail. DKIM: the forwarder appended a “Forwarded by Contoso” line, so the body hash mismatches. Result: DMARC fail with p=reject. The receiver returns a 550 or silently quarantines, and the sender’s aggregate report shows a failure from an IP they never authorized.
The core fact to hold onto: a catch-all email is configured on the mail server, not in DNS, and the forward it performs is invisible to SPF, DKIM, and DMARC unless the forwarder takes explicit action. That action is either ARC sealing or SRS rewriting, covered next.
ARC Sealing vs SRS Rewriting at the Catch-All Forwarder
Two fixes exist at the forwarding hop, and they solve different halves of the problem. ARC (Authenticated Received Chain) preserves the original authentication verdicts across intermediaries by adding a signed header set at each hop. catch all email meaning offers additional context worth reviewing. SRS (Sender Rewriting Scheme) rewrites the envelope sender so SPF stays valid downstream. A catch-all email configured on the mail server, not in DNS, is precisely the kind of wildcard mailbox that ends up forwarding off-domain, so operators running one usually need to pick a side.
ARC works like a chain of custody. Each forwarder that supports it adds an ARC-Seal, an ARC-Message-Signature, and an ARC-Authentication-Results header, then cryptographically seals the set. When the message reaches the final receiver, that receiver can see the original SPF and DKIM results from the first hop and trust them if the chain validates and the sealer is on a short list of known intermediaries. Nothing in the message body or headers is modified, so DKIM signatures from the original sender stay intact. The catch: the receiving side must actually evaluate ARC. Gmail and Microsoft 365 do, in varying degrees. Plenty of smaller MTAs and spam filters ignore the headers entirely and fall back to plain SPF and DMARC checks, which brings the failure right back.
SRS takes a blunter approach. The forwarder rewrites the MAIL FROM address to something like SRS0=hh=aa=example.com=user@forwarder.tld, keeping a timestamp and hash so bounces can be routed back to the original sender. SPF now evaluates against the forwarder’s own domain, which passes because the forwarder controls its own SPF record. The original sender’s domain is no longer in the envelope, so SPF alignment for DMARC is broken unless the From header domain still matches something. SRS also mutates the envelope, which some mailing lists and autoresponders handle poorly, and hash secrets must be rotated without breaking in-flight bounces.
Where each one fails in practice:
- ARC fails silently when the final receiver does not validate the chain, and the message is scored as if no authentication had happened.
- ARC sealers must be trusted by the receiver; an unknown forwarder’s seal is often discarded.
- SRS breaks DMARC alignment for strict p=reject senders because the envelope domain no longer matches the From domain.
- SRS hash rotation and timestamp windows cause bounces to be dropped if the secret changes mid-flight.
- Neither scheme helps if the forwarder strips DKIM signatures or rewrites the Subject or body.
A working catch-all setup requires DNS pointing at the right host and a server accepting unknown recipients, but the forwarding hop is where the authentication chain breaks. The pragmatic default: enable ARC sealing if your forwarder supports it and your downstream receivers are mostly Gmail or Microsoft, and layer SRS on top for older receivers that still lean on SPF. Test both with real messages before trusting either.
Why DMARC p=reject Senders See Failures Attributed to Your Catch-All Domain
Here is the part most operators miss until a sender’s postmaster emails them directly: the failure lands on your name, not the forwarder’s. A catch-all email accepts every message sent to a domain, and when a filtering rule or alias pushes that mail to an external destination, the forwarder becomes an intermediary. The original sender published DMARC p=reject. Their SPF record authorizes their own sending IPs. Your forwarder is not on that list. The receiving mailbox evaluates SPF against the connecting IP of your server, gets a fail, and unless something else passes, the message is rejected or spam-foldered. The sender’s DMARC aggregate report then shows a failure with your domain in the forwarder position.
Trace the alignment. SPF checks the envelope sender domain against the IP that connected. At the forwarding hop, the envelope sender still reads as the original sender, but the IP belongs to your catch-all mail server. That is a hard fail on SPF. DKIM survives only if your forwarder leaves the body and signed headers untouched, which many do not: subject tagging, footer injection, and list headers all break the hash. If both SPF and DKIM fail at the destination, DMARC p=reject fires. The receiving MTA logs something like dmarc=fail spf=fail dkim=none against the original sender’s domain, with the connecting IP being yours. The original sender never sees your domain in their own logs unless they read the report XML closely.
What the reports actually say, and why blame drifts
DMARC aggregate reports are sent to the domain in the From header, which is the original sender. Each record carries a source IP, a count, and a disposition. When your catch-all forwards off-domain, that report lists your forwarder’s IP as the source. To the sender, it looks like an unauthorized relay is spoofing them. Some senders respond by blocking your IP outright, and shared hosting makes that worse because the block hits every customer on that range.
The misdirection is structural. A catch-all email is configured on the mail server, not in DNS, so the sender cannot see your routing rules. MX records route inbound mail to a mail server, but they say nothing about what that server does next. SPF, DKIM and DMARC govern outbound mail only, which means the sender’s policy cannot describe your forwarding behavior. A standard mail server replies with 550 no such user when no mailbox matches, and that clean rejection is exactly what a p=reject sender expects. Your catch-all defeats that expectation by accepting the message and then relaying it, so the failure surfaces downstream with your IP attached. Without ARC sealing or SRS at that hop, the receiver has no signed record of the original authentication verdicts, and the report attributes the break to the last hop it can see. That hop is yours.
One practical detail: receivers log the ARC result separately from DMARC. If you seal, the destination’s log shows arc=pass alongside dmarc=fail, and many mailbox providers use the ARC verdict to override the reject. If you do not seal, that column is empty and the reject stands. Check your own outbound logs for the 550 responses before assuming the sender misconfigured anything.
Implementing ARC or SRS for a Catch-All Mailbox: Configuration and Verification
Before you touch a config file, find out what the receiving side actually honors. ARC sealing only helps if the downstream mailbox provider validates ARC and folds the chain into its DMARC decision. Gmail and Microsoft 365 both do this. Plenty of smaller providers and self-hosted stacks either ignore ARC headers entirely or strip them at the edge. SRS is the opposite problem: it works with any receiver because SPF stays valid, but it rewrites the envelope sender, which breaks SRS-unaware bounce handling and can trip DMARC alignment if you rewrite the wrong domain. Check your top ten forwarding destinations by volume first, then pick per-route rather than globally.
| Option | What it fixes | Receiver requirement | Main failure mode |
|---|---|---|---|
| ARC sealing | Preserves original SPF and DKIM verdicts across the hop | Downstream must validate ARC and use it in DMARC evaluation | Ignored or stripped by receivers that do not implement ARC |
| SRS rewriting | Keeps SPF valid by rewriting the envelope sender to your domain | None, works with any SPF-checking receiver | Bounces return to you, not the original sender; SRS-unaware relays break |
| ARC plus SRS together | Covers both SPF and DKIM paths | ARC-aware receiver for full benefit | More moving parts, harder to debug header chains |
| Forward without either | Nothing | None | SPF fails at the hop, p=reject senders get DMARC failures blamed on your domain |
Configuring the forwarder itself depends on your platform. In Postfix, SRS is handled by postsrsd, which you wire into the cleanup and smtp stages; ARC sealing comes from OpenARC or the built-in milter in newer releases. On a hosted catch-all mailbox, the control is usually a checkbox labeled “preserve authentication” or an ARC signing toggle in the mail routing panel. In Cloudflare Email Routing, catch-all forwarding to an external address passes mail through Cloudflare’s own infrastructure, and their ARC signing is automatic, so verify the chain rather than assume it. Whichever path you take, confirm the forwarder signs with a key published in DNS and that your SPF record lists the forwarder’s sending IPs if SRS is in play.
Testing is where most deployments stop too early. Send a message from a domain you control with DMARC at p=reject, forward it through the catch-all, and read the raw headers at the destination. You want to see an ARC-Authentication-Results set showing spf=pass or dkim=pass from the original hop, and an ARC-Seal that validates. Then watch DMARC aggregate reports for the original domain: failures attributed to your catch-all domain after the hop are the signal that sealing is not landing. Give it a week of reports before you call it done, and recheck whenever you change the forwarder or its IPs, because a silent config drift is the usual culprit for residual alignment failures.
If you run a catch-all forwarder, the simplest next step is an audit: take three or four recent messages that your catch-all relayed off-domain and inspect their headers at the final destination. Look for an ARC-Authentication-Results set that records what your hop saw, and check whether the envelope sender still belongs to the original domain or has been rewritten to yours by SRS. If neither is present and the original sender publishes p=reject, you have a failure waiting to happen, and the DMARC aggregate reports landing in that sender’s inbox will keep pointing at your catch-all domain until you fix the hop.
Then pick your fix based on what the receivers downstream actually support. Most large mailbox providers validate ARC chains, so sealing at the forwarder is the least invasive option: the original SPF and DKIM verdicts travel with the message, and the final receiver can weigh them even though the connecting IP is yours. SRS is the safer bet when you forward to smaller hosts or older gateways that ignore ARC headers, since rewriting the envelope sender keeps SPF passing at every hop, at the cost of hiding the original return path. Whichever you choose, verify it end to end: send a test message through the catch-all from a domain you control with p=reject, confirm the ARC headers or the rewritten envelope at the destination, and recheck your DMARC aggregate reports a week later for residual alignment failures. A catch-all email address is only as useful as the mail it can actually deliver, and that last forwarding hop is where the whole chain either holds or falls apart.