Skip to main content

Dedicated IP Strategy for Postchi

Executive Summary

YES, you should absolutely dedicate an IP for the Postchi brand (system emails) and keep it separate from customer IPs.

Why Dedicated Brand IP?

1. Reputation Protection

  • Customer mistakes won't affect your system emails
  • If a customer sends spam, it won't damage Postchi's ability to send password resets
  • System emails maintain high deliverability regardless of customer behavior

2. Deliverability Reliability

  • Gmail, Outlook, Yahoo track sender reputation by IP
  • Critical system emails (password resets, verifications) need 99.9%+ deliverability
  • One bad customer can tank IP reputation for weeks

3. Brand Trust

  • Emails from @postchi.io should always land in inbox
  • Consistent IP = consistent reputation = inbox placement
  • Professional image: "We take email seriously"

4. Regulatory Compliance

  • System emails are transactional (CAN-SPAM exempt)
  • Customer emails may be marketing (subject to CAN-SPAM)
  • Separate IPs = clear audit trail

5. Monitoring & Troubleshooting

  • Easy to identify if system IP has issues
  • Can monitor customer IPs independently
  • Faster incident response

Tier 1: Postchi Brand IP (1 dedicated IP)

Purpose: System/transactional emails only

  • Password resets
  • Email verification
  • Account notifications
  • Billing emails
  • Security alerts

Characteristics:

  • Very low volume (predictable)
  • 100% legitimate traffic
  • Strict sending policies
  • Monitor 24/7

Tier 2: Customer Shared IP Pool (Start with 2-3 IPs)

Purpose: Customer email sending

  • Marketing campaigns
  • Transactional customer emails
  • Newsletters
  • Notifications

Characteristics:

  • Higher volume
  • Variable quality
  • Requires reputation management
  • Scale as customer base grows

Tier 3: High-Volume Customer Dedicated IPs (Future)

Purpose: Enterprise customers with high volume

  • Customers sending 100K+ emails/month
  • White-label customers
  • Customers who want dedicated IP

IP Warming Schedule

Brand IP (postchi.io)

Since this is low-volume system emails, warming is simpler:

Week 1: 50 emails/day Week 2: 100 emails/day Week 3: 200 emails/day Week 4+: Full volume (likely still low)

Tip: You can accelerate by having team members trigger password resets, sign-ups, etc.

Customer Shared Pool IPs

More aggressive warming needed:

Week 1: 200 emails/day per IP Week 2: 500 emails/day per IP Week 3: 1,000 emails/day per IP Week 4: 2,500 emails/day per IP Week 5: 5,000 emails/day per IP Week 6: 10,000 emails/day per IP Week 7+: Full volume

IP Allocation Architecture

┌─────────────────────────────────────────────┐
│ Postchi Email Infrastructure │
├─────────────────────────────────────────────┤
│ │
│ Brand IP: 203.0.113.10 │
│ ├─ noreply@postchi.io │
│ ├─ security@postchi.io │
│ └─ support@postchi.io │
│ │
│ Customer Pool IPs: │
│ ├─ IP 1: 203.0.113.20 (Customers A-M) │
│ ├─ IP 2: 203.0.113.21 (Customers N-Z) │
│ └─ IP 3: 203.0.113.22 (Overflow/Testing) │
│ │
│ Enterprise Dedicated IPs: │
│ ├─ IP X: Customer ABC Corp │
│ └─ IP Y: Customer XYZ Inc │
│ │
└─────────────────────────────────────────────┘

DNS Configuration

For Brand IP (203.0.113.10)

# SPF Record
postchi.io. IN TXT "v=spf1 ip4:203.0.113.10 -all"

# DKIM Record (use the generated key from script)
default._domainkey.postchi.io. IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"

# DMARC Record
_dmarc.postchi.io. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@postchi.io; ruf=mailto:dmarc@postchi.io; pct=100; adkim=s; aspf=s"

# MX Records (for bounce handling)
postchi.io. IN MX 10 s1.mx.postchi.io.
postchi.io. IN MX 20 s2.mx.postchi.io.

# A Record (if needed)
postchi.io. IN A 203.0.113.10

Note: For brand IP, use strict DKIM/SPF alignment (adkim=s; aspf=s) instead of relaxed.

For Customer IPs

Customer domains will have their own DNS records with their assigned pool IP.

Monitoring Strategy

Brand IP Monitoring (Critical)

  • Uptime: 99.99% SLA
  • Deliverability: Alert if <99% inbox rate
  • Reputation: Daily checks on:
    • Google Postmaster Tools
    • Microsoft SNDS
    • Spamhaus
    • Barracuda
  • Bounce Rate: Alert if >2%
  • Complaint Rate: Alert if >0.1%

Customer IP Monitoring

  • Uptime: 99.9% SLA
  • Deliverability: Alert if <95% inbox rate
  • Reputation: Weekly checks
  • Bounce Rate: Alert if >5%
  • Complaint Rate: Alert if >0.5%
  • Automatic quarantine: If customer IP gets blacklisted

Cost Considerations

IP Costs (AWS/Digital Ocean example)

  • Dedicated IP: $3-5/month
  • Elastic IP: Free if attached, $3.60/month if idle

Brand IP (1): ~$5/month

Worth it? Absolutely. This protects your business.

Customer Pool (3): ~$15/month

Worth it? Yes. Room to grow and isolate problems.

Total: ~$20/month

ROI: Priceless for reputation protection

Implementation Checklist

  • Provision dedicated IP for postchi.io brand
  • Configure reverse DNS (PTR record) for brand IP
  • Set up DKIM keys for postchi.io (use generated keys)
  • Configure SPF with strict IP (only brand IP)
  • Set up DMARC with quarantine policy
  • Add MX records for bounce handling
  • Start IP warming (50 emails/day)
  • Set up monitoring (Google Postmaster, etc.)
  • Configure separate SMTP connection pool for brand IP
  • Update password-reset service to use brand domain/IP ✅
  • Provision 2-3 IPs for customer pool
  • Implement customer IP assignment logic
  • Set up customer IP warming schedule
  • Create IP reputation dashboard

Best Practices

Do's:

✅ Use dedicated brand IP only for system emails ✅ Monitor brand IP reputation daily ✅ Keep volume consistent (avoid spikes) ✅ Warm up IPs properly ✅ Set up feedback loops with ISPs ✅ Monitor bounce/complaint rates

Don'ts:

❌ Don't mix customer emails with brand IP ❌ Don't share brand IP across environments (dev/prod) ❌ Don't skip IP warming ❌ Don't ignore blacklist alerts ❌ Don't use shared IPs for high-value customers

Conclusion

Dedicating an IP for the Postchi brand is not just recommended—it's essential for a professional email service platform. The cost is minimal (~$5/month) compared to the risk of losing the ability to send critical system emails.

Next Steps:

  1. Provision brand IP
  2. Configure DNS records (use generated DKIM keys)
  3. Start IP warming with test emails
  4. Begin production use after 2-week warm-up