Why Your App's Emails Land in Spam: Transactional Email and Deliverability Explained

A customer asks for a password reset and nothing arrives. An invoice goes out and the client finds it in the junk folder two weeks later. Problems like these rarely show up in testing, because the email was sent correctly as far as your application can tell. What failed is deliverability: whether the receiving mailbox provider trusted the message enough to put it in the inbox.

Email delivery is part of the architecture of any web or mobile application, not a detail to settle the week before launch. This guide explains, in plain language, why application email ends up in spam and what your developers should set up to prevent it.

Transactional vs marketing email

Transactional email is triggered by something one user did or needs to know: a password reset, a sign-in code, an order confirmation, a receipt, a shipping update. It goes to one person, it is expected, and it is often urgent. Marketing email is sent to a list on your schedule: newsletters, promotions, product announcements.

The distinction matters because the two behave differently. People open a password reset within seconds and almost never report it as spam. Promotional mail is opened less and reported more. Mailbox providers watch those reactions and use them to judge the sender, so the two types of mail earn very different reputations.

Why sending from your own web server is a bad idea

Most frameworks can send email straight from the server that runs the application, and it works on a developer's machine. In production it tends to fail quietly. Receiving providers judge mail partly by the reputation of the IP address and domain it comes from, and a newly rented server has no sending history. Many hosting providers also restrict outbound mail from their servers to limit abuse.

There is a practical problem as well. A plain web server sends the message and forgets it. It does not retry sensibly when the receiving server is busy, does not record which addresses bounced, and does not tell you when a recipient clicks "report spam". You end up with no data at exactly the moment you need it.

What an email sending service does

An email sending service (sometimes called an email API or SMTP relay) is a specialist provider your application hands messages to over an API or SMTP connection. The service maintains the sending infrastructure and its relationships with mailbox providers, queues and retries messages, signs them with your domain, and reports back what happened to each one: delivered, bounced, or marked as spam.

Most services offer a choice between shared IP addresses, used by many customers, and dedicated ones. Shared is the usual starting point for low volumes, but it has a trade-off that Google's guidelines spell out: the activity of every sender on a shared IP affects the reputation of all of them. A good service does not rescue bad sending habits.

SPF, DKIM and DMARC in plain language

These three standards let a receiving mail server check that a message claiming to come from your domain really does. All three are set up as DNS records on your domain.

SPF is a published list of the servers allowed to send mail for your domain. DKIM adds a cryptographic signature to each message; the receiver looks up a public key in your DNS to confirm that the message was signed by your domain and was not altered on the way. DMARC ties the two together. It checks that the domain your recipient sees in the From line matches the domain that passed SPF or DKIM (this is called alignment), and it publishes your instruction for mail that fails: do nothing (p=none), treat it as suspicious (p=quarantine), or reject it (p=reject). DMARC can also send you reports showing who is sending mail in your name.

Authentication proves identity, not quality. A fully authenticated domain that sends unwanted mail still goes to spam. Without authentication, though, even wanted mail struggles.

What Google, Yahoo and Microsoft require

The large mailbox providers now publish their rules. As of October 2026, Google's email sender guidelines require every sender to personal Gmail accounts to authenticate with SPF or DKIM, have valid forward and reverse DNS records, and send over TLS. Senders of more than 5,000 messages a day to Gmail accounts must set up SPF, DKIM and DMARC (a policy of none is accepted), align the From domain with the SPF or DKIM domain, and support one-click unsubscribe on marketing and subscribed messages. Google asks senders to keep the spam rate shown in Postmaster Tools below 0.1% and never reach 0.3%.

Two details in Google's sender guidelines FAQ are worth knowing. Transactional messages are excluded from the one-click unsubscribe requirement, and bulk sender status does not expire once a domain has reached it. The FAQ also says Gmail has been ramping up enforcement since November 2025, with non-compliant mail facing temporary and permanent rejections.

Yahoo's sender best practices set out very similar requirements, including a spam rate below 0.3% and honoring unsubscribes within two days. Yahoo's sender FAQ says it will not specify a volume threshold for what counts as bulk. Microsoft's Outlook.com postmaster policies require SPF, DKIM and DMARC from domains sending more than 5,000 emails a day to Outlook.com accounts; mail that falls short goes to the junk folder and may later be rejected.

These pages change, so have your developers read the current versions. A small sender is wise to meet the bulk standard anyway: it costs little and avoids a rush when volumes grow.

Separate your transactional and marketing streams

If a promotion draws spam complaints, you do not want your password resets to pay for it. Google's guidelines advise against mixing content types in one message, recommend a consistent From address for each category of mail, and suggest a different IP address for each message type when more than one IP is used.

In practice this usually means sending from separate subdomains, for example one for account and order mail and another for newsletters, each with its own authentication records and often its own stream or account at the sending service. The extra setup is small and it contains the damage when one stream has a bad week.

Bounces, complaints and monitoring

A hard bounce means the address does not exist or refuses mail permanently; a soft bounce is a temporary failure such as a full mailbox. A complaint is a recipient pressing the spam button. Your application should receive these events from the sending service, usually through webhooks, and act on them: stop sending to hard-bounced addresses and to anyone who complained.

For monitoring, Google Postmaster Tools shows spam rate, reputation, authentication results and delivery errors for mail sent to personal Gmail accounts once you verify your domain. Combine it with your sending service's dashboard and your DMARC reports, and make one named person responsible for looking at them.

Common mistakes

The same handful of errors sit behind many deliverability problems:

• Authentication set up for the main website domain but not for the domain the application actually sends from, so DMARC alignment fails.
• Several tools (CRM, help desk, billing system, the app itself) all sending as the same domain, with some never added to SPF or DKIM.
• Promotional content added to receipts and notifications, which blurs the line between the two streams.
• Bought or old lists loaded into the same account that sends transactional mail.
• Bounce and complaint events never connected, so nobody notices delivery degrading.

What to do next: a checklist for your developers

Hand this list to whoever maintains your application and ask for a yes or no on each line. Email sits alongside the other items in a web application security checklist, since the same records that protect deliverability also make your domain harder to spoof.

• All application email goes through a dedicated sending service, not the web server.
• SPF, DKIM and DMARC are published and passing for every sending domain, with the From domain aligned.
• Transactional and marketing mail use separate subdomains or streams.
• Marketing mail carries a one-click unsubscribe header and a visible unsubscribe link, and requests are honored promptly.
• Bounces and complaints flow back into the application and suppress future sends.
• Postmaster Tools and DMARC reports are set up, and someone reviews them on a schedule.

Conclusion

Email lands in spam when the receiving provider cannot verify who sent it or has reason to doubt the sender. The fix is rarely one setting. It is a combination of a proper sending service, correct SPF, DKIM and DMARC records, separate streams for transactional and marketing mail, and a habit of acting on bounces and complaints.

None of this is expensive compared with the cost of customers who never receive a reset link or an invoice. If you are planning a new application or suspect that an existing one has delivery problems, you can contact Entrant Technologies to talk through how email should be set up.