Introduction
A brand-new domain has no sending history, so mailbox providers treat it as unknown. If you ramp volume too quickly, you can see throttling, more spam-folder placement, or blocks while reputation signals are still forming.
This guide is for SaaS and development teams sending transactional email (OTPs, password resets, receipts, and alerts) who need a safe warm-up process without guesswork. It covers the setup checklist (SPF, DKIM, DMARC, and alignment), a practical ramp schedule, and the daily metrics that tell you when to slow down.
Warm-up cannot guarantee inbox placement because providers decide that. What it can do is reduce avoidable risk and help you build stable sending patterns with clear observability. Start with MailCub Documentation to validate your domain and API sending so you can see request results and basic email logs quickly.
Quick Answer
- Use one dedicated sending subdomain (for example, notify.yourapp.com) and keep it stable.
- Set up SPF and DKIM first, then add DMARC once you are ready for enforcement.
- Ramp daily volume gradually and do not exceed about 2× the previous stage/day.
- Start with your most engaged recipients to reduce early complaints and improve signals.
- Watch spam complaints daily: aim below 0.1% and avoid 0.3%.
- Use logs and event webhooks to categorize failures and react quickly.
Why It Matters
Warm-up is reputation building. Providers look at authentication, sending consistency, bounces, and user feedback to decide placement. Early negative feedback can affect future mail for weeks.
The provided content also notes Google spam-rate thresholds and daily spam-rate calculation. During warm-up, treat 0.1% as a strong target and 0.3% as a hard slow-down line.
It also notes stricter Microsoft requirements for high-volume senders (over 5,000 emails/day) to Outlook consumer domains, including SPF, DKIM, and DMARC. If your SaaS grows quickly or is multi-tenant, you may hit that threshold sooner than expected.
Warm Up a New Sending Domain Setup Checklist
Complete these before increasing volume. Otherwise, you may be warming up on a broken foundation.
1) Choose a sending identity (subdomain recommended)
Pick a dedicated transactional subdomain, such as notify.yourapp.com. Keep the From address consistent during warm-up. This makes DNS, monitoring, and future changes easier to manage.
2) Authenticate with SPF, DKIM, and DMARC (keep alignment clean)
Configure SPF and DKIM first. Add DMARC once you are confident in alignment and ready for stronger spoofing protection. Keeping alignment clean helps mailbox providers connect your authentication to your visible sending identity.
Use MailCub Documentation for setup and verification guidance while configuring your sending domain.
3) Ensure you have observability (logs and events)
Warm-up needs fast feedback. You want visibility into accepted, deferred, and bounced outcomes, plus event visibility when possible. MailCub includes logs and analytics in the documentation and supports event tracking on the Transactional Email page through webhooks and real-time events.
Step-by-step Warm-up Plan
1) Start with low-risk message types
Begin with essential transactional flows such as verification, password reset, security alerts, and receipts. Avoid promotional-style content during the early warm-up phase.
2) Pick the first cohort: engaged recipients first
Even for transactional mail, start with users who recently interacted with your product and are less likely to mark messages as spam. The provided content notes this as a recommended warm-up practice because positive engagement supports reputation signals.
3) Use a day-by-day ramp schedule (baseline)
If your domain is truly new and has no recent traffic, start small and ramp in predictable stages. The provided content also notes an important rule: do not send more than double the previous stage/day.
| Day | Daily message cap (baseline) | Notes |
|---|---|---|
| 1 | 100 | internal + most engaged |
| 2 | 200 | same cohort |
| 3 | 350 | expand slightly |
| 4 | 500 | keep steady |
| 5 | 750 | keep steady |
| 6 | 1,000 | only if metrics are stable |
| 7 | 1,500 | expand carefully |
| 8 | 2,000 | monitor closely |
| 9 | 3,000 | monitor closely |
| 10 | 5,000 | only if stable |
| 11 | 8,000 | keep consistent |
| 12 | 15,000 | slow down if needed |
| 13 | 25,000 | only if stable |
| 14 | 50,000 | only if you truly send this daily |
Stop increasing once you reach your normal daily volume. There is no benefit to warming above what you usually send.
4) Monitor daily stop signals
Track these every day during warm-up:
- Spam complaint rate: target below 0.1% and avoid 0.3%.
- Hard bounces: remove invalid addresses quickly.
- Deferrals and throttling: slow down and spread sends across more hours if temporary failures increase.
The provided content also notes a practical response when deferrals are high: reduce volume (often around 20–30%), stabilize, and only then increase again.
5) Add a controlled sending pipeline (queue + backoff)
Use a queue and rate limits so traffic spikes do not break your warm-up plan. If you send through MailCub, use the documented API endpoint and auth method as the single source of truth:
- POST https://api.mail.mailcub.com/api/send_email
- Header: x-sh-key: YOUR_API_KEY
Use MailCub Documentation to add rate-limited sending and error handling, and review the Transactional Email page for product capabilities like logs, analytics, and event support.
Common Mistakes
- Jumping volume too fast instead of following a staged ramp (especially above 2×).
- Warming with low-quality or cold recipients, which increases complaint risk early.
- Ignoring spam-rate thresholds during ramp-up.
- Changing From domains or templates frequently during warm-up.
- Not using logs and events, so delayed, bounced, or blocked messages are hard to explain.
Troubleshooting
Problem: Gmail spam complaints rise during warm-up
- Pause growth and hold or reduce daily volume.
- Return to your most engaged cohort for a few days.
- Verify complaint-rate thresholds and aim below 0.1%.
- Re-check SPF, DKIM, and DMARC alignment.
Problem: Outlook throttling or junk placement increases
- Confirm SPF, DKIM, and DMARC are configured correctly.
- Smooth sending and avoid bursts.
- If you are over 5,000/day to Outlook consumer domains, treat Microsoft requirements as mandatory.
Problem: API requests fail during warm-up (MailCub)
The provided content notes common MailCub status codes during setup and ramping:
- 401: invalid API key
- 403: domain not verified
- 404: domain not found or not associated
- 429: rate limit or quota
Use MailCub Documentation to validate authentication, domain verification, and request handling before increasing volume.
FAQ
How long does it take to warm up a new sending domain?
It often takes 2–4 weeks, depending on your target daily volume and whether your metrics stay stable.
What spam complaint rate is safe during warm-up?
The provided content notes Google guidance to keep spam rate below 0.1% and prevent it from reaching 0.3% or higher.
Do I need DMARC to start warming up?
You can start with SPF and DKIM, then add DMARC once alignment is correct and you are ready for stronger enforcement.
Should I warm up to 50,000/day if I only send 2,000/day?
No. Warm up to your normal daily volume and stabilize there.
What should I do if I see deferrals or throttling?
Slow down, spread sending across more hours, and reduce daily volume until deferrals drop.
Why start with engaged recipients?
The provided content notes that engaged cohorts are recommended early because positive interaction supports reputation signals, especially with Gmail.
Conclusion
Domain warm-up works best when it is predictable: authenticate correctly, start small, ramp in stages, and let complaint rate and deferrals control the pace. If metrics worsen, slow down and stabilize instead of pushing through.
Use MailCub Documentation to implement verified sending, logs, and event visibility so your team can ramp safely and debug issues faster. If you want to start quickly, you can also use the Transactional Email service for developer-friendly API sending, logs and analytics, webhooks and events, and a free trial and pricing options, including optional dedicated IP or dedicated server choices mentioned in your provided USPs.