Job sendgrid-transactional-email-aligned-sending-with-bounce-handling · revised 11 October 2026
Send your app's emails through SendGrid on your own domain, with bounces recorded
Up to three kinds of app email go out through your SendGrid account on your authenticated domain, and an address that bounces is recorded once and not mailed again.
You might be seeing
- Customers report missing password-reset or receipt emails and support can only ask them to check junk
- The app has no record of which messages were rejected, deferred or blocked
- A test message's full headers show no DKIM pass for your own domain, or a pass for a domain that does not match the From address
No passwords, keys, card details or admin invites needed to start.
What usually happened
The app hands mail to a sender that is not set up to prove the mail belongs to your domain, and nothing reads the provider's feedback. A hard-bounced address keeps being mailed, a block or drop is invisible, and a customer who never got a receipt has no trail anyone can follow. The fault is the missing provider connection and feedback loop, not a single broken form.
Who it’s for: A founder or product owner whose web app sends password resets, receipts or notices from a shared mailbox, a web-host mail function or a half-finished provider setup, and who has a SendGrid account or is ready to open one in the company's name.
Usually starts when: Customers say a reset link or receipt never arrived, or the app keeps mailing addresses that have already failed, and nobody can say which messages were rejected.
The result: Each agreed kind of app email (up to three) is sent through your SendGrid account from your authenticated domain, and a test message to Gmail and Outlook.com shows a DKIM pass on a domain that matches the From address. A deliberately bad recipient produces one stored bounce record, and the app skips that address on later sends.
Check whether this job fits
Answer from what you already know about your app and account. The result says whether this fixed job fits; it does not need keys, DNS logins or code.
Checks you can run yourself
Read the authentication results of one real message
Send yourself one message from the app to a mailbox you control and open the full original headers in your mail client. Do not forward the message or paste customer data.
Look for: Whether a DKIM result says pass, and which domain it names. A pass for a provider's own domain rather than yours means your domain is not authenticated for this sender.
What you get
- A pull request containing the send module, the event endpoint, the address flag and its tests
- The DNS record list for your DNS holder, and a dated copy of the public lookup after they added it
- Redacted full headers of one test message per type received at Gmail and Outlook.com
- A one-page note on what each stored event type means and what the app does for it, and how to undo the change
Included
- Up to three named transactional message types in one existing app (for example password reset, order receipt, account notice), sent one-to-one through SendGrid's mail send API using a restricted key that your account holder creates
- Domain authentication guided against SendGrid's instructions: we specify the DNS records, your DNS holder adds them, and we check the public result
- A signed Event Webhook endpoint in the app that records bounce, blocked, dropped and spam-report events once each, keyed by SendGrid's event ID
- An address-level flag in your own data so a hard-bounced or spam-reported address is skipped, with an admin way to clear it
- Tests for the send path, the event endpoint and the skip rule, run against staging with addresses you control
Not included
- Marketing or bulk campaigns, list management or newsletter templates
- Any promise of inbox placement or sender reputation, dedicated IP set-up or warm-up
- Fixing authentication for other senders on your domain: that is the domain-wide SPF, DKIM and DMARC job
- Changing an existing DMARC policy without your written approval
- Consent, unsubscribe-law or privacy-law advice for the messages you send
- Receiving inbound email, mailbox hosting or SMS
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Public DNS returns the records the provider specified for your sending domain, and your account holder's dashboard shows the domain as authenticated.
Evidence: Dated public lookup output for each record and a screenshot of the authenticated status taken by your account holder.
One staging test message of each agreed type received at a Gmail and an Outlook.com address you control shows DKIM pass for a domain that matches the From address.
Evidence: Redacted full headers of each received message with the authentication results visible.
A message to a deliberately non-existent recipient on a domain you control produces a stored bounce or blocked record, and replaying that same event payload twice leaves exactly one record.
Evidence: The stored row with SendGrid's event ID, the replay log and the database count before and after.
A request to the event endpoint with a wrong signature or an altered body is rejected, and a later send to the flagged address is skipped and logged.
Evidence: Test output for the rejected request showing no database change, and the skip log line for the flagged address.
Sign-off. You read the DNS lookup, the headers and the test output, then sign off in writing and merge. Payment follows sign-off; your own team deploys and holds the production keys.
If it fails. If the agreed checks do not pass you do not pay for this fixed scope. If the cause is the provider account, your DNS host or an excluded sender, we explain the evidence and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The messages are one-to-one transactional email, not a mailing to a list
- You control the sending domain's DNS, or can name the person who adds records and agree a time for it
- Your SendGrid account is active and a person on your side can create a restricted API key and place it in your own secret store
- The app can run a staging copy that sends only to test addresses you control and can receive HTTPS callbacks
- A person on your side reviews and merges the pull request and deploys it
We stop and tell you if
- The SendGrid account is suspended or flagged by the provider, which only you and the provider can resolve
- Your DNS host cannot publish the records SendGrid specifies and you cannot move DNS; we quote a different route
- The mail is really marketing to a list, which needs a different scope and different consent controls
- Nobody on your side can hold the API key or add DNS records, so the result cannot be checked
What could go wrong
Before merge, closing the pull request changes nothing. After you merge, reverting it restores the old send path; the DNS records can stay because they only authenticate the domain, and your DNS holder can remove them if you leave the provider. Stored event rows can be kept or dropped under your own retention rules.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A real customer address is mailed during testing or marked as bounced by mistake. | Testing uses addresses you control on staging. The address flag can be cleared by an admin and nothing is deleted. |
| The event endpoint accepts forged or altered events and flags real customers. | The endpoint verifies SendGrid's signature on the raw request body before reading it, and a test proves an altered body is rejected. |
| New DNS records clash with records already on the domain, such as an existing DMARC record. | We list the existing records you share before specifying changes, and we never change a DMARC policy without your written approval. |
A reviewer separate from the builder checks the diff, the event endpoint's signature handling and that no key or customer address is logged. Your authorised maintainer reviews and merges, and your account holder controls production keys.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the message types, sending domain, staging route and who adds DNS records and holds the keys
- Read the existing send path and list every place the app builds or sends the agreed messages
- Specify the DNS records for your DNS holder, then check the public result before testing sends
- Build the send module and the signed event endpoint on a branch, with the address flag and tests
- Send test messages of each type to your Gmail and Outlook.com mailboxes and capture the redacted headers
- Send a deliberately bad recipient on a domain you control and replay the event to prove one record
- Have an independent reviewer check the diff and evidence, then hand over the pull request with undo steps
An enquiry books nothing and charges nothing. Scope, access route and checks are agreed in writing first.
Need to keep it working?
If missed or bounced mail matters to your business, ask about the monthly service that reviews delivery events and flags addresses that keep failing.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Your own developer can follow the provider's domain authentication guide and read its Event Webhook reference to build the same connection. www.twilio.com
- If every sender on your domain is affected, a domain-wide authentication review fits better than a single app connection.
Questions
Will this make my emails reach the inbox?
No promise of placement is made. The job proves that your domain is authenticated, that bounces are recorded and that bad addresses are skipped; where a provider files a message is outside our control.
Do you need my SendGrid password or API key?
No. You create a restricted staging key and keep the production key. Keys are never part of the first enquiry.
What if my domain already has other senders and a DMARC record?
We read what is published and only add the records for this sender. We do not change an existing DMARC policy without your written approval.
Does this cover marketing emails?
No. It covers one-to-one messages sent because a person did something in your app.
Send an enquiry
Send us
- The app's language and framework, and how it sends mail today (SMTP relay, host function or another provider)
- The domain mail is sent from, written as text only, and who controls its DNS
- The names of the message types in scope, with no customer addresses or message bodies
- Whether a SendGrid account exists. Do not send API keys, DNS logins, customer data or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository or export, and a staging environment you control
- A restricted SendGrid API key limited to mail sending, created and held by you; staging and production keys stay separate
- The Event Webhook signing public key, copied from your account after you enable signed events
- Test mailboxes at Gmail and Outlook.com that you control, and an agreed time for your DNS holder to add records
You own the SendGrid account, the domain, the DNS and every key. We work on a branch through a company-controlled identity and use only a restricted staging key that you create. We do not hold production keys, log in to your DNS host or deploy for you.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “sendgrid-transactional-email-aligned-sending-with-bounce-handling” as the subject.