Standing service notify-keep-transactional-messages-delivering · revised 11 October 2026
Standing service
Keep your app's emails and texts reaching people, with failures found early, every month
Each month we read your app's delivery records for email and SMS, flag addresses and numbers that keep failing, check sender records still match, and send a short delivery summary.
This starts a conversation by email. Nothing is charged, and nothing is reviewed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Message delivery decays quietly: addresses go stale and keep bouncing, the callback that records delivery stops arriving after a deployment, a new sending service is added without authentication, and a number that cannot receive texts is retried for months. Each shows in a record that nobody reads. The fault is that no one reviews the delivery trail on a schedule.
Who it’s for: A founder or product owner whose app sends receipts, resets or reminders through an email or SMS provider, and who has no routine way to learn that a share of them is bouncing, being blocked or not recorded.
Usually starts when: Customers keep saying a message never came, the delivery log stopped filling weeks ago without anyone noticing, or a sending service was added to the domain and nobody checked how it authenticates.
The result: The email and SMS senders you name keep a live delivery trail in your app. Each month you see how many messages ended delivered, bounced, blocked or failed, which addresses and numbers keep failing, whether the delivery records are still arriving, and whether the sending domain's public records still match the services in use.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can actually keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- Delivery records from the named providers keep arriving in your data, in proportion to what is sent
- Addresses and numbers that fail repeatedly are listed for you each month
- The sending domain's public records are checked against the services you say send as it
- A test message per channel, triggered by you, reaches a mailbox and phone you own each month, and the result you share is recorded
What we watch
- The read-only monthly export of your delivery table
- Public DNS records for the sending domain
- The headers and delivery records of the monthly test messages that you send and share
- Your application logs with personal data removed
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| Messages were sent but few or no delivery records arrived in the export period. | We investigate the recording path, fix what sits in your code in a pull request, or tell you what outside the code changed, such as a callback address or a signing key. |
| An address or number fails repeatedly across the period. | We list it with the reason the provider reported and a recommendation, such as suppressing it or asking the customer for another. You decide. |
| A public lookup shows a sending service not on your list, or a service on your list with no matching records. | We tell you which records differ and what to ask your DNS holder; we do not change DNS. |
| The monthly test message you trigger does not arrive, or the headers you share show authentication not passing. | We show you the headers or status history and the likely cause, and fix what sits in your code. |
| A month ends. | We send a short written summary: outcomes by type, failing addresses and numbers, records checked and what is open. |
We do on our own
- Read the exports you share and run public DNS lookups
- Read the received headers and delivery record of the monthly test messages that you trigger and share
- Open pull requests on a branch or fork that change delivery-recording code and tests
We ask you first
- Changing DNS, provider settings or credentials, which stay with you
- Suppressing, deleting or messaging any customer
- Merging, or any change to your default branch
We escalate to you when
- A provider suspends or restricts the account
- Failure rates rise sharply in a way that could indicate a compromised sender, in which case we tell you straight away
- Fixes pass the agreed monthly number
How you know it held. Each month you get the outcome counts, the failing list, the arrival check, the DNS comparison and the test message result, and you can compare the counts with your provider's own dashboard.
How we keep it true
This service is never finished. Each month's summary shows what was checked and what is open, and it continues until you end it.
Send your app's emails through SendGrid on your own domain, with bounces recorded Job Optional
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.
If email delivery records do not yet exist, this build adds them and can be bought on its own.
Send one kind of SMS notification from your app through Twilio and track its delivery Job Optional
One agreed app event sends one SMS through your Twilio account, and the app stores each message's delivery status from signed callbacks, even when they arrive out of order.
If SMS delivery records do not yet exist, this build adds them and can be bought on its own.
What is included, and what is not
- A written monthly delivery summary
- A list of the pseudonymous references of repeatedly failing addresses and numbers for you to review, which you map back to the real ones
- A pull request for each problem in your delivery-recording code that we can fix, up to the agreed number a month
- Instructions for anything that only you can change, such as DNS records or provider settings
Included
- Up to two message channels from one app, such as email through one provider and SMS through one provider, each with its delivery events already recorded in your data
- A monthly count of final outcomes by message type, from a read-only export of your own delivery table that you share
- A monthly list of the pseudonymous references (as they appear in the export) of addresses and numbers that failed repeatedly, with a recommendation for each that you decide on; you map the references back to real addresses and numbers using your own data
- A monthly check that delivery records arrived recently relative to messages sent, to catch a callback that has stopped
- A monthly public DNS lookup for the sending domain, compared with the list of sending services you give us, and a monthly test message per channel that a person on your side triggers and shares the result of (below)
- The monthly test message: a person on your side runs an agreed admin action or script in your app that sends one message per channel to a mailbox and phone you own, then sends us the received message's full headers and the delivery record for that message. We never hold credentials or send from your production system. If no such action exists, the first pull request adds a small one for you to review, and it counts as one of that month's fixes
Not included
- Any promise of inbox placement, sender reputation or delivery rates
- Marketing or bulk campaigns, list building and consent management
- Changing DNS, provider accounts, credentials or production, or sending messages from your system ourselves
- Watching domain expiry, certificates or DNS drift in general: that is the domain-keeping service ("Keep your domain, DNS and mail records from silently breaking, month after month"). This service only compares the sender records against the list of sending services you give us
- Building the delivery-recording code if it does not yet exist: that is a separate outcome
- Legal advice on messaging or privacy rules
- Out-of-hours cover or any guaranteed response time
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
In the first month, the counts of final outcomes in our summary match the provider dashboard counts for the same period within the difference you can explain, and we list any gap.
Evidence: The summary table next to your provider dashboard figures.
Each month's summary lists the pseudonymous reference of every address and number that failed repeatedly, the arrival check result, the DNS comparison and, for each channel, the result of the test message you triggered, read from the headers and delivery record you shared.
Evidence: The written monthly summary, which you can compare with your own records and with the headers you sent.
For each problem in your recording code that we fix, a replayed provider callback is stored once and a callback with a wrong signature changes nothing.
Evidence: Test output on the pull request branch and the diff.
Sign-off. You read each monthly summary and review and merge each pull request. A fix counts as delivered when you accept it.
If it fails. If we cannot fix a problem we say so, explain what we found and what it would take, and it does not count against the monthly number. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- Your app already records delivery events from the providers, or you have bought the build that adds them
- You can share a monthly read-only export of the delivery table with personal data pseudonymised or removed
- A test mailbox and a test phone you own are available each month, and a person on your side can run the test-message action and send us the result
- A person on your side reviews and merges pull requests and decides what to do about failing addresses
We stop and tell you if
- The app records no delivery events and no build is planned, so there is nothing to review
- The export cannot be shared without exposing customer data we should not hold
- Most issues are in provider accounts or DNS that you cannot or will not change
- Failures regularly exceed the agreed monthly number
What could go wrong
Every code change is a pull request that your team merges, so any one can be reverted like any other change. Ending the service leaves the code as it is, with open pull requests finished or handed back and no change made to your accounts or DNS.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The monthly export exposes recipients' personal data. | Identifiers are pseudonymised before sharing, message contents are never included, and the export is deleted after the review. |
| A count is read as a promise about inbox placement. | Summaries report what providers recorded and say plainly that they cannot show inbox placement. |
| A failing address is suppressed wrongly. | We only recommend; you decide, and nothing is deleted. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You run the monthly test-message action and share its result
- You change DNS, provider settings and credentials
- You decide what to do about failing recipients
Access we would need
- Read access to the code and a branch or fork for pull requests
- A read-only monthly export with identifiers pseudonymised
- The received headers and delivery record of a test message that you trigger to a mailbox and phone you own
Questions
Will this improve my delivery rate?
No promise is made. It makes failures visible early and fixes the recording code, but where a provider files a message is outside our control.
Do you need access to our email or SMS provider?
No. We work from exports you share, public records and the results of test messages you send. You keep every account and credential, and we never send from your system.
Who sends the monthly test message?
A person on your side, using an agreed admin action or script in your app. They send us the received headers and the delivery record, and we read them.
What if the app does not record delivery events?
Then there is nothing to review yet. The one-off builds that add email and SMS delivery records can be bought first.
How is this different from the integration-health service?
That one watches credentials, quotas and provider deprecations across integrations. This one watches what happened to the messages.
Does this watch my domain's DNS and renewals?
Only as far as comparing the sender records with your list of sending services. Records that drift, expiry dates and certificates are the domain-keeping service: "Keep your domain, DNS and mail records from silently breaking, month after month".
Also part of
Send an enquiry
Send us
- The channels and providers in use, and roughly how many messages a month are sent
- Whether the app records delivery events today, as a yes or no
- The sending domain, as text only, and the services that send as it
- Do not send API keys, customer lists, message contents or code in the first enquiry
Later, once you agree
- Read access to the code through a company-controlled repository, with a branch or fork for pull requests
- A monthly read-only export of the delivery table, with identifiers pseudonymised
- The list of services that send as your domain, a test mailbox and phone number you own, and the admin action or script that sends the monthly test message
- The agreed number of fixes a month and the person to tell about failing addresses
You own the accounts, domain, credentials and every message recipient. We read what you share, run public DNS lookups, change files only on a branch or fork through pull requests you review, and never hold production secrets.
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 “notify-keep-transactional-messages-delivering” as the subject.