Mailgun email warmup: when to warm a dedicated IP

Mailgun says senders use a shared IP by default, and that a shared IP does not need new-IP warmup. If your Mailgun traffic moves to a new dedicated IP, use a controlled increase of legitimate mail to engaged recipients and monitor the actual sending path. A new domain can need similar care. Neither a Mailgun warmup plan nor a ramp proves that a production message authenticates correctly, has consent, or will reach an inbox.

When does Mailgun email warmup apply?

The first decision is the IP model, not a generic warmup calendar. Mailgun's IP warm-up guidance says a shared IP does not need an IP warm-up, while a new dedicated IP needs to be warmed before use. The same guidance says the pace depends on the sender's program and calls for a gradual increase rather than an immediate full-volume launch.

That distinction matters because a shared IP and a dedicated IP expose different evidence problems. Mailgun notes that activity from other senders can affect a shared IP. With a new dedicated IP, your own production traffic is the path being introduced. Do not copy another account's quota, date, or plan into either case. For the vendor-neutral operating rule, see the email warmup schedule.

What should a dedicated-IP ramp use as evidence?

Mailgun advises increasing the volume sent through a dedicated IP step by step and focusing on recipients who find the mail valuable. Its current warm-up article also distinguishes IP warmup from domain warmup and notes that a new domain can need a related controlled approach. Those are provider-specific recommendations, not a universal schedule or a guarantee.

Use the ramp to produce evidence from real mail. Google's email sender guidelines advise senders to increase volume slowly, avoid sudden spikes, and monitor delivery, spam rate, server responses, and sending-domain reputation. They also require authentication for the actual messages sent to Gmail. That makes a warmup plan an operating process, not a substitute for testing the production identity.

MAILGUN SENDING-PATH REVIEW
IP model: shared IP or new dedicated IP
Sending identity: From domain and Mailgun route under review
Authentication: SPF, DKIM, and DMARC on a representative delivered message
Audience: legitimate recipients who expect the mail
Observed results: delivery, SMTP responses, complaints, and available reputation signals
Decision: hold or investigate when the same path worsens; do not infer inbox placement from a warmup plan

What Mailgun warmup cannot prove

Mailgun's documentation describes a provider-side warmup process and the signals it recommends watching. It does not publish a rule that a warmup state proves the authentication result of your message, recipient consent, or a future inbox decision. That conclusion is an inference from the different evidence scopes, not a claim about Mailgun's private placement logic.

Confirm the From domain and authentication result on a representative delivered message before changing volume. What DMARC does explains why alignment is evaluated against the visible domain, while email deliverability covers the wider outcome beyond provider acceptance. If real messages are already filtering, investigate the message, consent, and sender history instead of treating more warmup activity as the repair.

Mailgun's public IP warmup glossary describes warmup as a gradual increase in volume for a new IP. It does not turn automated mailbox activity into equivalent evidence. If you are assessing that separate mechanism, read automated email warmup.

Check the public authentication baseline before a ramp

Before you raise volume on a domain you manage, use the Email Security Score to inspect its published SPF, DKIM, DMARC, and BIMI posture. That is a useful first check when the available evidence is a domain name. It cannot inspect the Mailgun account, confirm dedicated-IP allocation, read recipient consent, validate a delivered-message route, or determine inbox placement.

If recurring DMARC-report evidence later shows unknown senders or alignment failures, Palisade's remediation guide describes how Palisade's DMARC Agent analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies changes. Palisade does not operate Mailgun, warm an IP, change DNS automatically, or guarantee delivery or placement. Start with Palisade only when that recurring sender-evidence work remains after the immediate check.