MAILBOX SIGNALS · FIELD NOTE 01
Soft bounces are a signal, not a single diagnosis.
A soft bounce describes a temporary failure, but the reason behind it determines whether you should retry, slow down, or investigate a broader sender issue.
01 / ReadUse the SMTP response
Mailbox-full messages, rate limits, and policy responses do not mean the same thing. Preserve the raw reason in your post-send review.
02 / SegmentCompare by provider
Check whether the issue is isolated to Gmail, Microsoft, or another mailbox family before reacting to the overall rate.
03 / RespondMatch the action
Retry temporary failures, suppress invalid addresses, and slow volume when policy or reputation signals grow.
Good operating ruleDo not convert every soft bounce into a permanent suppression. Use the category and repeated behavior to determine treatment.
WARMING · FIELD NOTE 02
Why an aggressive ramp is not always a faster ramp.
A sending ramp is useful because it creates observable evidence. Going faster than the signals support can trade a short-term volume gain for a longer recovery.
Start by separating the audience into the mailbox providers that actually matter. A single daily target masks the fact that each provider can react differently to a new domain, IP, or content pattern. Establish a provider-level starting volume, choose a multiplier, then retain enough unsent audience to revise the schedule if the signals change.
Use actual sends as the new baselineOnce a few days have completed, replace planned values with the volume that actually went out. The next day’s ramp should build from the real last send, not the original forecast.
When content is repeated, make the eligible audience explicit. A campaign target is only realistic when enough recipients are eligible for the campaign content after accounting for prior sends and required spacing.
AUTHENTICATION · FIELD NOTE 03
SPF lookup count: the small limit with big consequences.
SPF evaluation has a DNS-lookup limit. A record can look simple on its own while nested include: and redirect= mechanisms push it over the limit.
Start with the direct policy, then identify mechanisms that can cause a DNS lookup: include, redirect, a, mx, exists, and ptr. The direct count is only a first pass; included records can add more mechanisms underneath.
01 / InspectFind the actual record
Check the exact envelope-from domain. Do not assume the visible From domain is the SPF domain.
02 / CountFollow includes
Document the paths before removing providers or changing policy terms.
03 / SimplifyReduce dependency layers
Consolidate where practical and retest after each change.
Remember DMARC alignmentSPF can pass while DMARC still fails alignment. Check SPF, DKIM, and the DMARC policy together.
OPERATIONS · FIELD NOTE 04
Keep delivery evidence attached to message identity.
Campaign names help people read an export. UUIDs make the relationship between a delivery signal and the actual send durable.
Keep campaign, trigger, and experiment identifiers in your engagement export. When a bounce or complaint pattern changes, these values let you distinguish a list issue from a template, trigger, or experiment change. They also make it easier to compare different audience treatments without guessing which send generated an event.
Useful review questionFor a provider-level issue, can you identify the campaign, trigger, experiment, and template involved before you change the ramp?