Password resets, login codes, receipts, and alerts are easier to operate when application email has its own delivery path. Here are the setup decisions that matter before sending. Verify the sending domain Use a domain you control, then add the DNS records shown by zaSend: SPF authorizes the delivery service. DKIM signs each message so recipients can verify it. DMARC tells receiving systems how to handle authentication results. Wait for DNS to update, then run the domain check again. A domain is ready when all required records match the values generated for it. Choose API or SMTP The API fits an application that already makes HTTPS requests. A request needs the sender, recipient, subject, and HTML or text body. Keep the API key on your server; never put it in browser code. SMTP is useful when the application or framework already supports SMTP. Use the host and port shown in your domain's SMTP settings, authenticate with a domain sending key, and enable TLS. Send a real application message Start with one message type, such as a password reset. Give it a clear subject, a plain-text alternative, and an expiring link. Record the provider message ID so delivery events can be connected to the user action that created the message. Handle delivery events Use webhooks to track accepted, delivered, bounced, and complained messages. Temporary delivery failures may be retried; permanent bounces should be removed from future sends. Keep sending safe Store keys in environment variables or a secrets manager. Use a separate key for each application where possible, rotate keys when access changes, and begin with a small sending volume. Check delivery logs before increasing volume. For more detail, see the zaSend API documentation and SMTP relay guide.