How Email Foundry Routes Marketing And Transactional Messages

Marketing and transactional email may leave the same business, use the same customer data and share a recognisable brand. They should not, however, automatically share the same sending stream.

A password-reset message is expected immediately by one person who has just asked for it. A weekly product update is sent on the sender’s timetable to a wider subscribed audience. The two messages have different urgency, recipient expectations, complaint risk and acceptable delivery delay. Treating them as interchangeable can allow weak marketing engagement to affect important account or service communications.

Email Foundry’s approach is therefore to classify permission-based mail by its purpose and recipient expectation, then apply the appropriate sending controls. Where the underlying sending infrastructure supports it, that can include separate identities or routes, mailbox-provider-aware pacing and evidence-led routing decisions. It is not a technique for disguising unwanted mail, cycling through infrastructure, or working around a provider’s protections. The starting point is always legitimate permission, sound authentication and mail that recipients reasonably expect.

First, distinguish the message types properly

Transactional email is triggered by a customer action or an essential account, service or purchase event. Typical examples include password resets, login alerts, order receipts, delivery updates, subscription confirmations and security notifications. Its primary purpose is to complete, confirm or protect a relationship or transaction.

Marketing email promotes products, content, offers, events or a broader commercial relationship. Newsletters, sale announcements, product recommendations, win-back programmes and seasonal campaigns generally belong here, even when they are personalised.

The distinction matters because mailbox providers recognise it. Google’s sender guidance says that one-click unsubscribe is required for marketing and promotional messages, while transactional messages such as password resets and reservation confirmations are excluded from that specific requirement. The same guidance also advises using different IP addresses for different message types where multiple IPs are used, giving account notifications and promotions as the example. Google’s email sender guidelines and its sender-guidelines FAQ are useful reference points here.

There is a practical grey area: an order-confirmation email with a small cross-sell module is still principally transactional if the confirmation remains the clear reason for the message. But if the promotional material becomes the main event, or the message is sent without a recent customer action to justify it, it should be treated as marketing. Classification should follow the actual recipient experience, rather than an internal campaign label.

Why separate streams protect delivery

Mailbox providers assess many signals, including authentication, complaint behaviour, recipient engagement, sending patterns and IP or domain reputation. A sender cannot assume that a clean transactional programme will neutralise a poorly targeted promotional one.

Separation gives each stream a clearer operational identity. Promotional messages can be paced around demonstrated engagement and frequency limits; a password-reset email can retain the prompt handling appropriate to a security request. A surge in complaints from a marketing campaign is easier to detect, isolate and correct when it is not mixed indistinguishably with receipts and account alerts.

Yahoo’s sender guidance explicitly advises senders not to send bulk or marketing mail from the same IPs used for user mail, transactional mail and alerts. Yahoo’s sender best practices also require authentication and support for one-click unsubscribe for bulk senders. Microsoft similarly recommends considering separate authenticated subdomains for bulk and transactional traffic, such as distinct marketing and transactional subdomains. Microsoft’s outbound-authentication guidance makes clear that this is a deliverability recommendation, not a delivery guarantee.

That does not mean every organisation needs a dedicated IP address for every kind of email. Smaller senders may be using shared infrastructure, and volume alone does not make an IP strategy appropriate. The underlying principle is clearer than any fixed infrastructure rule: keep materially different traffic types distinguishable, authenticate them correctly and do not expose urgent service mail to avoidable promotional-mail risk.

What routing means in this context

Routing is sometimes used loosely to mean “sending via a different provider”. In responsible deliverability work, it is broader and more disciplined. It is the decision about how a legitimate message is prepared, segmented, paced and handed to the appropriate sending infrastructure, based on its type and the evidence available.

For a permission-based sender, Email Foundry’s routing work can involve the following layers.

Message classification and stream ownership

Each message should be assigned to a stream before it is sent: for example, lifecycle marketing, purchase communications, security alerts or operational notices. The stream should have a clear owner, sending purpose, From identity and suppression rules.

A useful arrangement might use news.example.co.uk for newsletters and notify.example.co.uk for account or order communications, with valid authentication configured for each. Subdomains are not a shortcut to a clean reputation. They are a way to create clearer boundaries and make it easier to see which programme is responsible when a problem appears.

Authentication and identity checks before traffic moves

Routing cannot compensate for broken identity. Before making volume or infrastructure decisions, Email Foundry checks the relevant sending setup: SPF authorisation, DKIM signing, DMARC alignment, DNS and infrastructure configuration. These checks matter for every stream, but they are especially important when several systems send for the same brand.

For Gmail personal accounts, all senders must use SPF or DKIM, while bulk senders need SPF, DKIM and DMARC. Bulk senders must also align the From-domain organisational domain with either SPF or DKIM for direct mail. Gmail describes a bulk sender as a sender reaching around 5,000 messages or more to personal Gmail accounts in 24 hours; once classified, the status does not expire. Google’s current bulk-sender FAQ explains the detail.

Outlook.com has also required domains sending more than 5,000 messages a day to comply with SPF, DKIM and DMARC requirements. Its published guidance says non-compliant traffic can be rejected, including with a 550 5.7.515 error. Microsoft’s Outlook.com high-volume sender requirements should be reviewed alongside any platform-specific configuration.

One recurring source of trouble is a brand using several systems: an ecommerce platform, a support desk, a marketing platform and a product application. Each can send apparently legitimate mail, but an omitted SPF authorisation, unsigned message or misaligned From domain can create failures. Proper routing starts by mapping these sources rather than assuming that a single DNS record covers them all.

Audience eligibility and suppression

A route should only carry messages to people eligible to receive them. For marketing mail, that includes consent status, unsubscribes, previous hard bounces, complaints where feedback is available and sensible contact-pressure rules. Transactional streams need their own safeguards too: they must not be used to continue marketing to someone who has opted out, and they should only be triggered by a genuine service event.

Email Foundry can apply audience verification, suppression and likely-human engagement filtering before promotional volume is released. This helps avoid sending a campaign indiscriminately to stale, unresponsive or risky records merely because they remain in a database. It is not a case for suppressing people who have simply not opened an email once; open data is imperfect, and Google notes that it does not track or verify third-party open rates. Google’s guidance instead points senders towards recipient feedback, authentication and Postmaster Tools data.

Provider-level pacing rather than a single blast rate

Different mailbox providers and recipient domains can respond differently to the same campaign. Provider-level pacing means adjusting the rate at which messages are released to particular destinations, based on delivery responses, reputation indicators, recent complaint signals and the history of the stream. It is designed to keep sending controlled and observable rather than delivering a sudden burst with no room to react.

For example, if a re-engagement campaign produces temporary deferrals at one provider, the sensible response is usually to slow or pause that segment, inspect audience quality and review the campaign, not to force the volume through elsewhere. Google recommends consistent sending rates, gradual volume increases, and monitoring server responses, spam rate and reputation as volume grows. Its sender guidelines also warn that quotas can be tracked by domain and IP.

Transactional mail is paced differently. A customer who has requested a password reset should not wait behind a large newsletter release. But transactional urgency does not justify poor controls: repeated failed login notifications, duplicate event triggers or an account-error loop can create a high-volume and unwanted stream very quickly. Routing should therefore include event validation, deduplication and sensible rate controls at the application level.

Evidence-led provider-aware routing

Where the available platform and infrastructure support it, Email Foundry can use provider-aware routing as one part of a managed recovery or protection programme. The decision should be based on evidence, such as SMTP response patterns, inbox-placement testing, authentication results, known blocklist signals and provider reporting. It should not be based on simplistic assumptions that one provider is inherently “better” for every type of message.

This is important because a route change cannot repair the underlying causes of poor delivery: absent permission, excessive frequency, weak audience quality, deceptive content or broken authentication. It can only determine how correctly prepared, expected messages are handled within the available infrastructure.

How feedback changes the routing decision

Routing is not a one-off configuration exercise. It needs a feedback loop.

For Gmail, Google Postmaster Tools provides data on spam reports, authentication, reputation and delivery errors when there is sufficient relevant traffic. Google recommends keeping the user-reported spam rate below 0.1% and avoiding 0.3% or higher. These are provider thresholds and guidance, not a target to operate close to. Google’s Postmaster Tools FAQ describes the available dashboards, including delivery errors and spam rate.

For Outlook.com, Microsoft’s Smart Network Data Services (SNDS) offers data intended to help senders understand and improve their reputation with Outlook.com, while the Junk Mail Reporting Program can supply complaint feedback to eligible senders. Microsoft’s SNDS service explains that access is requested for the IPs a sender is responsible for. These sources can help show whether a problem is isolated to a particular route, IP range or programme.

Email Foundry uses the available provider reporting alongside inbox placement tests, blacklist monitoring and sending-platform data to determine whether a stream should continue, slow down, be narrowed to a stronger audience or be paused while a root cause is corrected. The objective is to learn from recipient and provider signals early, before a local campaign issue becomes a broader reputation problem.

Examples of routing decisions

A newsletter to a mixed engagement audience. A retailer plans a seasonal promotion to all historic subscribers. Rather than send at one rate to everyone, a responsible programme may first exclude ineligible and clearly risky contacts, apply contact-pressure rules, begin with the recently engaged portion and monitor provider-level response. The message remains marketing mail, with a clear unsubscribe path, regardless of how much purchase history it contains.

An order confirmation with a recommendation block. The confirmation belongs in the transactional stream because it confirms a recent order. The recommendation should remain secondary, and the message must not be used as a vehicle to bypass the customer’s marketing preference. If the promotional content takes over, it should be separated into a marketing message with the appropriate opt-out treatment.

A sudden Gmail deferral pattern. The correct response is not to move the same campaign to a new sending identity and carry on. The sender should examine the SMTP responses, authentication, spam-rate and audience signals; reduce or pause relevant Gmail volume where appropriate; and correct the trigger, content, frequency or list-quality issue. A provider-aware route is a control for legitimate traffic, not a way to evade enforcement.

What responsible routing does not do

It does not make purchased, scraped or cold-prospecting lists safe to mail. It does not relabel promotional content as transactional to avoid unsubscribe expectations. It does not promise inbox placement, because recipients and mailbox providers make the final placement decisions. And it does not treat new subdomains, IPs or vendors as disposable replacements for a damaged sending reputation.

For organisations with a delivery problem, the practical value is in finding the contributing causes: authentication gaps, unexpected senders, contaminated audiences, excess contact pressure, unstable sending patterns or poor complaint performance. Email Foundry’s managed recovery work is relevant when those issues need coordinated investigation and controlled remediation over time. Routing is one tool within that process, rather than the whole answer.

The principle behind the route

The best route reflects what the message is, why the recipient should expect it and what current evidence says about sending it safely. Marketing mail should be permission-based, recognisable, easy to leave and released at a pace the audience and providers can sustain. Transactional mail should be prompt, authenticated, tightly tied to a real event and insulated from avoidable promotional risk.

When those fundamentals are in place, separate identities, audience controls, pacing and provider feedback make the sending operation easier to understand and protect. When they are absent, changing the route only changes where the underlying problem appears.