The same goes for domain names; do NOT use a public domain name you do not control in your configuration, documentation, or UI language.
Instead, use one of the available reserved domain names documented in RFC 2606, such as 'example.com', 'example.net', or the .example top-level domain.
โ test.com
โ yourdomain.com
โ
example.com
โ
yourdomain.example
Pass it on to your fellow developers, designers, documentation writers, and so forth.
Full RFC text is here;
https://datatracker.ietf.org/doc/rfc2606/
2/ ๐งต
Oh, and please, if you are sending email, don't make up random addresses for your app to test with. Only send mail to addresses you know are valid, and for which you have permission to send mail.
If you need to test SMTP while developing software, use a mock SMTP server that drops all outgoing email in a local directory, so you can inspect it without dumping a metric ton of email in your upstream's SMTP queue.
If you absolutely must generate unique email addresses for testing, either register a domain for that purpose and set up mail handling for it, or use the .test TLD, and have as many unique domain names as you like.
3/ END
Oh, and please, if you are sending email, don't make up random addresses for your app to test with. Only send mail to addresses you know are valid, and for which you have permission to send mail.
If you need to test SMTP while developing software, use a mock SMTP server that drops all outgoing email in a local directory, so you can inspect it without dumping a metric ton of email in your upstream's SMTP queue.