DMARC Failures You Didn’t Cause: Catch-All Relaying

You set up a catch-all email address so nothing bounces. Six weeks later, a stranger emails you about a DMARC failure report from your domain, and the message in question is one you never sent. You forwarded it. That is the shape of the problem: a catch-all mailbox accepts every message sent to a domain, including mail addressed to invented local parts, and when it relays that mail off-domain, SPF, DKIM, and DMARC alignment can all break in transit. The original sender sees the failure, not you.

The mechanics are not mysterious once you separate the pieces. MX records route inbound mail to a mail server. The server decides what to do with a local part that matches no mailbox, and a catch-all domain tells it to accept the message anyway instead of replying with 550 no such user. Relaying happens after that decision, and relaying is where authentication starts to fray. SPF checks the envelope sender against the connecting IP, DKIM signs specific headers and body, and DMARC requires identifier alignment between what the user sees and what authenticated. Break any link in that chain and the receiving provider logs a failure attributed to the domain in the From header, which belongs to someone else.

This piece walks through the failure modes and the two fixes that matter: ARC sealing, which preserves prior authentication results across the hop, and SRS rewriting, which repairs the envelope so SPF survives forwarding. Neither is a complete answer, and the trade-offs differ by deployment. If you run a catch-all mailbox that relays mail for external senders, the goal is to know exactly which failures are yours, which are the sender’s, and where to draw the line before a catch-all domain becomes a reputation liability you cannot audit.

What a Catch-All Email Address Actually Does at the SMTP Layer

A catch-all email address is a mailbox that accepts every message sent to a domain, regardless of the local part in front of the @ sign. Someone writes to anything@yourdomain.com, and the mail server hands it to one designated catch-all mailbox instead of bouncing it. That is the whole trick, and it happens in one place: the mail server. A catch-all email is configured on the mail server, not in DNS. MX records route inbound mail to a mail server, but they do not decide which local parts exist. That decision belongs to the server’s recipient table, alias file, or virtual mailbox configuration.

People mix up four terms that describe different layers of the same setup. A catch-all email address is the wildcard recipient itself. A catch-all mailbox is the physical inbox that collects the mail. A catch-all domain is a domain configured to accept all addresses rather than a fixed list. And a wildcard mailbox is the server-side rule, often written as @domain.com or *@domain.com, that matches any unknown local part. The catch-all email meaning is simple once you separate them: unknown recipient acceptance at the server level, not a DNS feature and not a client setting.

Contrast that with the options people confuse it with. An alias maps one specific address to another specific address. Forwarding sends mail for a known address to an external inbox. A disposable address is a throwaway local part you create on purpose. None of them accept mail for addresses that were never defined. A catch-all does, and that difference is where the trouble starts.

Here is the part that catches operators off guard. A standard mail server replies with 550 no such user when no mailbox matches. That bounce is a signal to the sending side: the address does not exist, stop retrying. A catch-all suppresses that signal for every invented local part, and if the catch-all mailbox then forwards mail off-domain, the message leaves your server under someone else’s identity. The original sender never asked for that hop, and their authentication records were never written to survive it. Catch-all domains are used for unlimited unpredictable addresses in automation and sign-ups, which is exactly why the forwarding surface grows quietly and why the DMARC failures show up later, attributed to domains you do not own.

How SPF, DKIM, and DMARC Alignment Break During Relaying

A catch-all email accepts every message sent to a domain, including mail addressed to local parts that were never provisioned. That behavior is configured on the mail server, not in DNS. MX records only route inbound mail to a mail server, and once the message lands, the catch-all mailbox takes over. The trouble begins when that mailbox forwards the message off-domain. At that instant, three separate authentication systems see three different versions of who sent what, and each one can fail independently.

SPF: The Envelope Sender No Longer Matches the Connecting IP

SPF checks the envelope sender (MAIL FROM) against the IP address that connects to the receiving server. When your catch-all relays a message, the connecting IP is yours, not the original sender’s. If the envelope sender is still alice@example.com, the recipient’s server looks up example.com’s SPF record, finds your relay’s IP missing, and records a fail. The original sender never touched the connection, yet their domain carries the result.

DKIM: The Signature Survives Only If Nothing Is Rewritten

DKIM signs specific headers and the body with a private key published in DNS. A plain forward usually preserves the signature, so DKIM can still pass at the final destination. It breaks when the relay modifies a signed header (adding a subject tag, appending a footer, re-encoding the body) or when the signing domain’s selector is unreachable. A pass here proves the message was signed by the domain, not that the forwarder is legitimate. That distinction matters for the next check.

DMARC: Alignment Is Where Relayed Mail Falls Apart

DMARC requires identifier alignment: the domain in the From header must match the domain that passed SPF or DKIM. A relayed message keeps the original From header, so alignment depends on whether the original domain’s SPF or DKIM still passes after the hop. SPF almost never does. DKIM does only if the signature is intact. When both fail, DMARC reports a failure against the original sender’s domain, and a p=reject policy tells the receiver to quarantine or reject mail the sender never sent through your server. The checks that break, in order of likelihood:

• SPF fails because the relay IP is not in the original domain’s record
• DKIM fails when the relay rewrites a signed header or body part
• DMARC alignment fails when neither SPF nor DKIM passes for the From domain
• DMARC passes only if DKIM survives untouched through the hop

The practical consequence: SPF, DKIM and DMARC govern outbound mail only, yet a catch-all relay turns your inbound path into an outbound path for someone else’s domain. The visible failure lands on the sender’s reputation, not yours, which is why relayed DMARC failures often surface first in someone else’s aggregate reports.

Why the Original Sender Gets Blamed for Your Relay

The failure report lands in the inbox of a company that has never heard of you. Their DMARC aggregate feed shows a message claiming to be from their domain, failing alignment, arriving from an IP they do not recognize. That IP belongs to your catch-all host. The original sender did nothing wrong, you did nothing malicious, and yet their domain reputation takes the hit. This is the part of catch-all relaying that surprises people most: the damage is billed to the wrong party.

The mechanics are simple once you trace one message. Someone at partner.example sends mail to anything@yourdomain.com, an address that does not exist as a real mailbox but is swallowed by your catch-all. Your server accepts it, then a forwarding rule re-emits it to the final destination with the original From: header intact. At the receiving end, DMARC evaluates the message against partner.example, not against your domain. SPF fails because the connecting IP is yours, not theirs. DKIM may fail if the forward altered the body or stripped a header. The verdict is recorded against the domain in the From: field, which is the sender who never touched your infrastructure.

What the original sender sees is a stream of failures from an IP they cannot account for, against a domain they control, at a volume they did not send. If they run p=reject, their own legitimate mail is unaffected, but their aggregate reports fill with noise and their security team opens an investigation into phantom spoofing. Some receivers apply reputation penalties to the domain in the failing reports, which means your forwarding habit can quietly degrade deliverability for a business that has no relationship with you at all.

There is no clean way to shift that blame after the fact. The receiving MTA logs the failure against the From: domain because that is what DMARC specifies, and the forwarding hop leaves no durable trace in the report beyond the source IP. You can identify yourself in the report only if you rewrite the envelope (SRS) or seal the authentication results (ARC), which are the subjects of the next two sections. Without one of those, the visible failure belongs to the original sender by design.

This is why catch-all domains that relay external mail are a reputational liability you inherit from strangers. Every forwarded message is a small debit against someone else’s domain, and enough of them turn a quiet catch-all mailbox into a source of complaints you will never see. The practical rule: if a catch-all forwards mail for senders you do not control, assume their DMARC reports are already showing your IP, and treat that as a defect to fix rather than a curiosity to ignore.

ARC Sealing: Preserving Authentication Across the Forwarding Hop

ARC exists because every other authentication mechanism in the chain asks the final receiver to judge a message by what it can see right now. By the time your catch-all mailbox relays a message, the connecting IP belongs to you, the DKIM signature may cover headers your forwarder rewrote, and the SPF result reflects your server, not the original sender. ARC flips the question: instead of re-evaluating from scratch, the receiver can read what earlier hops already concluded.

Mechanically, an ARC set has three parts. The ARC-Authentication-Results header records what the sealing hop observed (SPF, DKIM, DMARC results for the original message). The ARC-Message-Signature is a DKIM-style signature over selected headers and the body as they existed at seal time. catch all email meaning offers additional context worth reviewing. The ARC-Seal signs the entire chain of prior ARC sets plus the current one, so any later tampering or reordering invalidates the seal. When your catch-all server forwards mail, it adds one set. The receiving provider, if it supports ARC, validates the seals in order and can decide to honor the earlier DMARC pass even though its own SPF and DKIM checks fail.

The practical value is narrow but real. Gmail has validated ARC since 2016 and uses it as one input in its spam and authentication scoring; Microsoft added ARC validation to Outlook.com and Office 365 several years later. The catch is that ARC is a signal, not a guarantee. A receiver that sees a valid chain still applies its own judgment, and a chain sealed by a hop with a poor reputation can hurt rather than help. Also note that ARC does not change the visible From header, so DMARC alignment at the final receiver still fails on paper; the receiver simply has grounds to overlook it.

What ARC cannot fix is anything broken before the seal. If the original message already failed DMARC at your server, sealing it just preserves a failure. If your forwarder rewrites the body (adding a footer, stripping attachments, reformatting HTML), the ARC-Message-Signature covers the rewritten version, and the original DKIM signature is dead regardless of what the chain says. Keep relay processing byte-faithful if you want ARC to do its job.

Operational limits matter more than the spec. Adoption is uneven: many smaller ISPs, regional providers and self-hosted mail systems ignore ARC entirely and fall back to strict DMARC evaluation. Chain length is also bounded; some receivers cap the number of ARC sets or distrust chains from unknown sealers. If your catch-all sits behind a mail gateway that strips or reorders Authentication-Results headers, the seal you produce may be rejected downstream. Test with real sends to Gmail and Outlook before you trust ARC as your only mitigation.

SRS Rewriting: Fixing the Envelope Without Touching the Header

SRS exists because of one hard fact: SPF checks the envelope sender (MAIL FROM) against the IP that connects. When your catch-all accepts mail for anything@yourdomain.tld and forwards it to a real mailbox, the connecting IP belongs to your relay, but the envelope sender still says someone@theirdomain.com. That sender’s SPF record was never written to authorize your server, so the check fails at the receiving end. Sender Rewriting Scheme fixes this by rewriting the envelope sender at the forwarding hop into something your domain can authorize, typically SRS0=HHH=tt=someone=theirdomain.com@yourdomain.tld. The local part carries an HMAC hash, a timestamp, and the original address encoded so the relay can reverse it later. Now SPF evaluates against your domain, which does authorize your relay, and the check passes.

The mechanism is deliberately narrow. SRS touches only the envelope, never the message header. From: stays exactly as the original sender wrote it. That restraint is the point: the receiver can still see who really sent the message, and bounce messages can be routed back to the original sender instead of landing in your catch-all as a mail loop. Without that reversal step, a forwarded message that bounces would bounce back to the envelope sender, which is now your domain, which means your catch-all accepts the bounce, forwards it again, and you get a loop. SRS breaks the loop by keeping the original address recoverable inside the rewritten local part.

What SRS does not solve matters more than what it does. It has no effect on DKIM. If the original sender signed the message and the body or signed headers survive the forward untouched, DKIM still validates, but many forwarders add headers or alter the body and break the signature. It has no effect on DMARC alignment either: DMARC wants the From: domain to align with an authenticated SPF or DKIM identifier, and SRS changes the SPF identifier to your domain while From: still belongs to the original sender. So a forwarded message can pass SPF under SRS and still fail DMARC alignment unless DKIM survives. For a sender publishing p=reject, that is a failure you caused and they get blamed for.

SRS also breaks in specific places. It fails when the forwarding hop cannot rewrite, which is common in simple mail server rules and in some hosted catch-all implementations that forward at the MTA level without a rewriting layer. It fails when the rewritten address exceeds the 64-character local-part limit, which truncation then makes unreversible. It fails when the timestamp window expires before a bounce returns. And it fails when the receiving side rejects the rewritten address as a forgery attempt. Practical mitigations include keeping your own SPF record tight so the rewritten envelope actually passes, enabling SRS only on the forwarding path, and logging every rewrite so you can trace a bounce back through the hash. Cloudflare Email Routing and cPanel forwarders both rewrite the envelope in some configurations, but neither guarantees it for every rule you build.

Choosing Between ARC and SRS for Your Catch-All Mailbox

ARC and SRS fix different halves of the problem, and most catch-all operators end up needing both. The fastest way to choose a starting point is to look at which failure your DMARC aggregate reports actually show.

Failure mode, effort, and receiver support side by side

The failure mode drives the decision more than anything else. If your reports show SPF failures on relayed mail from senders with a strict DMARC policy, SRS closes that gap immediately because it changes the envelope before the message leaves your host. If your reports show DKIM failures after forwarding, SRS does nothing, and ARC sealing is the only mechanism that carries the original signature’s verdict forward.

Deployment complexity usually favors SRS for small setups. A catch-all on cPanel or a Postfix relay can add SRS with a package and a couple of config lines, while ARC signing requires a milter that understands the chain and a validation step on the outbound path. On larger infrastructure the balance flips, because ARC sealing happens once at ingress and does not touch individual forwarding rules.

Receiver support is the tiebreaker. SRS guarantees an SPF pass at every hop that checks SPF, but it cannot rescue DMARC alignment for a sender publishing p=reject with strict alignment. ARC can, but only at receivers that validate it. For a catch-all domain relaying mail for external senders, the practical answer is SRS for the envelope plus ARC for the chain, with DMARC reporting left on so you can see which mechanism is actually saving messages. If you can only run one, run SRS first when SPF failures dominate, and ARC first when DKIM failures dominate.

Configuring and Monitoring a Catch-All Domain Without Causing DMARC Failures

Configuration starts with an honest inventory. List every address your catch-all has accepted in the last 90 days, then split it into three buckets: legitimate mail you must forward, mail you should store locally, and pure noise. That list drives everything else, because the forwarding rules are where the authentication damage happens.

Forwarding Rules, DNS Records, and Report Analysis

For each forward that leaves your domain, decide the mechanism before you write the rule. If the destination is a major mailbox provider that validates ARC, seal the hop and forward the message intact. If the destination is a smaller host or an old MTA that ignores ARC, rewrite the envelope with SRS instead. Never do both blindly on the same rule set; pick one path per destination and document it, because a mixed setup makes aggregate reports almost impossible to read.

DNS has to match the plan. Your MX records route inbound mail to the mail server, and the catch-all itself is configured on that server, not in DNS. Keep SPF, DKIM, and DMARC records on the forwarding host correct for mail it originates, and remember that those records govern outbound mail only; they do nothing to protect a relayed message whose original authentication already passed elsewhere. If you run Cloudflare Email Routing or a cPanel-style host, confirm the wildcard mailbox or accept-all setting is actually active and that the server, not just the DNS zone, accepts unknown recipients. A working catch-all setup requires both halves.

Monitoring is where most operators fall short. Publish a DMARC record with a reporting address (rua) on the catch-all domain, collect aggregate XML reports for at least 30 days, and filter for failures where the reported header From domain is not yours. Those are the relayed messages. Group them by original sender domain, count the failures per sender per day, and check whether the failure type is SPF, DKIM, or alignment. A steady trickle from one sender usually means a broken forward; a spike across many senders usually means your catch-all is accepting spam to invented addresses and forwarding it.

Set thresholds in advance. As a working rule: if more than 5 percent of relayed messages from any single external sender produce DMARC failures at the destination, fix the rule with ARC or SRS within a week. If a forward cannot be sealed or rewritten, disable it and store mail in a local catch-all mailbox instead. If the whole catch-all cannot be sealed and the failure rate stays above 10 percent for two weeks, retire it. A catch-all domain that quietly damages other senders’ reputation is not worth the convenience.

Start with an inventory before you change anything. Pull 30 days of DMARC aggregate reports for the catch-all domain, group failing records by the reported domain in the policy_published block, and flag any source IP that belongs to your own relay rather than to the sender. Those records are the ones you caused. For each, check whether the relay adds ARC seals and whether it rewrites the envelope with SRS; a quick dig on the relay’s SPF record and a look at the topmost Authentication-Results header on a forwarded test message will tell you. Send one test message through the catch-all from a Gmail account, then read the full header chain at the destination: you want to see arc=pass with a valid chain, or an envelope sender rewritten to your own domain that passes SPF. If neither appears, the catch-all is leaking authentication failures onto strangers’ domains and you have three options: move the relay to a host that seals with ARC, add SRS at the edge, or replace the catch-all with explicit aliases for the addresses you actually need. The last option costs the least and breaks the least.

Whatever you choose, write it down and review it quarterly. Catch-all domains accumulate forwarding rules quietly, and a rule added eighteen months ago for a vendor signup is still relaying mail today. Keep a short list of every local part that forwards off-domain, note which ones are sealed or rewritten, and retire the rest. If you want a second opinion on the header chain from your test message, AllMail.one publishes a guide to catch-all email that walks through the same checks with sample headers. Run the test, read the chain, and decide from evidence rather than from the assumption that forwarding is harmless. The 550 no such user reply that a standard mail server would have returned is not a bug to route around; it is the signal that keeps your domain out of other people’s failure reports.