Sending servers and IPs: choose the allocation your plan needs

When a plan mentions a sending server and an IP address, ask what each item actually allocates. The server side concerns the resources and software that accept, process, queue and transmit your messages. The IP side concerns the address used on an outbound connection. You need a description of both to understand the arrangement.

SMTP can involve more than one server. Your campaign application may submit mail to an intermediary before another server connects to the receiving service. For this guide, outbound IP means the source address on that final SMTP connection. Ask which step an advertised IP belongs to; an application's address is not automatically the delivery address.

Draw a simple inventory: campaign application, submission service, outgoing queue and receiver-facing connection. Against each item, record who operates it and what is shared. You are building a map for a decision, not trying to infer architecture from a product name.

Treat dedicated as a term that needs a written definition. It could describe an application instance, a virtual machine, reserved computing capacity or an entire physical machine. Those arrangements have different boundaries. The word alone does not tell you which one is being offered.

For example, a separately managed instance could still depend on shared physical equipment or networking. That may fit the requirement perfectly. A physical machine reserved for one customer can also depend on shared services elsewhere. Evaluate the actual boundary against your needs rather than ranking labels.

The matrix below is an original planning aid. Shared means more than one workload or sender uses the named resource; dedicated means it is reserved within a defined scope. Ask whether that scope is your account, a business unit or a particular sending stream. The table describes allocation choices, not a ranking or a list of available products.

Allocation describes who uses something. Isolation describes which effects can cross a boundary. A failure domain is the set of components that can be affected by the same incident. Do not substitute an IP count for an explanation of those dependencies.

Imagine two outbound IPs served by the same queue on the same host. If that queue stops, both routes could stop. That is a hypothetical example of why two addresses need not provide two independent recovery paths. Conversely, separating processing resources may address one contention concern while leaving another shared dependency.

Ask for a short dependency note covering the queue, host, storage, network path and management services. For each relevant incident, identify what stops, what remains available and what recovery requires. Separate a documented recovery design from a promise that someone will investigate.

• Capacity isolation: Can one workload consume resources another workload needs?
• Configuration isolation: Can one change affect another sending stream?
• Operational isolation: Which maintenance or incident could interrupt multiple routes?
• Recovery: What evidence supports the proposed restoration procedure and recovery expectations?

Google's personal Gmail guidance says senders sharing an IP can affect its reputation and others' delivery. It also discusses domain reputation, authentication and DNS. This guidance does not establish a universal preference for either allocation model.

A reserved address answers who may use that address. It does not demonstrate that your targeting is relevant, your authentication is correct or a receiving service will accept a particular message. SMTP receivers can refuse mail for operational or technical reasons. Acceptance itself is not evidence of inbox placement.

Make the evidence specific: the configured route, authentication checks, delivery responses and available monitoring for your sending activity. Before changing allocation, state the problem you expect the change to address. A queue capacity issue, an unclear operating owner and poor recipient response require different investigations.

These scenarios are hypothetical. They illustrate how to frame a discussion without promising performance or prescribing a volume threshold.

• A team is preparing its first repeatable campaign. Its immediate need is a clear queue policy, visible delivery responses and an accountable operator. Shared resources and a shared IP could be a candidate if those requirements are met. Ask how changes in demand and sending behaviour are managed before deciding that reservation is necessary.
• A team needs independent configuration and a defined processing allocation for a more complex workflow. Dedicated server resources with a shared IP could meet that particular resource requirement. Check which settings are independent and how the shared outbound address is managed. A separate processing allocation does not answer the IP question.
• A team needs a distinct outbound address for a clearly defined sending stream. Shared server resources with a dedicated IP could be considered if the processing arrangement fits. If the same team also needs reserved processing, evaluate the dedicated/dedicated combination. Record each requirement separately so the second reservation has a reason.

An allocation choice becomes useful when someone can operate it. Agree who manages the sending configuration, DNS changes, queue behaviour, access, monitoring and incident response. A managed service can take on agreed infrastructure work, but the handover still needs named responsibilities and a way to escalate a problem.

Keep campaign responsibilities visible too. The business controls its audience, message content, scheduling decisions and handling of recipient requests. Establish how campaign changes reach the infrastructure operator when they affect the workload. The receiving service makes its own acceptance and placement decisions; neither party should turn those decisions into an unconditional infrastructure promise.

Bring this worksheet to a planning conversation. Use your volume estimate to describe demand, including follow-ups and busy days, without treating the estimate as a safe sending limit. Mark unknown items as questions. A useful brief makes uncertainty visible before it becomes a launch assumption.

Ask the operator to confirm or correct the allocation and dependency entries. Keep the completed version with your launch plan so a later change has a clear starting point.