Your staging inbox shouldn't be a free-for-all.
Whitelist senders, block domains, and set rate limits — all at the inbox level. Your sending app receives a real rejection response for every blocked email. Not a silent drop. Not a display filter. A genuine gateway-level decision.
WHAT IS EMAIL INBOX FIREWALL
Inbox-level rules that behave like a real email gateway
Every email hitting your Sandbox inbox is evaluated like a real email gateway. Allowed emails land. Blocked emails are rejected — and your sending app receives a genuine SMTP rejection response, not a success.
Zunoy Email Inbox Firewall acts as an email firewall for your staging environment — with allowlists, blocklists, and SMTP-level rejection handling. Rules are configured per inbox, active immediately, and fully independent across environments.
No rules set? All senders are accepted unless explicitly blocked. Set up rules only when you need them.
Define who gets in. Define who doesn't.
Allowed Domains
Only emails from specified domains are accepted. Everything else is rejected at the gateway level.
payments.yourapp.com
noreply.yourapp.com
Allowed Email Addresses
More granular than domain-level. Specify exact sender addresses that are permitted. Useful when you need to isolate a single sender within a broader domain.
billing@yourapp.com
alerts@yourapp.com
Blocked Domains
Emails from specified domains are always rejected — regardless of any other rule.
marketing.yourapp.com
newsletter.yourapp.com
Blocked Email Addresses
Block specific senders outright. Emails from blocked addresses are rejected immediately on arrival.
noreply@thirdpartyservice.com
digest@analytics.yourapp.com
Rule Priority
Blocked rules always take priority over allowed rules. If a sender matches both an allowed domain and a blocked address — the block wins. Every time.
No Rules Needed to Start
If no allowed rules are defined, all senders are accepted unless explicitly blocked. You don't need an allowlist to get started — only add one when you need to restrict the inbox to specific senders.
What the sending app receives on a blocked email
550 5.1.1 Message rejected
Reason: Sender domain blocked by inbox firewall
Inbox: staging-qa@sandbox.zunoy.com
Your app receives a real SMTP rejection — the same kind a real carrier would return. Your error handling, retry logic, and alerting are all testable against genuine rejection behaviour.
Test how your app behaves when the gateway throttles.
Set a maximum number of emails your inbox accepts per hour or per day. Emails that exceed the limit are rejected — and your sending app receives the rejection response.
Per Hour Limit
Set the maximum emails accepted within any rolling 60-minute window. Emails beyond the limit are rejected until the window resets.
Per Day Limit
Set the maximum emails accepted within a 24-hour period. Useful for confirming your app respects daily sending thresholds before going live with a real provider.
Note: Rate limiting works alongside allowed and blocked rules. An email from an allowed sender is still rejected once the rate limit has been reached — whichever threshold hits first.
What to test with rate limiting:
Does your app handle gateway throttling gracefully — or does it fail loudly?
Does it queue emails and retry when the limit resets?
Does your monitoring detect when email volume exceeds expected thresholds?
What to test with rate limiting:
Does your app handle gateway throttling gracefully — or does it fail loudly?
Does it queue emails and retry when the limit resets?
Does your monitoring detect when email volume exceeds expected thresholds?
When firewall rules actually help
Three services are sending emails to your staging inbox. You only need to see one.
Set an allowed domain for the service you're testing. Every other sender is rejected at the gateway. Your inbox shows exactly what you need — nothing else. No scrolling through noise from other services running in parallel.
Your app needs to handle carrier rejection
Real email carriers reject messages from unauthorised or unknown senders. Block a sender domain in Sandbox and trigger your flow. Your app receives a genuine 550 SMTP rejection and must handle it — so you can confirm your error handling, alerting, and retry logic works before production does it for real.
A developer ships a new notification feature. It sends 200 emails in a batch.
Set a low per-hour limit and trigger the batch. Does the app detect the throttle? Does it queue and retry, or does it silently fail? Rate limiting in Sandbox answers this before a real provider enforces it in production.
You're running a long QA sprint with multiple developers
Five developers are running different test flows simultaneously. Emails from every service are landing in the same inbox. Set allowed addresses for the specific flow each developer is responsible for — each tester sees only what's relevant to their current test run.
The things developers ask about Email Inbox Firewall
What does my sending app receive when an email is blocked?
A real SMTP rejection response — the same kind a real carrier would return. Your app receives and must handle a genuine error, not a silent drop.
If I don't set any rules, does Sandbox block anything?
No. Without any rules configured, all incoming emails are accepted regardless of sender. Rules only apply once you create them.
Can I have both allowed and blocked rules active at the same time?
Yes. Blocked rules always take priority. If a sender matches both an allowed domain and a blocked address — the block wins.
Does rate limiting apply to allowed senders?
Yes. Rate limiting applies to all incoming emails regardless of allowed or blocked rules. An email from an allowed sender is still rejected once the rate limit has been reached.
Can different inboxes have different firewall rules?
Yes. Rules are configured per inbox. Your dev, staging, and QA inboxes can each have completely different configurations — independent of each other.
A focused inbox makes for better testing.
Configure allowed senders, block unwanted domains, and set rate limits on any inbox. Active immediately. No rules needed to get started — Sandbox accepts all emails by default.
Allowed and blocked rules per inbox
Rate limiting per hour or per day
Real SMTP rejection responses to your app
Free forever on basic plan
Sandbox
Test Email, SMS, Webhooks & 2FA codes without touching production.
Operational
Contact Us On
Mail Us
support@zunoy.comCopyright © 2026 - Mentcube Innovations Pvt Ltd.. All Rights Reserved.