Start with the right model: an entry point, not a mailbox
A forwarding alias looks like a complete email address, but its core function is to receive messages and forward them to your real inbox. Reading and long-term storage usually still happen in the real inbox.
This model explains many of its limits: pausing an alias blocks new messages but doesn’t delete copies already received in your real inbox; deleting an alias also won’t remove account details from other systems.
Limit 1: Successful forwarding isn’t permanent delivery
Email passes through several stages: the sender, domain reception, forwarding, and the destination inbox. Quota limits, spam filters, or temporary outages at the destination can affect final delivery.
The 30-day archive helps you review recent messages and retry failed deliveries, but it isn’t a permanent mail archive. Keep important content in your real inbox or a dedicated archival system.
Limit 2: Pausing affects future messages only
Pausing is useful for stopping the flow when a subscription suddenly becomes noisy. Messages sent to the alias afterward won’t be forwarded, and pausing won’t reveal your real address to the sender.
Pausing doesn’t send an unsubscribe request to the original website or change the information in its database. To end a contract or marketing consent, complete the cancellation process on the relevant site.
Limit 3: Replies may reveal your real address
SendTmp aliases are designed to receive and forward mail; they don’t provide the full ability to send outward as the alias. If you reply directly from your real inbox, the recipient may see your real sending address.
For ongoing two-way communication where identity separation is essential, use a dedicated email solution that supports sending as an alias. Don’t reply to sensitive conversations until you’ve confirmed how the sender address will appear.
Limit 4: A 30-day archive isn’t a backup
The archive is for viewing recent message content, downloading attachments, checking status, and retrying failed mail. After the window ends—or after you delete a message—don’t treat the record as recoverable.
Contracts, invoices, recruiting correspondence, and project decisions may have their own retention requirements. Move them to a long-term system instead of waiting until the archive is about to expire.
Each source gets its own master switch. If an address is exposed or becomes noisy, turn off that one entry point without changing your real email address.
Make prefixes easy to track—but don’t reveal private details
Choose a purpose-based prefix that doesn’t include your name, birthday, or order number—for example, a short project code. When mail arrives at the alias, you’ll know who first received the address.
The prefix must start with a letter, be 3–30 characters long, and avoid system-reserved words. If you leave it blank, SendTmp generates a random value that follows the rules.
Your real inbox remains the security root
Code-based login proves that you can access the destination inbox. If your real inbox is compromised, your alias dashboard may be affected too. Use a strong password and your inbox provider’s own multi-factor authentication.
The dashboard’s TOTP two-step verification adds extra protection. Store the QR code and secret key in a trusted authenticator—don’t share screenshots or send them by email.
When aliases are the best fit
Long-term subscriptions, job applications, housing inquiries, project registrations, and trials that need follow-up notifications all work well with separate aliases. They need ongoing inbound mail but may need to be shut down quickly one day.
Financial, government, and primary identity accounts are still better served by a well-protected real inbox. An alias can reduce exposure, but it shouldn’t be used to bypass an organization’s security rules.
Do a quick monthly cleanup
Review forwarding volume to spot sources that suddenly increase; pause completed projects and delete aliases you’re sure you no longer need. Before cleaning up, confirm that no associated account still relies on the address for recovery.
Check failed statuses in the archive: first confirm that the destination inbox is available, then consider a retry. Mark clearly malicious messages as spam instead of repeatedly delivering them.