deliverability
Why Your Email Went to Spam
SPF, DKIM and DMARC decide whether a mailbox provider believes you are you. Everything after that is reputation, and reputation is complaint rate.
Delivery is two questions asked in order. Are you who you say you are, and do people want what you send?
The first is answered by three DNS records and is entirely under your control. The second is answered by recipient behaviour and is not, which is why the first one is the part worth getting perfect.
Authentication, in three records
SPF, RFC 7208, is a DNS record listing which servers may send mail for your domain. The receiving server checks the sending IP against it.
The failure mode specific to SPF is the lookup limit: the specification caps the number of DNS lookups performed during evaluation at ten, and a record that includes several vendors exceeds it. Over the limit, the result is a permanent error rather than a pass, and the symptom is intermittent delivery failure that correlates with nothing obvious. If you have added a mail vendor more than twice, check the count.
DKIM, RFC 6376, signs the message with a private key and publishes the public key in DNS. The signature survives forwarding, which SPF does not, and that makes it the stronger of the two.
The failure mode is key length and rotation: a short key is weak, and a key that has never been rotated has usually also never been tested.
DMARC, RFC 7489, ties the other two to the domain the recipient actually sees, and tells receivers what to do when a message fails. It also produces aggregate reports, which are the only direct feedback most senders ever get about who is sending as them.
The three combine into one claim: this message is from the domain it says it is from. Without them you are asking a mailbox provider to take an unverified stranger's word on a Tuesday morning.
The bulk sender requirements
In 2024 the major consumer mailbox providers published requirements for senders above a volume threshold, and they moved several things from best practice to condition of delivery.
Authenticate with SPF and DKIM, and publish a DMARC record. Align the visible from domain with the authenticated domain. Provide one-click unsubscribe in the headers. Keep spam complaint rates below a stated threshold, in the region of a tenth of a percent, with a hard ceiling above it.
The complaint rate is the one that ends campaigns. It is small enough that a single badly targeted send can breach it, and recovery is slow because reputation is built over weeks.
One-click unsubscribe is a header, not a link
The requirement is specific and is frequently misread as "have an unsubscribe link". It is not: it is the List-Unsubscribe header, plus List-Unsubscribe-Post as defined in RFC 8058, which lets the mail client present its own unsubscribe control and have it work with a single POST, without the recipient visiting your site.
Two things make it work rather than merely exist. The endpoint must act on the POST without requiring any further interaction: no confirmation page, no login. And the unsubscribe must be processed promptly, well inside the ten business days CAN-SPAM allows, because a recipient who unsubscribes through their client and receives another message will press the spam button instead, and that button is what the threshold measures.
Reputation is behaviour
Once authentication is in place, delivery is decided by what recipients do.
Opens and clicks help. Replies help more. Complaints hurt disproportionately. Deletion without opening, repeatedly, hurts quietly. Hitting spam traps and dead addresses hurts a great deal, which is why list hygiene is a deliverability activity rather than a tidiness one.
Three practices follow.
Warm a new domain or IP gradually. Volume from a cold sender is itself a signal. Ramping over weeks is slower and works; sending ten thousand on day one does not.
Remove hard bounces immediately and permanently. A repeated send to a dead address is one of the clearest signals that a list was not maintained.
Segment by engagement and stop sending to the never-engaged. This feels like discarding reach. It is the single most effective deliverability intervention available, because the never-engaged are the population that generates complaints and no revenue.
Separate your mail streams
Transactional and marketing mail should not share a sending domain.
A marketing campaign that damages reputation should not be able to stop a password reset or an appointment confirmation from arriving. The standard answer is a subdomain for marketing, with its own authentication and its own reputation, leaving the primary domain for mail that must arrive.
Set this up before it matters. Moving a sending domain after reputation damage means warming a new one while the old one is the reason you need to.
The check
Send a message to an address you hold at a major provider. Open the raw headers.
SPF pass, DKIM pass, DMARC pass, on the domain the recipient sees. List-Unsubscribe present with a POST form. If all four are true you have done the part you control, and everything else is about whether the message was worth sending.