What actually decides whether you reach the inbox
Most deliverability advice stops at "set up SPF and DKIM". That is the entry ticket, not the outcome. Here is what each record does and what decides placement once they pass.
8 min read · Written by the Autocloz team
The three records, and what each one proves
- SPF lists which servers are allowed to send for your domain. It answers: did this come from an authorised machine?
- DKIM signs the message cryptographically. It answers: was this message altered in transit, and does the signing domain match?
- DMARC ties the two together and tells receivers what to do when they fail — nothing, quarantine, or reject. It also turns on reporting.
All three are DNS records. None of them make your email interesting, and none of them will rescue a message that recipients mark as spam.
Why DMARC policy matters more than people expect
A DMARC record set to p=none passes technical checks while asking receivers to take no action on failures. It is the correct starting position because it gives you reporting without risk, but staying there indefinitely leaves your domain spoofable.
Google and Yahoo now require DMARC for bulk senders, and the direction of travel is clear: unauthenticated mail is being squeezed out. Move to p=quarantine once your reports show legitimate sources passing consistently.
Set DMARC to p=none first and read the reports for two weeks. Going straight to p=reject before you know every legitimate sender will silently kill your own invoices and notifications.
What decides placement once authentication passes
Authentication gets you considered. Engagement decides where you land. The signals that move placement, roughly in order of weight:
- Spam complaints. The most damaging signal by a wide margin. Above 0.3% and you are in trouble.
- Replies. The strongest positive signal, and the hardest to fake.
- Bounces. High hard-bounce rates suggest scraped or stale lists.
- Deletion without opening. Weakly negative, and it accumulates.
- Consistency of volume. Spiky sending patterns read as compromise.
Seed testing, and its limits
A seed test sends a copy of your campaign to a set of monitored mailboxes across providers and reports where it landed. It is genuinely useful for catching a content or authentication problem before a send.
It is less useful as an ongoing score. Seed accounts have no engagement history and no relationship with your domain, so they do not reflect how your actual recipients are treated. Use seed tests to catch breakage, not to certify health.
Practical checklist before any campaign
- SPF, DKIM and DMARC all present and passing, verified with a real test send.
- Separate sending domain, not your primary.
- List verified for deliverable addresses; anything older than 90 days re-verified.
- A visible, working unsubscribe in every message.
- Volume inside the mailbox ramp.
- Plain text or very light HTML. Heavy templates and tracking-image bloat both hurt.
Common questions
Does adding a tracking pixel hurt deliverability?
Mildly, and it varies by provider. Open tracking requires a remote image, which some filters weight negatively. Reply rate is a better success metric anyway.
Are link shorteners a problem?
Yes. Public shorteners are heavily abused and frequently blocklisted. Use a branded tracking domain instead.
How often should I check deliverability?
Monitor complaint and bounce rates continuously; they move fastest. Re-run a seed test whenever you change templates, domains or sending volume materially.
My open rate collapsed overnight. What happened?
Usually one of three things: a DNS change broke authentication, volume stepped up too fast, or a batch of bad addresses drove complaints. Check authentication first, it is the quickest to rule out.
Autocloz checks all of it before every send
The compliance gate runs six pre-flight checks, including authentication, on every touch.