Transactional Emails from Your Web App

What counts as transactional

A transactional email is one the app sends because the user did something or something happened on their account: a sign-up confirmation, a password reset, a receipt, a booking confirmation, an invitation to a team. Google's Email sender guidelines FAQ gives "password reset messages, reservation confirmations, and form submission confirmations" as examples. A newsletter, a discount offer or a we miss you message is marketing, even when the app sends it.

The line is not always clear, and Google does not draw it for you. The same FAQ says the distinction "can vary depending on industry and applicable regulations" and that "Message recipients, not Google, determine the nature of the messages they receive." If users see a message as promotional and report it as spam, that counts against you. Google adds that high spam rates "negatively affect message delivery for any message type that you send", so a careless newsletter can push your password resets into spam too.

The mailbox rules apply to app email too

Gmail's Email sender guidelines apply to everyone sending to personal Gmail accounts since 1 February 2024, not only to newsletter senders. All senders need SPF or DKIM, valid forward and reverse DNS for the sending server, a TLS connection, messages formatted to RFC 5322 and a spam rate in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to Gmail accounts also need SPF, DKIM and DMARC with an aligned From domain. Yahoo's Sender Requirements & Recommendations set the same shape of rules. Our SPF, DKIM and DMARC guide explains the records themselves.

Enforcement is getting stricter. The Gmail FAQ says that "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic" and that messages which fail the requirements "will experience disruptions, including temporary and permanent rejections." For a web app, that means the mail must go out through a service your DNS records cover, not straight from an unconfigured web server, as our business email setup guide also says.

Keep transactional and marketing mail apart

Both Gmail and Yahoo ask you to separate mail by type. Gmail says: "Don't mix different types of content in the same message. For example, don't include promotions in sales receipt messages." It also asks that "Messages of the same category should have the same From: email address", with examples such as sales@ for receipts, deals@ for promotions and alert@ for account notifications. If you send from more than one IP address, Gmail suggests "one IP address for sending account notifications and a different IP address for sending promotional messages."

Yahoo is more direct: "Don't send bulk/marketing email from the same IPs you use to send user mail, transactional mail, alerts, etc." It explains that each IP and DKIM domain has its own reputation, and "By segregating your email according to function, you help ensure that your mail receives the best delivery possible." In practice many apps use a separate sending stream or subdomain for marketing, so a complaint-heavy campaign does not drag down the reset emails. Ask your email provider how it separates the two.

Yahoo also warns about one risk that is specific to apps: "Filter user-generated content before sending it, to prevent spammers from using your resources." If users can type a message that goes into an invitation or a share email, spammers can use your app to send their text under your name. Limit what can be typed, rate-limit how many invitations one account can send, and log them.

Password reset emails

The OWASP Forgot Password Cheat Sheet covers the reset flow in detail, and our user authentication guide sums up its token rules. Several points are about the email itself:

• Same answer for every address. OWASP says: "Return a consistent message for both existent and non-existent accounts", and responses should take a consistent amount of time. It suggests "asynchronous calls" as one way to do that, which in practice means putting the email in a queue rather than sending it while the user waits.
• Limit requests. Without rate limits, OWASP warns, an attacker could send thousands of requests for one account, "flooding the user's intake system (e.g., email inbox or SMS) with useless requests."
• Build the link safely. "Don't rely on the Host header while creating the reset URLs to avoid Host Header Injection attacks. The URL should either be hard-coded, or validated against a list of trusted domains." The reset page should also use a Referrer Policy of no-referrer, so the token does not leak to other sites.
• Confirm the change. After the reset, OWASP says to "Send the user an email informing them that their password has been reset (do not send the password in the email!)." It also advises against logging the user in automatically after the reset.
• Tell the user after a recovery. When an account may have been taken over, OWASP says to notify the user "through all applicable registered notification addresses", with instructions and contact details for reporting a recovery they did not make.

Sender name, subject and links

Gmail's guidelines list formatting rules that apply to every message. From headers "should include only one email address", every message needs "a valid Message-ID", and single-instance headers such as From, To, Subject and Date must appear only once. Subject lines should not start with Re: or Fwd: unless the message really is a reply or a forward. Gmail also says: "Don't use HTML and CSS to hide content in your messages" and "Web links in the message body should be visible and easy to understand."

For the display name, Gmail says it "should be used exclusively to identify the sender" and adds: "Don't include subject or message content in display names." So Acme Billing is fine; URGENT: invoice overdue as a sender name is not. These are small template choices, but they are cheap to get right at the start.

Notifications users can switch off

Between pure transactional mail and marketing sit the optional emails many apps send: weekly summaries, digest emails, product updates. Gmail's rule for senders of more than 5,000 messages a day is that "Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body." Yahoo asks bulk senders to support one-click unsubscribe "for marketing and subscribed messages" and to honour unsubscribes within 2 days; Google recommends 48 hours. The rules for marketing consent are in our email marketing rules guide.

One-click unsubscribe is defined in RFC 8058 (January 2017). The message carries a List-Unsubscribe header with one HTTPS link and a List-Unsubscribe-Post header with the value List-Unsubscribe=One-Click, both covered by a DKIM signature. For a developer, three details matter: the link "MUST contain enough information to identify the mail recipient and the list", the POST request "MUST NOT include cookies, HTTP authorization, or any other context information", and "The mail sender MUST NOT return an HTTPS redirect". So the unsubscribe endpoint must work for someone who is not logged in, from the link alone.

Google notes that one-click unsubscribe "doesn't automatically remove the recipient from all messages from the same sender": the recipient is removed "only from the mailing list associated with the message." That suits an app well. Give each optional notification type its own list, so switching off the weekly digest does not stop invoices or security alerts.

Bounces, volume and monitoring

Gmail suggests you "Automatically unsubscribe recipients who have multiple bounced messages", and Yahoo asks senders to "Monitor hard and soft bounces as well as inactive recipients" and to "Remove invalid recipients from your list promptly." For an app, a hard bounce on an account address usually means the user cannot receive resets or invoices. Mark the address as failing and ask the user to update it the next time they sign in, rather than sending again and again.

Volume matters at launch and after a big import. Gmail recommends that you "Send email at a consistent rate" and "Avoid sending email in bursts", and to start with a low volume and increase it slowly. When Gmail returns error 4.7.28 for exceeding its limits, it says: "Do not send email for at least 10 minutes." Build sending through a queue that can slow down and retry, rather than sending thousands of messages from a single request.

To see how your mail is received, Gmail points senders to Postmaster Tools for spam rate, authentication and reputation. Yahoo runs a Complaint Feedback Loop for DKIM-signed mail, which sends you a copy of messages that Yahoo users report as spam. Your email provider's dashboard adds delivery, bounce and complaint figures per message type.

What to put in the brief

Email is often left until the end of a web app project. Agree these points with your developer before the build:

• a list of every email the app sends, marked as transactional or optional;
• the sending service, the sending domain or subdomain, and SPF, DKIM and DMARC for it;
• From addresses and display names per category, and no promotions in transactional mail;
• the password reset flow as OWASP describes it, including the confirmation email;
• one-click unsubscribe and a preferences page for optional notifications;
• limits on invitations and any user-written text in emails;
• a sending queue with retries, bounce handling, and who checks the reports.

FAQ

Do transactional emails need an unsubscribe link?

Google says one-click unsubscribe is required only for marketing and promotional messages, and that transactional messages such as password resets, reservation confirmations and form submission confirmations are excluded. Optional notifications such as digests are subscribed messages, so give them an unsubscribe option.

Can I add a promotion to a receipt email?

Gmail's sender guidelines say not to mix different types of content in one message, and give including promotions in sales receipt messages as the example. Send offers as separate marketing email to people who agreed to receive it.

Should transactional and marketing email use different addresses?

Gmail asks that messages of the same category use the same From address, for example one for receipts, one for promotions and one for account notifications. Yahoo advises sending marketing email from different IPs than transactional mail and alerts.

Can my web server send the emails itself?

It can, but the mail must still meet Gmail's and Yahoo's requirements: SPF or DKIM, valid forward and reverse DNS, TLS and correct formatting. Most apps send through an email service that the domain's SPF and DKIM records cover.

What should a password reset email contain?

A single-use link built from a fixed or validated domain, never from the request's Host header, as OWASP advises. After the reset, send a confirmation email that does not include the password.

Planning a web app whose emails need to reach the inbox? See our web app development service and all our services, or email [email protected].