Deliverability basics.

Start with DNS

Complete domain setup. Publish one valid SPF record, the domain’s DKIM public key, and a DMARC policy appropriate to your rollout. Use the console’s checks and inspect authentication results in a live message.

Keep the From domain consistent with the identity recipients expect. Verification proves control; it does not guarantee that every receiving server will trust a message.

Send mail people expect

Send only to recipients who expect the message. Validate addresses at collection, confirm signups where appropriate, and remove stale or repeatedly failing recipients. Do not buy lists or keep retrying an address that has hard-bounced.

Make the sender and subject recognizable. Include a usable Reply-To address when the From address is not monitored. Provide a plain-text body alongside HTML.

Read bounces, not just counts

Use message details to distinguish temporary deferral from permanent bounce. Read the event’s detail before deciding what to do.

A recipient hard bounce can automatically suppress that address. Policy or authentication failures usually require fixing the sender or message, not deleting the recipient. The API does not yet ingest asynchronous DSN bounce messages that arrive after delivery.

Respect suppressions

Treat the suppression list as a safety mechanism. Reactivate only after correcting the address or confirming the original failure no longer applies. Suppressions are organization-wide and persist after the original message expires.

Increase volume deliberately

Start with expected transactional traffic, monitor deferrals and bounces, and spread work instead of exhausting the daily cap in one burst. The rate limit and allowance are ceilings, not a recommendation to send at the maximum.

Delivered means a receiving server accepted the message. It does not mean it reached the inbox, was opened, or was read.