SendGrid in your app: authenticated sending, then what the delivery events tell you

Accepted by SendGrid is not delivered

A successful call to SendGrid's mail send endpoint returns a 202 status, which the documentation describes only as accepted. Whether the receiving server took the message is reported later, by events. An app that treats the 202 as delivery has no way to learn that an address bounced, that a message was dropped because the address was already on a suppression list, or that the receiving server is deferring mail.

• Accepted: your request was valid and SendGrid took it.
• Processed, deferred, delivered, bounce, blocked, dropped: later events, in no promised order.
• Opens and clicks are engagement events, not delivery.

What domain authentication does and does not prove

Domain authentication publishes DNS records so receivers can check that SendGrid is allowed to send as your domain. With automated security on, SendGrid asks for CNAME records and manages the underlying keys. It applies the authentication when the From domain matches the authenticated domain, and a subdomain does not inherit a parent domain's authentication. Passing these checks lets a receiver trust where the message came from; it does not decide whether the receiver files the message in the inbox.

• Check a real received message's headers rather than only the dashboard status.
• Records can take up to 48 hours to verify, so a first test may fail for timing alone.
• An existing DMARC record on the domain needs reading before anything is added.

What your app has to build

SendGrid supplies the feed; your app decides what to do with it. A useful connection stores bounce, blocked and dropped events once each, keyed by the event ID, skips addresses that failed permanently, and verifies the signature on the feed so a forged request cannot flag real customers. Those pieces are code in your application, and each can be tested with deliberate bad recipients on a staging copy.

• Use a restricted API key that can only send mail, and keep it in your secret store.
• Keep staging and production keys separate.
• Never test bounce handling on real customers' addresses.

Which paid step fits

One app, up to three message types and one sending domain is the single outcome priced from a fixed £395 test price, paid after the agreed checks pass and you sign off. Several channels at once belong in the notification project, and a monthly review of delivery records is the standing service. Each is an untested price. Marketing mail, inbox-placement promises and domain-wide authentication for other senders are outside the single connection. Send the stack and the sending domain name first; never keys or customer addresses.