A request a dedicated IP process is not simply a billing or infrastructure change. It is a deliverability decision: your organization takes responsibility for building and maintaining the sending reputation previously shared with other customers on a provider’s IP pool.

For transactional email teams, the right preparation makes approval and IP warming much smoother. This guide explains what providers generally assess, what to include in the request, how to prepare DNS and sending systems, and how to protect the reputation of a newly assigned IP.

What a dedicated IP is—and what it is not

A dedicated IP is an outbound mail IP address reserved for one sender or organization. Instead of your application’s email leaving from a shared provider IP used by many approved senders, mail sent through your account is routed through an IP associated with your own program.

That distinction matters because mailbox providers build reputation signals around several identifiers. The sending IP is one identifier, but it is not the only one and is increasingly not the most important one. Receiving systems also evaluate the visible From domain, DKIM signing domain, envelope-from or return-path domain, content, recipient engagement, complaint patterns, and sending consistency.

A dedicated IP therefore does not provide an automatic delivery advantage. A fresh IP has little or no reputation, which means it must earn trust. A well-managed shared pool can outperform a poorly warmed dedicated IP, especially for low-volume or irregular senders.

It also helps to separate a dedicated sending IP from these related concepts:

  • Dedicated IP: The public IP address your email provider uses when relaying your outbound email.
  • Dedicated sending domain: A domain or subdomain reserved for your sending identity, such as notify.example.com.
  • Dedicated tracking domain: A branded domain or subdomain used for click tracking, such as links.example.com.
  • Dedicated return-path domain: A custom envelope-from domain used for bounce processing and SPF alignment, such as bounce.example.com.
  • Static application egress IP: An IP your application uses to call a provider’s REST API or connect to its SMTP relay. This is unrelated to the email-delivery IP in most setups.

Do not assume that obtaining a dedicated email IP requires changing your application’s outbound firewall rules or publishing an A record for the IP. Normally, your provider handles the mail transport and reverse DNS. Your primary work is authenticating the sending domain, maintaining list quality, and changing volume carefully.

When to request a dedicated IP

The best reason to request a dedicated IP is not “dedicated sounds better.” It is that your email volume, cadence, and operational maturity make IP-level reputation ownership useful.

A dedicated IP is often a reasonable fit when you have predictable, sustained daily traffic. Examples include a large SaaS platform sending account activity notifications, a marketplace issuing order and shipment events, a financial service sending statements and security alerts, or a high-volume application that has enough traffic to warm and maintain an IP continuously.

Many transactional email providers set minimum-volume rules because a dedicated IP needs consistent mail flow. As one current example of provider policy, MailerSend describes dedicated IPs as a high-volume option, notes an eligibility threshold of 500,000 emails per month, suggests at least 50,000 emails per day for optimal reputation protection, and recommends roughly one dedicated IP per 10 million messages per month. Those figures are provider-specific, not a universal standard, but they illustrate why dedicated IPs are generally aimed at established senders rather than early-stage applications.

Signs that a dedicated IP may be appropriate

Consider requesting one when most of the following are true:

  1. Your volume is substantial and steady. You can send a meaningful number of wanted messages every day, including weekends if your product activity supports it.
  2. Your recipients expect the mail. Password resets, receipts, confirmations, alerts, and account notifications usually have clearer user intent than cold outreach or loosely permissioned promotional mail.
  3. You have authenticated domains already. SPF, DKIM, and DMARC are implemented and monitored before the move—not after an incident.
  4. You can segment traffic. You can separate critical transactional messages from marketing, product announcements, and lower-engagement notifications.
  5. You can control deployment volume. Your engineering and operations teams can ramp traffic gradually, pause a problematic stream, and avoid sudden spikes.
  6. You have people and dashboards to watch deliverability. Someone can review bounces, complaints, authentication failures, deferrals, inbox placement indicators, and provider feedback.

Signs that you should remain on shared IPs

A shared pool is usually the safer choice if you send only a few thousand messages a month, have long periods with no email, or generate highly unpredictable bursts. It can also be better when your email provider has mature shared-pool controls and your own program does not yet have reliable suppression handling and engagement hygiene.

Avoid a dedicated IP if the underlying goal is to “escape” a poor reputation caused by invalid addresses, spam complaints, scraped contacts, misleading content, or weak consent. Those problems follow the domain and sending behavior. A new IP may briefly look neutral, but it will acquire the same negative signals if the program does not change.

What providers evaluate before approving a request

Most transactional email providers manually review dedicated-IP requests because one sender’s poor practices can create abuse handling, blocklisting, and network-reputation risk. The exact form, contract terms, fees, and thresholds differ by provider, but the evaluation topics are remarkably consistent.

The provider wants to know whether you can safely build a positive reputation and whether your messages are legitimate, expected, and technically compliant. Treat the request like a concise deliverability plan rather than a one-line support ticket.

Sending volume and cadence

State your current and expected volume in daily and monthly terms. Include expected peaks and explain why they occur. For example, a payroll platform might send 80,000 routine notifications on ordinary days and 450,000 on scheduled payroll dates. A provider can assess whether that pattern can be warmed safely and whether one IP is sufficient.

Be honest about seasonality. A retailer may send much more during November and December, while an education platform may spike during enrollment. Surprises are difficult to manage during warming; planned variation is manageable.

Email type and recipient relationship

Describe each message category and its user trigger. Strong examples include:

  • Password resets requested by the user.
  • One-time passcodes and security alerts.
  • Purchase receipts, invoices, shipping updates, and appointment reminders.
  • Product notifications a user selected in account settings.
  • Account-verification messages following a sign-up.

If you also send marketing mail, identify it separately. Explain how recipients subscribed, how frequently they receive messages, and how they unsubscribe. Never characterize marketing traffic as transactional merely to simplify approval. Classification affects risk assessment and may affect required headers, unsubscribe behavior, and routing decisions.

Authentication and identity controls

Providers commonly expect at least one authenticated sending domain before assigning a dedicated IP. A credible request confirms that SPF and DKIM pass, that DMARC is published, and that the visible From domain aligns with SPF or DKIM for direct mail.

Google’s sender guidance says all senders to personal Gmail accounts need SPF or DKIM, while bulk senders need SPF, DKIM, and DMARC. Google defines a bulk sender as an organization that sends close to 5,000 or more messages to personal Gmail accounts within 24 hours. Those requirements make authentication a prerequisite for any serious dedicated-IP plan, not a finishing step.

Complaint, bounce, and suppression handling

Explain how your system handles hard bounces, complaints, unsubscribes, and repeated delivery failures. A provider needs confidence that invalid or unwilling recipients will not receive repeated mail.

Useful details include whether you process provider webhooks, how quickly a hard bounce is suppressed, whether marketing opt-outs apply globally, and how you stop retrying after permanent failures. For a REST API integration, capture message IDs and delivery-event webhooks. For SMTP relay integrations, capture accepted-message identifiers where available and reconcile them with event data from the provider.

Security and abuse controls

Providers also assess whether an attacker could use your account to send abuse. Mention token rotation, least-privilege access, multi-factor authentication where supported, rate limiting, audit logs, and IP allowlisting for API or SMTP credentials where your provider supports it.

A compromised application token can destroy a new IP’s reputation in hours. Dedicated IP ownership requires operational controls, not only DNS records.

What to include in your dedicated IP request

A good request reduces back-and-forth and gives the provider’s deliverability team enough context to make a sound decision. You do not need to write a formal essay, but you should include concrete data rather than vague claims such as “we send a lot of important emails.”

Use this template and replace the bracketed values:

Subject: Dedicated IP request for [company / account ID]

We would like to request a dedicated outbound IP for transactional email.

Sending domain(s):
- [example.com]
- [notify.example.com]

Current volume:
- Average daily: [number]
- Peak daily: [number]
- Monthly: [number]
- Expected growth over next 90 days: [number or percentage]

Message categories and approximate share:
- [e.g., password resets and account security alerts: 20%]
- [e.g., receipts, invoices, and order updates: 65%]
- [e.g., opted-in product notifications: 15%]

Recipient acquisition and consent:
- [how users sign up or trigger messages]
- [how marketing recipients opt in, if applicable]

Authentication:
- SPF: [pass / record published]
- DKIM: [pass / selector(s)]
- DMARC: [published policy]
- Custom return-path / tracking domain: [if applicable]

Deliverability controls:
- Hard bounces are suppressed within [time period].
- Spam complaints and unsubscribes are suppressed [scope].
- We monitor [provider events, Postmaster Tools, feedback loops, etc.].

Sending integration:
- [REST API / SMTP relay]
- [regions or source systems]

Warm-up plan:
- [daily volume ramp, segmentation, and fallback plan]

Please let us know the eligibility requirements, pricing, IP allocation process,
rDNS/HELO configuration approach, and the recommended warm-up schedule.

This format makes clear that you understand the responsibility involved. It also prompts the provider to disclose important implementation details, such as whether the IP is automatically assigned to all traffic, can be applied by subdomain or stream, supports IP pools, and includes provider-managed warm-up assistance.

Prepare your domain authentication before the IP is assigned

Dedicated IP warming works best when domain identity is already stable. Configure and test your sending domain before you ramp volume. Keep in mind that the values below are examples of syntax, not values to copy blindly: your provider supplies the exact hostnames, selectors, and target values for its infrastructure.

SPF: authorize the envelope sender

SPF is published as a DNS TXT record. It evaluates which systems may send for the envelope-from domain, also called the MAIL FROM or return-path domain. A simple example for a domain that sends only through one provider could look like this:

example.com. 3600 IN TXT "v=spf1 include:spf.email-provider.example -all"

If you also send mail from a separate system with a known IPv4 address, the record might be:

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.24 include:spf.email-provider.example -all"

Use a single SPF TXT record per domain. Do not create separate SPF records for each sending service. Combine authorized mechanisms into one record, and ensure you remain within SPF’s DNS-lookup limits. RFC 7208 defines SPF and its evaluation rules.

Do not use an IP address in SPF just because it is your dedicated outbound email IP unless your provider specifically instructs you to do so. Managed email platforms commonly ask you to authorize their sending infrastructure through an include: mechanism or a custom return-path configuration. Their provided value may change or may include more than one IP.

DKIM: cryptographically sign mail

DKIM publishes a public key in DNS while the provider signs messages with the matching private key. A TXT-style DKIM record might have a hostname like this:

s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Many providers instead request a CNAME delegation, which keeps the key material and rotations on provider-controlled DNS. That form may look like:

s1._domainkey.example.com. 3600 IN CNAME s1.example.com.dkim.email-provider.example.

Both patterns are legitimate when supplied by your provider. Publish the exact records shown in your provider’s domain-authentication instructions. Do not change selectors, remove quotation marks where your DNS interface requires them, or substitute a root domain for a required subdomain.

Use an aligned DKIM domain whenever possible. For example, if your visible From address is alerts@notify.example.com, signing with d=notify.example.com provides straightforward relaxed DMARC alignment.

DMARC: publish policy and receive feedback

A DMARC record lives at _dmarc under the domain being evaluated. A conservative monitoring record can look like this:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; adkim=r; aspf=r; pct=100"

This tells receivers to collect aggregate reporting without requesting quarantine or rejection for mail that fails DMARC. After reviewing reports and ensuring all legitimate streams authenticate and align, an organization may choose a stronger policy such as p=quarantine or p=reject according to its security and deliverability goals.

The rua mailbox must be able to receive reports, directly or through a DMARC-reporting service. Do not publish an address nobody monitors. DMARC is useful during a dedicated-IP migration because reports can expose an overlooked application, vendor, or domain that is sending unauthenticated mail.

Custom return-path and tracking records

Your provider may request a CNAME for a branded return-path domain or a branded tracking domain. A generic return-path delegation might resemble:

bounce.example.com. 3600 IN CNAME u123456.wl.email-provider.example.

A tracking-domain delegation could resemble:

links.example.com. 3600 IN CNAME track.email-provider.example.

The exact record labels and targets are provider-specific. Do not infer them from examples. In particular, a CNAME record cannot coexist with other record types at the same hostname, so choose an unused subdomain such as bounce, mail, or links rather than the apex domain.

For implementation details specific to a REST or SMTP sending integration, consult the provider’s email API setup guidance and use the generated DNS values for your account.

Understand reverse DNS, HELO, and dedicated-IP identity

Reverse DNS, also called PTR, maps an IP address back to a hostname. Receiving systems commonly expect outbound email IPs to have valid reverse DNS, and many providers configure it as part of dedicated-IP provisioning.

For example, the provider may set a PTR such as:

198.51.100.50 -> mailout-01.email-provider.example

or, when the provider supports custom branding and has verified the required DNS relationship:

198.51.100.50 -> mta1.example.com

Your provider controls the PTR because it controls the IP address block. You cannot usually create a PTR record from your ordinary domain DNS panel. Ask these questions before warming begins:

  • What hostname will the IP’s PTR resolve to?
  • Does the forward DNS for that hostname resolve back to the assigned IP?
  • What EHLO or HELO hostname will the provider’s SMTP server present?
  • Is custom reverse DNS available, optional, or managed only by the provider?
  • Is the dedicated IP assigned to a single sending domain, all account domains, or a configurable stream?

Avoid promising a custom PTR name to stakeholders before the provider confirms it. A valid, provider-managed reverse DNS name is often entirely appropriate. The important issue is that transport identity is configured correctly and the sending domains authenticate consistently.

Build a deliberate IP warm-up plan

IP warming is the controlled process of creating a positive reputation on a new or previously idle IP. The aim is not to send as fast as possible. The aim is to demonstrate consistent, wanted mail to major mailbox providers while limiting the impact of a problem.

There is no universal daily-volume table. Appropriate ramp speed depends on total volume, recipient-domain mix, historic domain reputation, message type, complaint rate, engagement, and the provider’s infrastructure. Transactional traffic can sometimes ramp differently from promotional traffic because it is triggered by clear user actions, but it still needs careful observation.

Start with the most wanted messages

Prioritize recipients most likely to recognize and value the messages. Good starting segments include recent active users, customers expecting a receipt or shipment update, users who initiated a password reset, and subscribers with recent engagement.

Do not start an IP warm-up by mailing inactive addresses, old imported lists, or every historical contact. Low engagement and complaints during the first days can create reputation problems precisely when the IP has no established trust.

Example warm-up structure

The following is an illustrative operational pattern, not a provider-mandated schedule. Confirm the permitted rate and any provider-supplied plan before using it.

  1. Days 1–3: Send a small, consistent portion of the cleanest, highest-intent transactional traffic. Watch authentication, deferrals, hard bounces, complaint signals, and delivery events.
  2. Days 4–7: Increase gradually only if delivery indicators remain healthy. Add another message category or recipient cohort rather than sending a large batch to dormant users.
  3. Week 2: Continue stepwise increases, keeping daily traffic relatively even. Do not double volume automatically if the previous day produced unusual deferrals or complaints.
  4. Weeks 3–4 and beyond: Move more production traffic once mailbox-provider behavior is stable. Retain a rollback route to a shared pool or prior route if the provider supports it.

The most important principle is consistency. An IP that sends a controlled daily volume is easier for receivers to evaluate than one that sends nothing for six days and millions of messages on day seven.

Keep critical and risky streams separate

If your provider supports IP pools or stream-level routing, keep essential transactional mail separate from lower-engagement promotional or bulk notification mail. Password resets and account-security notifications should not depend on the reputation of a weekly product newsletter.

If stream-level dedicated routing is not available, use separate authenticated subdomains and carefully manage the content and recipient expectations for each. This does not fully isolate IP reputation, but it improves diagnosis and domain-level governance.

Monitor results with the right signals

A successful SMTP response only means the receiving server accepted the message for further processing. It does not prove inbox placement, user engagement, or final delivery to the inbox rather than spam.

Your monitoring should combine provider event data, mailbox-provider tools, DNS checks, and message-level tests.

Delivery events and SMTP status codes

At the API layer, an accepted send request may return a success response such as HTTP 200 OK, 201 Created, or 202 Accepted, depending on the provider. An acceptance response normally means the provider accepted the submission; it does not guarantee recipient delivery.

Common API errors that deserve immediate attention include:

  • HTTP 400 Bad Request: malformed JSON, invalid parameters, or an invalid request shape.
  • HTTP 401 Unauthorized: missing, expired, or invalid credentials.
  • HTTP 403 Forbidden: valid credentials but insufficient permission, account restriction, or an access control rule such as an IP allowlist.
  • HTTP 422 Unprocessable Entity: structurally valid request that fails validation, such as an invalid sender or recipient field.
  • HTTP 429 Too Many Requests: rate limit or quota exhausted; back off and retry according to the provider’s guidance.
  • HTTP 5xx: a temporary server-side issue; retry with exponential backoff and idempotency protection where available.

At SMTP level, codes in the 2xx range generally indicate success, 4xx codes indicate temporary failure or deferral, and 5xx codes indicate permanent failure. Examples include 250 for successful acceptance, 421 for a temporary service or connection condition, 451 for a temporary local processing issue, 550 for a permanent mailbox or policy rejection, and 554 for a transaction failure or policy-related rejection. The enhanced status code and human-readable response often provide more useful detail than the three-digit code alone.

Do not treat 421, 451, or other 4xx responses as permission to retry aggressively. Back off, reduce concurrency if necessary, and investigate whether a particular recipient domain is throttling the new IP.

Domain and authentication checks

Use command-line DNS checks during setup and after DNS changes:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com
dig +short CNAME bounce.example.com
dig +short -x 198.51.100.50

Tools such as MXToolbox can help inspect SPF, DKIM, DMARC, reverse DNS, and blocklist visibility. For message-level testing, send a controlled test to mail-tester.com and inspect the authentication, headers, and content feedback it returns. These tools are diagnostic aids, not proof of inbox placement across every mailbox provider.

For Gmail-focused programs, Google Postmaster Tools can provide domain-level information such as spam rate, reputation, authentication, and delivery errors once enough traffic is available. Google recommends keeping reported spam rates below 0.3%, and its dashboards help identify whether the issue is authentication, reputation, or delivery behavior.

Metrics to review daily during warm-up

Track metrics by sending domain, IP, recipient mailbox domain, message type, and traffic source where possible. At minimum, review:

  • Volume sent, accepted, delivered, deferred, bounced, and suppressed.
  • Hard-bounce rate and the addresses or source systems producing it.
  • Complaint or feedback-loop events.
  • Authentication pass rates for SPF, DKIM, and DMARC.
  • Deferral codes and rejection reasons by Gmail, Yahoo, Microsoft, and other significant recipient domains.
  • Unsubscribe events for marketing or optional notification streams.
  • Delivery latency for time-sensitive transactional messages.
  • Any unexpected change after a code deployment, template release, or acquisition of a new traffic source.

Avoid the mistakes that damage a new dedicated IP

The same mistakes recur across providers because they are operational rather than vendor-specific. Preventing them is far less expensive than repairing reputation after a block or widespread spam placement.

Moving all traffic at once

A common failure mode is routing every stream to the new IP on the first day. This removes the ability to distinguish a reputation problem from a content problem, a list-quality problem, or a configuration error. It also creates a large blast radius.

Use a controlled routing change instead. Start with a known traffic class, retain observability, and increase only after reviewing the results.

Mixing transactional and promotional traffic indiscriminately

A receipt sent immediately after a purchase is not equivalent to a broad campaign sent to a list that has not engaged in a year. Combining them can cause critical operational mail to inherit the reputation consequences of less-engaged marketing traffic.

Apply different consent rules, suppression policies, templates, and routing strategies to these message types. If your platform has separate streams or subaccounts, use them intentionally.

Overlooking a secondary sender

Organizations frequently authenticate their main application but overlook a support platform, CRM, billing tool, help desk, or legacy server still sending with the same visible From domain. When DMARC policy tightens or a dedicated-IP project begins, these shadow senders emerge as failures.

Inventory every service that sends mail as your domain. Review DMARC aggregate reports, DNS records, application secrets, and vendor settings. Then either authenticate each legitimate service or stop it from using the domain.

Treating a new IP as a clean slate

A new IP does not solve unwanted sending. Purchased lists, stale addresses, unclear consent, surprise frequency, and misleading subject lines will generate the same poor user and mailbox-provider signals regardless of IP age.

Fix the acquisition and message-expectation problem first. Yahoo’s sender guidance emphasizes sending mail users want, honoring the frequency promised at signup, avoiding purchased lists, and authenticating with SPF, DKIM, and DMARC.

Forgetting rollback and incident procedures

Before a migration, decide what happens if deferrals rise sharply, a credential is exposed, a template creates unexpected complaints, or a key mailbox provider starts rejecting mail. Write down who can pause the stream, rotate credentials, reroute noncritical traffic, and communicate with the provider.

A dedicated IP should improve control. It only does so when the organization has a controlled response path.

How REST API and SMTP relay integrations affect the request

The transport method—REST API or SMTP relay—usually does not determine whether you qualify for a dedicated IP. Both can send through the same provider-managed delivery infrastructure. What matters is the account’s sending behavior, authenticated identity, and ability to operate safely.

With a REST API, use a server-side token, restrict permissions to the smallest practical scope, and avoid exposing the token in client-side code. Store the provider’s message ID with your application event ID, then process webhooks for delivered, bounced, complained, and suppressed outcomes. Make webhook handling idempotent because event systems may retry deliveries.

With SMTP relay, use provider-issued SMTP credentials rather than a personal mailbox password. Require TLS or STARTTLS where supported, keep credentials in a secret manager, and set reasonable connection reuse and retry behavior. A sudden spike in connection failures or 421 responses can indicate configuration or throttling issues that deserve investigation before adding more volume.

For either method, make sender identity deterministic. A password reset generated by one microservice and a receipt generated by another should not alternate unpredictably between unrelated From domains or return-path settings. Consistent identity makes authentication, DMARC alignment, user recognition, and incident diagnosis much easier.

Conclusion: request the IP when you can operate it responsibly

To request a dedicated IP successfully, present a clear picture of your volume, email categories, consent practices, authentication, suppression controls, and warm-up plan. Ask the provider how it assigns the IP, handles reverse DNS and SMTP identity, prices the resource, and supports routing or pools.

Then treat allocation as the beginning of the work, not the end. Authenticate domains before ramping, begin with wanted traffic, increase gradually, monitor mailbox-provider feedback, and keep critical transactional email isolated from riskier streams. A dedicated IP can give a mature sender valuable control—but discipline, not exclusivity, is what builds reputation.

FAQ

How long does it take to get a dedicated IP?

Provider review and provisioning time varies. Some providers can allocate an IP quickly after approval, while the warm-up process can take weeks because mailbox providers need time and consistent traffic to establish reputation. Ask your provider for its current eligibility, setup, and warm-up timeline.

Do I need a dedicated IP for transactional email?

No. Many transactional senders perform well on reputable shared IP pools. A dedicated IP is most useful when you have sustained volume, predictable sending patterns, strong recipient hygiene, and the ability to monitor reputation actively.

Does a dedicated IP improve inbox placement immediately?

Usually not. A new dedicated IP starts with limited reputation. Inbox placement depends on authentication, domain reputation, recipient engagement, complaints, content, and sending consistency as well as IP reputation.

Do I need to add the dedicated IP address to my SPF record?

Not necessarily. Follow the provider’s exact domain-authentication instructions. Many managed email providers use an SPF include: record or a custom return-path domain rather than asking you to publish the individual dedicated IP.

Can I use one dedicated IP for marketing and transactional email?

You can technically do so in some platforms, but it is often risky. Separating critical transactional mail from lower-engagement promotional mail reduces the chance that campaign complaints or poor list quality affect password resets, receipts, and account alerts.