Why forwarding gets you blocklisted (the mechanics, not the vibes)
Here is the failure chain, and every operator of a forwarding or disposable-mail service meets it eventually. A spammer sends to [email protected]. Your MX accepts it, because at accept time it looks like ordinary mail. You forward it to the user's real inbox at Gmail. Now Gmail sees a message where the envelope sender is still [email protected] but the connecting IP is yours. SPF checks evil.biz's policy against your IP and returns fail. DKIM might survive if the spammer signed it, but DMARC alignment is already gone. Gmail files the message as spam, the user hits "report spam," and that complaint is attributed to the IP that delivered it — you. Stack up a few hundred of those and your forwarding IP lands on Spamhaus CSS or XBL, or flips red in Microsoft SNDS. From then on every *legitimate* alias forward you send bounces with 550 5.7.1 Service unavailable; Client host blocked.
You are managing exactly three reputation surfaces, and you should be able to name them cold:
- The connecting IP (or IP pool) that opens the outbound SMTP connection to the destination.
- The forwarding domain(s) that appear in your rewritten envelope and DKIM signature.
- The rDNS / HELO identity that receivers use to decide whether you are who you claim to be.
The structural tension of a disposable service is that it *maximizes account churn* — new addresses, new recipients, high create-and-discard velocity — and account churn is precisely the behavioral signal blocklists use to flag abuse. You do not get to opt out of that tension. You get to engineer around it.
Re-seal identity on the way out: SRS + ARC + DKIM
Forwarding breaks authentication because the message's envelope and headers were authored for a *direct* path, not a relayed one. RFC 7960 is the canonical write-up of exactly these interoperability failures — read it once so you stop treating them as surprises. Your job on egress is to re-establish a coherent identity the destination can evaluate.
SRS (Sender Rewriting Scheme) rewrites the envelope MAIL FROM to your own domain. The original [email protected] becomes something like [email protected], where HHH is a hash and TT a timestamp. Two things follow: SPF at the next hop now checks *your* domain against *your* IP and passes, and any bounce comes back to evilmail.pro, where you decrypt the SRS token and process it — instead of blasting a backscatter NDR at an innocent third party.
On Postfix, the standard tool is postsrsd, which runs a small daemon on 127.0.0.1:10001/10002 and plugs in as a sender canonical rewriter:
# /etc/postfix/main.cf
sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient, header_recipientARC (Authenticated Received Chain) solves the other half. SPF and DKIM will *legitimately* break across a forwarding hop for reasons no rewrite can fix — a body footer, a re-encoded MIME part, an SPF check that no longer sees the origin IP. ARC lets you record the authentication verdict you observed at inbound time and cryptographically seal it, so the destination can trust "evilmail.pro checked this and SPF/DKIM passed at the previous hop" even though those checks fail when Gmail re-runs them. A correctly forwarded message carries ARC-Authentication-Results: i=1, an ARC-Message-Signature, and an ARC-Seal. Rspamd ships a native ARC module — but it must run after your own auth verdict, never before.
That ordering is the whole ethical point: an ARC-Seal is you *vouching* for the mail. You are telling the next hop "trust my assessment." So only seal mail you would stand behind. Blindly ARC-sealing spam because it happened to pass DKIM at origin is how you convert a technical mechanism into a reputation liability. Seal clean mail; drop the rest before it ever reaches the sealer. And re-sign every forwarded message with your own DKIM key on evilmail.pro, so there is at least one aligned, passing signature the destination can hang alignment on.
Filter at the boundary, not after acceptance
The single most expensive mistake a forwarder makes is accept-then-bounce. If you accept a spam message into your queue and later generate a non-delivery report back to the forged sender, you have just emitted backscatter — and backscatter gets you listed on backscatterer.org, and drags your IP toward Spamhaus CSS, faster than the original spam would have. The rule is absolute: reject during the SMTP transaction with a 5xx, so the *originating* server owns the failure. You never take responsibility for mail you are not going to deliver.
Rspamd is the workhorse here. Its default action thresholds are tuned for a mailbox provider, not a forwarder, so tighten them. Out of the box you get roughly greylist at 4, add-header at 6, reject at 15. For a forwarder — where every message you accept is one you will re-sign and vouch for — pull the reject threshold down and open a quarantine band:
# /etc/rspamd/local.d/actions.conf
greylist = 4;
add_header = 6;
quarantine = 8; # hold for review / drop to a spam alias, do NOT forward
reject = 12; # 5xx in-transaction — originating server owns the bounceAnything scoring 12 or above never enters your queue. The 8–12 greyzone gets quarantined — routed to a per-account junk folder or dropped, but *not* forwarded to the user's real inbox, because a delivered-then-complained message costs you far more than a rejected one. Use the multimap and ratelimit modules for per-recipient caps so a single compromised or targeted alias cannot pump thousands of messages through you in an hour.
URL and attachment scanning matters even for mail you are only relaying, because the destination judges *you* by the payload that arrived from your IP. Wire Spamhaus DBL and SURBL into Rspamd's surbl/rbl modules so a message whose links sit on a domain blocklist scores toward reject. And enforce the boundary at the Postfix layer too, before Rspamd even runs:
# /etc/postfix/main.cf
smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_unknown_reverse_client_hostname,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client b.barracudacentral.org,
permitzen.spamhaus.org is the combined zone (SBL + CSS + XBL + PBL) — one lookup covers the surfaces that matter for inbound abuse.
Gate the humans: signup and account abuse scoring
A disposable service lives or dies on account controls, because your reputation is a weighted average of your users' behavior and the abusers are the ones actively working to concentrate their damage on you. Cheap, high-leverage controls:
- Forwarding disabled until the recovery address is verified. No verified human, no relay. This alone kills most drive-by abuse signups.
- Per-account and per-IP receive-rate caps. A free account capped at ~50 inbound messages/hour is invisible to a real user and a hard ceiling for a spam sink.
- Block paid-alias signups from hosting and VPN ASNs. Legitimate users buying a persistent alias are not signing up from an OVH or DigitalOcean IP. Maintain an ASN blocklist for the paid tier, and stay more lenient on the free/temporary tier, where transient users legitimately arrive from everywhere.
- Disposable-domain blocklist on the recovery email. If someone tries to anchor account recovery to another throwaway service, that is a laundering setup, not a customer.
- A trust score that starts low and rises with age and payment. New accounts get the tightest caps and the strictest content thresholds; a six-month-old paying account earns headroom.
Prefer shadow-limiting over hard blocking wherever you can. A hard 5xx or an account-suspended banner tells the abuser exactly what tripped, and they iterate against it. Silently dropping over-cap forwards into a sink, or quietly slowing an account's throughput, costs them time and hands them no signal to tune against.
Close the loop: FBLs, monitoring, and auto-ejection
You want to eject an abuser in minutes — before a blocklist ejects your whole IP for you. That takes two feeds: complaints from the receivers, and your own listing status.
Enroll every forwarding IP and domain in feedback loops: Microsoft SNDS plus JMRP (Junk Mail Reporting Program), Google Postmaster Tools, the Yahoo/Cloudmark Complaint Feedback Loop, and the individual ISP loops (Comcast, Cox). Complaints arrive as ARF reports (message/feedback-report, RFC 5965). Parse them automatically: extract the original recipient, map it back through the alias to the owning account, and increment that account's complaint counter. Gmail treats a spam rate above 0.3% as "high" and anything sustained over 0.1% as danger territory — so wire your auto-suspend to trip *earlier*, at 0.05%, and disable that account's forwarding automatically. Acting before you cross the receiver's own threshold is the entire game.
Self-monitor against DNSBLs on a cron so you learn about a listing from your own alerting, not from a wave of user tickets. The lookup is a reversed-octet DNS query into the list zone:
# IP 203.0.113.10 → reverse octets, append the zone
dig +short 210.69.22.212.zen.spamhaus.org
# any A record (e.g. 127.0.0.2 / .3 / .4) = LISTED; empty = cleanRun it against ZEN, Barracuda, SpamCop, and SORBS for each egress IP every few minutes, and page on the first non-empty answer.
Egress hygiene: rDNS, dedicated IPs, and warmup
The unglamorous prerequisites decide whether Gmail and Outlook even give your mail a fair hearing:
- Forward-confirmed rDNS. The PTR of every sending IP must resolve to a FQDN, and that FQDN's A record must point back to the IP.
HELO/EHLOmust equal that same FQDN. A mismatch is an instant score penalty at both Gmail and Outlook. - RFC 2142 mailboxes that a human reads.
postmaster@andabuse@must exist, and your published abuse contact must be accurate — that is the channel through which delisting requests and complaint escalations reach you. - Separate the transactional IP from the forwarding IP. Your password resets, receipts, and welcome mail must not share reputation with your forwarding stream. When a forwarding IP takes a hit, your own system mail has to keep flowing.
- TLS on egress. Publish an MTA-STS policy (
_mta-stsTXT record plus the policy file athttps://mta-sts.evilmail.pro/.well-known/mta-sts.txt) and DANETLSArecords. Some receivers now penalize opportunistic-only cleartext delivery.
Operator checklist
- SRS on — envelope
MAIL FROMrewritten to your domain viapostsrsd, bounces routed back to you. - ARC sealing on — seal *after* your own auth verdict, only on mail you would vouch for.
- DKIM egress key published — every forwarded message re-signed and aligned to your domain.
- Inbound reject threshold set low — Rspamd reject ≈12, quarantine band 8–12, nothing dubious forwarded.
- Backscatter off — reject spam with 5xx *in-transaction*; never accept-then-NDR.
- RBL checks at the boundary —
reject_rbl_client zen.spamhaus.orgplusreject_unknown_reverse_client_hostname. - FBLs enrolled for every IP — SNDS/JMRP, Google Postmaster, Yahoo/Cloudmark, ISP loops; ARF parsed automatically.