Testing without hurting your reputation

usend has no built-in test addresses that simulate delivery, bounce and complaint. Every email you send to a real domain is real mail, so test carefully.

#Use mailboxes you own

• Create test mailboxes at the providers your users use (Gmail, Outlook, Yahoo, iCloud) and send to those. They tell you what the mail looks like and where it lands.
• Plus addresses ([email protected]) give you many unique addresses in one inbox, handy for sign-up tests.
• While your organization is in the sandbox, you can send only to verified members of your organization, so add your testers as members and verify their addresses.

#Do not send to made-up addresses

Sending to [email protected] or an address that does not exist produces a hard bounce. Hard bounces count against your rate: usend suspends an organization above 4% over a week, and mailbox providers watch it too. A few bounces from a small test are harmless; a test suite that hammers fake addresses is not. A hard bounce also suppresses the address, so later real mail to it is skipped. See Bounces and suppressions.

Do not use other people's addresses or domains you do not control (for example example.com gets no mail, but it will bounce).

#Testing bounce and event handling

• Send to a nonexistent mailbox on a domain you own to cause a real bounce, once, and check your webhook handler. Events are described in Event types.
• To test the handler without sending, post a saved event to your own endpoint. Signature verification still needs the signing secret: see Verify signatures.
• Use the Retries and replay features to resend a delivery to your endpoint: Retries and replay.

#Local development

Do not send real mail from development machines.

• Use SMTP into a local catcher such as Mailpit or MailHog when your app uses SMTP, and switch the host to smtp.usend.et only in staging and production.
• If you use the API, wrap it behind your own function and replace it with a fake in tests: End-to-end testing.

#Separate keys

Use a different sending_access key for staging and production, and a separate domain if you can, so a test mistake never touches production reputation. See Handling API keys.