Friday evening, an hour before release. The product manager posts in Slack. "I'm not getting the password reset email." A developer tries with their own address and the email arrives. Someone from QA tries, and it arrives for them too. The cause only turns up later. Everyone has been using the same two or three addresses for months, so the system treats them as "already verified" and the new-user flow never fires. Nobody had actually tested as a brand-new user.
This happens on a lot of software teams. The most honest way to test email-based flows like sign-up, activation and password reset is to start every run with a clean address the system has never seen. That is exactly where a temporary email helps. We will also be upfront about where it doesn't help, because a developer who shows up with the wrong expectations gets frustrated within ten minutes.
What does a temporary email make easier in manual testing?
Sign-up and activation
You want to walk through the new-user scenario end to end. You fill in the form, the verification email goes out, you click the link, the account becomes active. Just open the Geçici Mail home page. An address is created automatically; grab it with the COPY button and paste it into the sign-up form. The inbox refreshes itself every 5 seconds, and in our own tests an email typically shows up within 3 to 5 seconds. If you don't want to wait, the REFRESH button updates the inbox right away.
What you should be checking goes well beyond whether the email arrived:
- Does the verification link point to the right environment? A staging email that links to production is a classic bug.
- Is the link single-use? Does a second click show a sensible message?
- What happens with an expired token? Leave the link for a while, then try it.
- What do the subject line and sender name tell the user when they glance at their inbox?
Password reset
The case people miss most often in password reset flows is whether old links are invalidated when several reset requests are sent to the same address in a row. Send three requests to a temporary address, wait for three emails, then click the link in the first one. If that old link still works, you may be looking at a security hole. Running this test in your personal inbox clutters it and mixes the results up with old mail.
How your HTML template really looks
Previewing a template in the browser is not the same as seeing it in an inbox. Geçici Mail displays HTML emails safely. Scripts are stripped out and the message opens in an isolated frame, separate from the rest of the page. If any part of your template depends on scripts, you'll spot it straight away. Most email clients don't run scripts either, so if your template looks broken here, there's a good chance it will cause problems elsewhere too.
To be clear, a single inbox won't reveal every difference between email clients. Desktop clients, mobile apps and dark mode all have their own quirks. A temporary email gives you a "first real look", not a full client compatibility test.
Multi-user scenarios
Invitations, team membership, message notifications between two users... Testing these takes more than one address. Each browser profile or private window can hold a separate address. For example, keep the "admin" address open in one window and the "invited user" in another, and check that the invitation goes to the right person with the right role. The DELETE button drops the current address and gives you a new one (it asks for confirmation first), which is handy for starting fresh once you're done with a user.
Limits for testing teams
Developers tend to ask the same thing first. "Do you have an API?" We don't. That's a deliberate choice rather than a missing feature. Automation is the easiest way to abuse a free, no-signup service, so the site is protected against automated bot use. If you try to hook your test script up to the site, it will get blocked, and that's the expected behaviour.
Other limits:
- Attachments aren't shown. If you're testing a flow that sends an invoice PDF, a ticket or a certificate as an attachment, you can't confirm the attachment here.
- You can't send email. Flows that rely on "reply to this email", meaning systems that process incoming replies, can't be tested.
- You can't choose the address. Addresses are random. If you need one that matches a specific pattern, this isn't the right tool.
- Emails don't stick around. Incoming emails are deleted automatically after 24 hours. If you need to keep evidence of a bug, take a screenshot.
- Some services reject temporary domains. If the app you're testing has a filter like that, remember it's your own rule at work, not a bug.
Manual or automated, which tool goes where?
Roughly speaking, a temporary email is for tests a human looks at. A pipeline that runs on every commit needs different tools.
| Need | Suitable tool | Why |
|---|---|---|
| Walking through the new-user flow by hand | Temporary email | Clean address, no setup, ready in seconds |
| How the template looks in a real inbox | Temporary email | Scripts stripped, isolated view; a quick first check |
| Automated email verification in CI/CD | Local SMTP capture tool | Mail never leaves your environment and can be read from test code |
| Checking emails with attachments | Local SMTP capture tool or your own test inbox | Attachments aren't shown in the temporary inbox |
| Deliverability and spam score | Your email provider's tools | Measuring sending-domain setup is a separate job |
Local SMTP capture tools collect the emails your application sends on a fake server, without letting them out to the real internet, and give you a web interface or a readable endpoint. There are plenty of open-source options you can spin up with Docker in a few minutes in a development environment. In automated tests, reading the email, extracting the link and clicking it should be done with a tool like that. It's faster, and it doesn't depend on an outside service.
The practical test flow we recommend
- Before you start, open a new private window and go to gecicimail.com.tr. An address is created automatically.
- Note the address and the recovery key in your test record or on the ticket in your issue tracker.
- Fill in the sign-up form with this address and roughly note how long the email takes to arrive.
- Open the email and check the subject, sender name, the environment the link points to, and how it looks at mobile width.
- Click the link, then click the same link again. Write down what happens.
- Trigger a password reset several times in a row and try the old links.
- Take the screenshots you need; the emails will be deleted after 24 hours.
- Use DELETE to get a new address for the next scenario.
If the email never shows up, the problem isn't always in your code. We've collected the other possibilities, such as the sending queue, domain filters or the wrong environment config, in our article on why emails aren't reaching your temporary inbox.
Don't test with real user data
One last note, and maybe the most important. Copying real user addresses from production into a test environment is the quickest way to accidentally send test emails to real people one day. If those people are in the EU or UK, GDPR makes it a data protection issue as well. Using a temporary address for manual tests and a local capture tool for automated ones removes that risk from the start.
FAQ
Does Geçici Mail have an API?
No, Geçici Mail doesn't offer an API. The site is built for manual use in a browser and includes protection against automated bot use.
Can I use a temporary email in automated tests (CI)?
We don't recommend it, because automation gets blocked. For automated tests, an SMTP testing tool that captures your application's emails locally is faster and more reliable.
Will testing my HTML email template in a temporary inbox give accurate results?
It gives you a good first idea of how the template looks in a real inbox, since scripts are removed and the email opens in an isolated frame. It won't show every difference between email clients, though.
Can I see emails with attachments?
No, attachments aren't shown. Check flows that include attachments in your own test inbox or in a local SMTP capture tool.
Can I come back to the same test address the next day?
Yes. If you saved the recovery key, use Recover Email to get back to the address. Incoming emails are deleted after 24 hours, though, so older messages may be gone.