To send SMS and email notifications reliably, use a dedicated sending provider for each channel, authenticate your sending domain with SPF, DKIM, and DMARC, keep transactional messages separate from marketing, record consent and honor every opt out, send from a queue with retries, and fall back to a second channel when a message matters.
A notification that does not arrive is worse than no notification, because someone was counting on it. We have built this plumbing at three different sizes.
On Vortech AC and Electrical, a quote form sends one email straight to the owner. On Regulars, shops send messages to loyalty members under a weekly frequency cap. On CoverageCobra, an attorney posting an urgent court appearance needs the right people told within minutes, by text, push, and email.
The size differs. The rules for getting a message delivered are the same.
How do you send notifications from an app reliably?
You send notifications reliably by handing delivery to a provider built for it, proving to mailbox providers that you are allowed to send from your domain, and treating every send as something that can fail. That means a queue, retries, a record of what was sent, and a second channel for anything urgent.
A web server can technically send email by itself. In practice, mail sent that way lands in spam or nowhere, because receiving systems trust established senders and distrust unknown ones. A sending provider brings reputation, delivery reports, and bounce handling. We use one for email and one for text messages, called through their APIs.
The working checklist:
- Use a provider per channel. One for email, one for SMS. Do not send from the web server directly.
- Authenticate the sending domain. Set up SPF, DKIM, and DMARC before the first real message.
- Split transactional from marketing. Different rules, and ideally different sending addresses or subdomains.
- Record consent. Store when and how each person agreed to each kind of message.
- Send from a queue. The user's action saves a job. A worker sends it and retries on failure.
- Listen for delivery results. Providers report bounces, failures, and complaints. Act on them.
- Cap frequency. Decide the most messages one person can receive in a period, and enforce it in code.
- Plan a fallback. If the message matters and one channel fails, try another.
What is the difference between transactional and marketing messages?
A transactional message is triggered by something the recipient did or needs to know about their own account: a receipt, a password reset, a booking confirmation. A marketing message promotes something. The distinction matters because consent rules, unsubscribe requirements, and delivery expectations differ between the two.
| Transactional | Marketing | |
|---|---|---|
| Triggered by | The recipient's own action or account | The sender's decision |
| Examples | Receipt, sign-in link, job accepted, form received | Promotion, newsletter, win-back offer |
| Expected speed | Immediate | Whenever scheduled |
| Consent | Generally expected as part of the service | Explicit opt in |
| Unsubscribe | Preferences, where practical | Always, in every message |
| If it lands in spam | The product looks broken | A campaign underperforms |
Keep the two apart technically as well. If a promotional campaign draws spam complaints, you do not want that to damage the reputation of the address that sends password resets. A common approach is to send each type from its own subdomain.
Do not dress marketing up as transactional. A "receipt" that is mostly an offer is a marketing message, and recipients and mailbox providers both notice. The rules on consent for texts and email vary by country and industry, so check the ones that apply to you.
What are SPF, DKIM, and DMARC?
SPF, DKIM, and DMARC are DNS records that prove an email claiming to be from your domain really is. SPF lists the servers allowed to send for you. DKIM adds a cryptographic signature to each message. DMARC tells receiving systems what to do when a message fails those checks.
You set them up once, as TXT and CNAME records in your domain's DNS, using values your sending provider gives you. If DNS records are unfamiliar, our guide to pointing a domain to a website explains the record types.
Three practical notes. First, large mailbox providers have been tightening their requirements, and unauthenticated mail is more likely to be rejected or sent to spam. Second, a domain should have only one SPF record, so when you add a second sending service, merge it into the existing record. Third, send from an address at your own domain that can receive replies. People reply to notifications, and those replies are often the most useful messages you get.
Text messages have their own version of this. Carriers and SMS providers generally require a business to register who it is and what it will send before messages go out at volume. Requirements differ by country and change over time, so follow your provider's current process and allow time for it before launch.
How should opt in and opt out work?
Opt in and opt out should be recorded per person and per message type, and checked by the code immediately before every send. An opt out has to take effect at once and has to be honored everywhere, including by scheduled campaigns created before the person opted out.
The data model is simple and worth doing properly from the start: who consented, to what, when, and through which screen. Then:
- Make opting out as easy as opting in. A reply keyword for texts and a one-click link for email.
- Check at send time, not at schedule time. A campaign queued on Monday must respect an opt out received on Tuesday.
- Offer choices, not just an off switch. Someone may want receipts and job alerts but no promotions.
- Treat a hard bounce or a complaint as an opt out. Stop sending to that address.
Frequency is part of consent. Regulars exists for shops whose main channel is a message on a customer's lock screen, and the campaign scheduler enforces a weekly cap because the fastest way to lose that channel is to overuse it. Every message has to be worth the interruption.
What should happen when a message fails to send?
When a message fails, the system should retry temporary failures automatically, stop sending to addresses that fail permanently, record the outcome, and, for anything important, try another channel or alert a person. A failed notification should never disappear silently.
Sending inside the user's request is the common mistake. If the provider is slow, the user waits. If it is down, the message is lost. Saving a job to a queue and sending from a worker fixes both.
For urgent messages, use more than one channel. On CoverageCobra we send text messages and browser push notifications as well as email, and let people choose, because email alone is too slow for a hearing the next morning. We explain the browser side in web push notifications explained.
The humble contact form deserves the same care. Vortech's quote form reaches the owner directly, which is only true if that one email arrives every time. A form that fails quietly loses customers without anyone knowing. Send a test through every form after launch, and wire send failures into error monitoring so someone hears about it.
Frequently asked questions
Can I send app emails from my regular business mailbox?
For a handful of messages it may work, but ordinary mailboxes are built for people, not programs, and usually limit automated sending. A dedicated sending provider gives you delivery reports, bounce handling, and a reputation that is separate from your day-to-day email.
Why do my app's emails go to spam?
The usual causes are missing or incorrect domain authentication, a new sending domain with no history, content that reads like promotion, and sending to old addresses that bounce. Fix authentication first, since it is the most common and the easiest to check.
Is SMS better than email for notifications?
SMS is better for short, urgent messages that need to be seen quickly. Email is better for detail, records, and anything the person may want to find later. Text costs more per message, so use it where urgency justifies it.
Do I need both SMS and email?
Not always. Many apps do well with email only, which is cheaper and simpler to run. Add text messages when a notification is time sensitive enough that a delay of an hour would cause a real problem.
If messages from your app or website are not arriving, or you are planning notifications for a new product, we can help. Get in touch.