Email Deliverability Basics: SPF, DKIM, DMARC and Warmup

Email deliverability is whether your message reaches the inbox — not whether the receiving server accepted it. The second thing is delivery, and almost every sending tool reports it as ‘delivered’. A message sorted straight into the spam folder counts as delivered. That gap is where senders lose months.

Mailbox providers decide placement per message using signals in three groups. Identity: can they prove who sent this? Reputation: how have recipients reacted to mail from this domain and this IP before? Content: does the message look like mail people complained about? Identity is settled by SPF, DKIM and DMARC and is entirely under your control. Reputation is earned slowly and lost quickly. Content matters least, which is why rewriting subject lines rarely fixes a placement problem.

The practical consequence: fix authentication first, because it is an afternoon of work with a permanent payoff, then treat everything after that as reputation management. There is no header, record or setting that makes mail to a bad list land in the inbox.

SPF is a TXT record on your domain listing the servers permitted to send mail using it. A minimal record looks like v=spf1 include:_spf.your-provider.example ~all. The receiving server takes the envelope sender — the Return-Path, not the visible From address — reads that domain’s SPF record, and checks whether the connecting IP is authorised.

Three details cause most SPF failures:

• The ten-lookup limit. Every include, a, mx and redirect costs a DNS lookup, and nested includes count too. Exceed ten and the record returns a permanent error, which receivers may treat as a failure. Re-check it every time you add a tool.
• One record only. Two SPF TXT records on the same domain is an error, not a merge. Combine them into one.
• ~all versus -all. Softfail marks unauthorised mail; hardfail asks receivers to reject it. Move to -all only once you are certain every legitimate sender is listed.

SPF breaks on forwarding, because the forwarding server’s IP is not in your record. That is not a bug you can fix, and it is precisely why DKIM exists and why DMARC accepts a pass from either mechanism.

DKIM adds a cryptographic signature to the message headers. You publish a public key as a TXT record at selector._domainkey.yourdomain.com; your sending platform holds the private key and signs each message. The receiver fetches the public key, verifies the signature, and now knows the message was authorised by the domain in the d= tag and was not altered in transit.

Practical points:

• Use a 2048-bit key where your DNS host supports it. 1024-bit still verifies, but it is the weaker option.
• Give each sending platform its own selector, so you can rotate or remove one without touching the others.
• The signing domain in d= should match your From domain, or DMARC alignment fails even though DKIM itself passed.
• Rotate keys periodically, and delete selectors for tools you have stopped using — an unused key is a standing invitation.

Because the signature travels with the message, DKIM survives simple forwarding where SPF does not. If you were only going to configure one of the two, DKIM would be the more valuable. Configure both anyway: receivers weigh them differently, and DMARC is far more robust when either can carry the alignment.

DMARC ties SPF and DKIM to the address the reader actually sees. A message passes DMARC when SPF or DKIM passes and the domain that authenticated matches the From domain. That match is called alignment, and it is the part people miss: a message can pass SPF perfectly on a provider’s domain and still fail DMARC because the From header says something else.

The record is a TXT entry at _dmarc.yourdomain.com, for example v=DMARC1; p=none; rua=mailto:[email protected]. The policy tag tells receivers what to do with failures:

• p=none — monitor only. Start here, so you can see who is sending as you.
• p=quarantine — failures go to spam. Move here once the reports are clean.
• p=reject — failures are refused outright. The goal state, and the one that stops others spoofing your domain.

The aggregate reports arriving at your rua address are XML and unpleasant to read raw; any DMARC report parser will do. Read them for a few weeks before tightening policy. Google’s and Yahoo’s published requirements for bulk senders now expect a DMARC record, aligned authentication, one-click unsubscribe and low complaint rates, so none of this is optional housekeeping once you send at volume.

A new domain has no reputation, and mailbox providers treat no reputation with suspicion. Warmup builds a sending history: start at a handful of messages per mailbox per day, increase gradually over two to four weeks, and make sure a meaningful share of that early mail is opened and replied to.

What warmup does is establish that this domain sends mail people engage with. What it cannot do is repair a bad list, absorb a high bounce rate, or offset spam complaints. Warm a domain carefully, then send it a stale purchased list, and you have simply warmed your way to a faster burn.

Practical rules:

• Authenticate before warming, not after. Unauthenticated mail during warmup teaches receivers the wrong lesson.
• Do not multiply volume the day warmup ends. Step it up week over week.
• Spread real campaign volume across several mailboxes rather than pushing one hard.
• Watch inbox placement during the ramp, and pause the ramp when it slips instead of pushing through.

Growmindr’s outreach and marketing automation module handles warmup, per-domain throttling and sending windows alongside the sequences themselves, which mainly helps by keeping the volume ramp and the campaign schedule from fighting each other.

A hard bounce is a permanent rejection: the mailbox does not exist, or the domain does not accept mail at all. A soft bounce is temporary — mailbox full, server busy, greylisting — and worth a few retries before you give up on it.

Hard bounces are the ones that hurt. They tell the receiving provider that you do not know who is on your list, which is the defining characteristic of a spammer. Any address that hard bounces should be suppressed permanently and immediately, everywhere, and never retried.

Keep the hard bounce rate in the low single digits at worst, and treat anything above that as a stop-and-fix signal rather than a metric to observe. The fix is almost never in the sending setup; it is in the list. Verify every address before it enters a sequence, re-verify lists older than a few months, and keep role addresses such as info@, sales@ and support@ out of cold campaigns, since they bounce more often and complain more when they do not.

Read the pattern as well as the rate. Bounces concentrated on one recipient domain usually mean that domain is blocking you, not that those addresses are invalid — a different problem with a different fix.

A spam complaint is the strongest negative signal a recipient can send, providers weigh it heavily, and they act on it fast. Complaint rates are measured in fractions of a percent, so the tolerance is far tighter than most senders assume — Google’s and Yahoo’s published bulk-sender requirements both set the acceptable rate well below one percent and expect senders to stay comfortably under the limit rather than near it.

You cannot see complaints at every provider, but you can see some. Register for feedback loops where they are offered, use Google Postmaster Tools to watch domain reputation and spam rate for Gmail traffic, and treat any upward movement as urgent rather than interesting.

Positive engagement counts too, which is why relevance beats volume. Replies are the strongest positive signal, followed by messages moved out of spam, starred or filed. Deletion without opening is mildly negative. A long stretch of no engagement from a recipient is a reason to stop mailing them, not a reason to try a fifth time.

So prune non-engagers on a schedule. A list that keeps only people who interacted in the last few months will outperform a list three times its size, on both placement and replies.

Deliverability decays quietly. Something changes — a new tool starts sending as you, a DNS edit drops a record, one campaign attracts complaints — and nothing announces it. Half an hour a month catches almost all of it.

• Authentication — SPF resolves within ten lookups and exists once; DKIM verifies for every active sending platform; the DMARC record is present at the policy you intended.
• DMARC reports — any new source sending as your domain? Any legitimate source failing alignment?
• Reverse DNS — the sending IP’s PTR record resolves to a hostname that resolves back to it.
• Blocklists — check your sending domains and IPs against the major public lists.
• Bounce and complaint trend — direction matters more than any single month’s number.
• Seed test — send a real campaign message to your own accounts at the major providers and note where it lands.
• Unsubscribe — the one-click header is present on bulk mail, and opt-outs are genuinely suppressed across every campaign.

Write the result down each month. One month of figures tells you almost nothing; six months of the same figures tells you exactly when the problem started, which is usually most of the diagnosis.