Before the first real send

Everything here has already caused somebody an incident. None of these takes more than minutes to check.

Test to addresses you control

Send the first messages to mailboxes of your own, at several providers: Gmail, Outlook, and a company mailbox with a filter of its own if you have one. All three behave differently, and that is what you want to see.

At each of them check:

• The message landed in the inbox and not in spam.
• The sender name is what you meant, rather than the bare address.
• The subject is not cut off or full of strange characters.
• The plain text version exists and makes sense on its own.
• The links point where they should, in production and not in development.

Look at the authentication in the message itself

In Gmail, open the message, press the three dots and choose Show original. What you want to see is this:

SPF:   PASS with IP 1.2.3.4
DKIM:  'PASS' with domain mail.mycompany.com
DMARC: 'PASS'

If DKIM names your domain and passes, you are done. If DMARC fails while DKIM passes, it is nearly always the From pointing at a different domain from the one that was signed.

Confirm that bounces come back

Send a message to an address that certainly does not exist, at your own domain, and watch the row in Messages turn to Bounced within minutes. If it stays Accepted forever, something is wrong on the bounce path, and you want to find that out with one message rather than with a whole list.

Treat 202 as accepted and not as delivered

It is the most common integration mistake. If you show a user "email sent" when you receive the 202, you are promising something that has not happened yet. Wait for the delivery event, or change the wording.

Keep the identifier

The id the API returns is what ties your database to the events, to the webhooks, and to what support needs in order to find a message. Keeping it costs one column.

Decide what a suppression means for you

A request for a suppressed address comes back with 422. The right answer is rarely to retry; it is to mark that contact on your side as not contactable, so you do not try again tomorrow.

Watch the environment

The number one cause of a campaign sent to real customers from a test environment is a database copied from production with the real addresses still in it. If you have a test environment, use a different API key and addresses of your own.

Raise the volume gradually

If you are about to send thousands of messages a day from a new domain, do not start there. A few thousand on the first day, doubling every couple of days, and watching the bounces between each step. A new domain with a sudden spike looks exactly like what a filter is waiting to block.