How we automated dedicated-IP warm-up without overloading reputation
An engineering writeup of PulsePigeon's dedicated-IP warm-up automation: per-IP stage state, reputation gates, bounded evaluation, and fail-closed rollout controls.
Blog
Email infrastructure blog, page 2
Read guides to deliverability, authentication, SMTP, and email infrastructure.
Sending transactional email from a Node.js app with PulsePigeon
Wire a PulsePigeon send into a Node.js HTTP handler or a BullMQ worker. Idempotency keys, error handling, and a typed error model.
Sending transactional email from a Python app with PulsePigeon
The Python SDK pattern: synchronous and asynchronous clients, deterministic idempotency keys, status-specific errors, and application-owned retries.
Planning a transactional email send from FastAPI
Conceptual guidance for server-side sends from FastAPI, including idempotency, response handling, and when a durable worker is safer than BackgroundTasks.
Send transactional email from Next.js with the REST API
A server-only Next.js REST example for order receipts, with stable idempotency, accepted message IDs, error handling, and delivery-event follow-up.
SMTP 421 — transient failure retry strategy
A 421 response is a temporary failure: the receiving server is asking you to retry later. The right retry policy protects your sender reputation and your recipients' patience.
SMTP 550 — permanent failure codes and what to do with each
A 550 response means the mailbox rejected the message and is asking you not to retry. Decode the common sub-codes and the right operational response for each.
SMTP relay, explained — and why free public relays are not safe for production
What an SMTP relay does, how it differs from a transactional email API, and why the free public SMTP relays that come up in search results are a reputation risk you cannot afford.
SPF too many DNS lookups: diagnose and fix the limit
The SPF 10-lookup limit is one of the most common authentication failures. What causes it, what the error looks like, and the practical fixes that don't break your existing email flow.
Designing idempotent sends with the PulsePigeon email API
How to use idempotency keys when sending transactional email so retries after a timeout never result in a duplicate message reaching a customer.
Warming up a new sending domain without losing deliverability
A practical warm-up schedule for a new sending domain: volume ramps, engagement signals, and the authentication records to land in the inbox instead of spam.