You have an empty campaign, a strong offer, and forty minutes before lunch. The tempting move is to start polishing the subject line. The useful move is to close the composer and inspect the machinery first.
A clever email cannot repair a sender domain that is not authenticated. A beautiful design cannot turn an old spreadsheet into a permissioned audience. If recent sends produced hard bounces or spam complaints, adding better adjectives will not solve the problem.
Inbox placement begins with the sender, audience, and exit path. Copy comes after those parts are sound.
Separate sending, delivery, and placement
These terms describe different events. A sending system can accept a campaign job. The recipient's mail server can then accept a message. The mailbox provider can still place that accepted message in spam, a promotions category, another tab, or the main inbox.
Amazon SES defines a delivery event as the recipient's mail server accepting the message. That event does not prove the person saw it, read it, or found it in a preferred folder. SES records bounces and complaints as separate events, which is why a green delivery total cannot stand in for the health of an email program. AWS's guide to monitoring SES sending activity explains those event types and what they mean.
Inbox placement is also not one universal score. Each provider evaluates mail with its own systems, and a recipient's choices matter. A person who asked for a weekly workshop notice is sending a different signal from someone who forgot why a business has their address.
Read the numbers separately:
A send count tells you how much mail entered the system.
A delivery count tells you what recipient servers accepted.
A bounce tells you a delivery failed, either permanently or after retry handling.
A complaint tells you a recipient marked an accepted message as spam.
A click or reply can show a useful action, but neither guarantees future placement.
This separation keeps diagnosis honest. If delivery falls, inspect technical failures and list quality. If complaints appear, inspect permission, sender recognition, cadence, and content. If delivered mail gets few useful actions, inspect relevance and the offer before blaming a filter.
Check the identity before the prose
Start with the domain in the visible From address. Is it a domain the business controls? Will a subscriber recognize the From name? Does the sending platform show that the identity is verified and authenticated?
Google currently requires every sender to personal Gmail accounts to use SPF or DKIM. Senders over Google's bulk threshold face added requirements, including SPF, DKIM, DMARC, and alignment. Google's current email sender guidelines list the requirements and should be checked again before a large send because provider rules can change.
Yahoo likewise requires at least SPF or DKIM for all senders covered by its guidance, with both plus DMARC for bulk senders. It also ties delivery to complaint control, valid DNS, relevant mail, and an active audience. Yahoo's sender requirements and recommendations put those pieces together.
Do not treat a check mark beside a From address as proof that every authentication method is correct. Verification proves some level of control. SPF, DKIM, and DMARC answer related but different questions during delivery. Review the actual authentication results in a test message, or ask the person who manages the sending domain to do it.
A good preflight note is plain:
From: Fern Street Repairs
<service@fernstreetrepairs.com>\ Domain control: verified\ SPF: pass in test mailbox\ DKIM: pass in test mailbox\ DMARC: pass with aligned DKIM\ Reply address: monitored by Mia
If the team cannot fill in that note, it is not ready to debate whether the subject needs an emoji.
Trace every address back to a real action
Next, take a sample of the audience and answer one question for each row: what did this person do that made this message expected?
Useful answers are specific. They joined the Saturday produce notice on the shop's form. They checked a marketing box while booking. They asked for the monthly studio schedule. They are an active customer who agreed to receive a defined class of updates under the rules that apply to the business.
Weak answers sound like archaeology. The address was somewhere in the old point-of-sale export. Someone collected the card at a conference. The owner knows the person. The list came with the business. None of those statements explains permission for this campaign.
AWS recommends building lists through explicit signup practices, validating form input, and keeping list data current. It warns that poor list practices contribute to bounces and complaints, which can damage sender reputation. AWS's sender-reputation guidance is written for SES users, but the operating lesson applies to any sender: know how addresses arrived and remove bad ones.
If the audience mixes several sources, label them before sending. A short source column such as website form, May workshop, or customer marketing consent is more useful than one giant list named EVERYONE_FINAL_4.
Pause when a source cannot be explained. A smaller list of people who expect the message is more useful than a large list padded with doubt.
Read negative signals before adding volume
Review the last few sends from the same domain and the same audience source. Look for hard bounces, repeated delivery failures, complaints, and a sudden change in volume. Do not wait for an account warning to start paying attention.
Amazon SES tracks bounce and complaint rates because high rates can harm sender reputation and can lead AWS to review or pause an account's sending ability. AWS's reputation monitoring documentation describes those signals without promising a safe universal rate for every mailbox provider.
Avoid inventing your own green zone from a blog post or a screenshot. Provider enforcement, traffic mix, and measurement methods differ. Use published requirements where they exist, then treat any complaint as a reason to inspect the message and acquisition source.
Ask four questions after a negative event:
Was the address typed incorrectly, old, or imported from a weak source?
Did the recipient recognize the sender name and domain?
Did the message match what the signup promised?
Could the person leave without hunting, logging in, or solving a puzzle?
Thunk Mail's architecture records SES delivery, bounce, and complaint events through SNS, then updates campaign data through a webhook flow. It also documents suppression and unsubscribe paths. The Thunk Mail architecture guide shows the product flow. Those events still need a human decision. A dashboard can reveal a complaint; it cannot repair a vague signup promise.
Make the campaign match the signup
Now the writing matters. The first screen of the email should help a recipient answer three quiet questions: who is this, why am I receiving it, and what can I do next?
Suppose a repair shop collected addresses for a monthly maintenance note. A campaign titled Last chance: buy our partner's insurance today breaks that expectation even if the offer is legitimate. The list did not grant a general license to send anything that might make money.
A matching message might begin:
You asked for Fern Street Repairs' monthly maintenance note. This month: a two-minute check for the hose that most often leaks behind a washing machine.
That sentence is not magic deliverability copy. It simply makes the source and value recognizable. The body should then do the promised job. If the business wants to introduce a new type of mail, explain the change and give the reader a real choice.
Keep the visible unsubscribe link readable. Google requires a clearly visible body link for relevant bulk marketing mail in addition to its one-click header requirement, and Yahoo also requires a clear body link for bulk senders. Their guidance is a floor for affected senders, not a reason smaller senders should hide the exit.
Run a ten-minute prewriting check
Before opening the composer, write down the answers to this short preflight:
Which verified From identity will send the campaign?
Did SPF, DKIM, and DMARC produce the expected results in a recent test?
How did every segment get permission for this specific type of message?
Which permanent failures and prior opt-outs are suppressed?
Did recent sends produce bounces or complaints that need investigation?
Does the campaign match the promise, sender name, and cadence people saw at signup?
Can a person unsubscribe through both the visible path and any provider-required header path?
Who will watch replies and negative events after the send?
If one answer is missing, fix it before writing. If all eight are clear, the blank page becomes much easier. You know who is speaking, who should receive the message, what they expect, and how they can leave. That is a better start than a folder full of subject-line formulas.