You build an application, set up email, and test it. Everything works. Then somebody tells you they never got the code. You check your logs and the message says **Delivered**. You ask them to look in spam, and there it is.
Delivered does not mean inbox
This is where most of the confusion starts. When your provider says Delivered, it means the recipient's mail server accepted the message - it returned a 250 and took responsibility for it. What happens next is a separate decision, made by filters that report nothing back to you. The same message can be accepted and then put in the inbox, in Promotions, or in spam, and your log says Delivered for all three.
Swipe the diagram to see the rest
1. Your domain has no reputation yet, or a damaged one
Every sending domain carries a history, in the way a credit file does. A new domain has none, so there is nothing to vouch for it. A domain people have reported before carries that too.
The fastest way to damage a new one is a sudden change in shape: twenty messages a day for a month, then twenty thousand in an afternoon. Receiving servers read that as a list somebody has just acquired, because that is usually what it is.
Swipe the diagram to see the rest
Grow volume with real demand, watch your bounces and complaints as you go, and do not send the first large campaign from a domain that has never sent anything.
2. SPF, DKIM or DMARC is failing
Anyone can type support@yourcompany.com into a From field. These three records are how a receiving server tells your mail from somebody impersonating you.
- **SPF** names the servers allowed to send for your domain.
- **DKIM** signs the message, so the receiver can check it was not altered and came from you.
- **DMARC** ties the two to the address the recipient actually sees, and says what to do when they disagree.
Swipe the diagram to see the rest
Send yourself a message, open it in Gmail, and choose **Show original** from the three-dot menu. SPF, DKIM and DMARC each show pass or fail at the top. If one fails, the problem is in your DNS and nowhere else - fix it before you change anything about the mail itself. SPF, DKIM and DMARC explained covers what each record should contain.
3. Recipients are reporting it
This weighs more than most of the other signals combined, and the numbers are smaller than people expect. Google asks senders to stay below a 0.1% user-reported spam rate and never to reach 0.3%.
Swipe the diagram to see the rest
Three complaints in a thousand delivered messages is the line. On a list of people who asked to hear from you, that is hard to hit. On a list of people who did not, it is a matter of time.
- Send marketing mail only to people who asked for it.
- Make unsubscribing one click, and honour it immediately.
- Stop mailing addresses that bounce - see handling bounces.
- Do not dress a promotion as an account notice. That is what the report button is for.
And keep codes and password resets to the task. A sales paragraph under an OTP turns a message nobody would report into one somebody might.
4. The message does not look like something anyone asked for
There is no secret list of forbidden words. Filters weigh the sender, the links, the domain's history and the content together, and a genuine security alert sometimes has to say urgent.
What moves the needle is whether the message looks like what it claims to be: a sender name the recipient recognises, a subject that matches the body, links to your own domain rather than a chain of redirects, and no attachment that did not need to be there. A plain password-reset email is usually the whole design.
5. The sending IP has a reputation of its own
Your domain is not the only thing being judged. The server the mail leaves from is judged too, and on shared infrastructure other senders' behaviour is part of that picture. This is not an argument against shared IPs - it is an argument for a provider that polices them, suppresses bounces automatically, and acts on abuse rather than waiting for a blocklist to act first.
What to check first
| Step | What to look at | What it tells you |
|---|---|---|
| 1 | Show original on a received message | Whether SPF, DKIM and DMARC pass |
| 2 | Your delivery logs | Accepted, deferred, bounced - and the exact SMTP code |
| 3 | Google Postmaster Tools | Your complaint rate and domain reputation at Gmail |
| 4 | The message itself | Sender name, subject, links, attachments |
| 5 | Your sending pattern | A volume spike, or old addresses being mailed again |
| 6 | A second provider | Whether it is every inbox or only one |
Then wait. Fixing a DNS record does not reset a reputation; it only stops it getting worse. Stop whatever caused the complaints, correct the technical faults, and watch the numbers over days rather than minutes.
Will changing provider fix it?
Sometimes - if the current one has an authentication or infrastructure problem you cannot see or correct. But a new provider does not repair a domain's reputation and does not make unwanted mail welcome. You still need the records right, a list of people who asked, and enough visibility to see what failed and why.
That visibility is what Sendpository is built around: domain verification with DKIM signing, a log of every message and what happened to it, webhooks for delivery events, and automatic suppression of bounced and complained addresses so a dead address is never mailed twice. The free plan is 6,000 emails a month.
The three questions
Before rewriting subject lines or switching providers, answer these: is the mail authenticated, did the recipient ask for it, and what do the logs and reputation signals actually say? Those get you closer than any amount of rewording.