Deliverability, run as an operational discipline.

What actually decides whether your mail reaches the inbox?

Two things, in this order: whether the receiving server can prove the mail is really from you, and whether recipients have shown they want it. The first is authentication, which is now a hard gate — fail it and you are not judged on merit, you are simply rejected. The second is reputation, which is the running tally a mailbox provider keeps on the domain and IP you send from: how often people open and reply, how often they complain, how many addresses bounce, and how steady your volume is.

Sending speed barely enters into it. A host that can push millions of messages an hour lands in spam just as easily as a slow one if the reputation is poor, because the provider is reacting to behaviour, not throughput. This is why we treat deliverability as an operational discipline that runs for the life of a sending platform, not a checklist you complete at launch and forget. The rules below are the floor; the reputation work above them is what actually keeps you in the inbox.

Engagement is the signal that ties it together. Opens, clicks, replies, and the absence of complaints tell a provider that real people want what you send, and that judgement is made per domain and per IP over a rolling window. It is also why a list you have not mailed in months is risky to wake at full volume: the provider has no recent evidence either way, and a sudden burst reads as the behaviour of a sender with something to hide.

Do SPF, DKIM, and DMARC need to align?

Yes, and alignment is the part senders most often get wrong. You need both SPF and DKIM configured, but DMARC only passes when the visible From: domain matches either the SPF domain or the DKIM signing domain. It is common to have SPF and DKIM both technically valid yet neither aligned to the From: address, which means DMARC fails and the mail is treated as suspect. We sign with 2048-bit DKIM keys, rotate them on a schedule, and confirm alignment for every stream before volume goes up.

DMARC also carries a policy that tells receivers what to do when a message fails: monitor only, quarantine to spam, or reject outright. Bulk senders are required to publish at least a monitoring policy, but monitoring alone does nothing to stop someone forging your domain. The right path is to start at monitoring, read the aggregate reports until every legitimate source is accounted for, and then move to enforcement. That progression is deliberate, because flipping straight to reject without checking the reports is how a company accidentally blocks its own invoices.

Two related details catch people out. Subdomains fall under your organisational DMARC policy, so a forgotten marketing subdomain can fail in your name if it is left unaligned. And forwarding breaks SPF, which is what ARC is for: it preserves the original authentication result as mail passes through forwarders and mailing lists, so legitimate forwarded mail is not punished for the hop. We account for both when we map your sending sources.

Do you actually need a dedicated IP?

Often, no. A dedicated IP only helps once you send enough to keep it busy and warm — roughly fifty thousand messages a month is the rough floor. Below that, a thin dedicated IP looks inactive to mailbox providers between sends, and a well-run shared pool that is already warm will place your mail better. For small senders, low-frequency lists, and tightly targeted business outreach, domain reputation and list quality do far more work than owning an address ever will.

This is the kind of advice that costs us a line item, and we give it anyway. The point of deliverability is mail that lands, measured in your own panel, not a longer invoice. When a dedicated IP is right we will say so and warm it properly; when it is not, we will put you on shared infrastructure and spend the effort on the things that actually move your placement. The same honesty applies to the optional authentication layers: we recommend MTA-STS or BIMI when they earn their keep and leave them out when they do not.

There is a quieter cost to a dedicated IP that sellers skip over: it has to stay busy. An IP that sends in bursts and then goes quiet looks unestablished every time it wakes, and never builds the steady history that earns trust. If your volume cannot keep one IP consistently active, splitting it across several is worse rather than better. We would rather warm one IP you can feed than hand you three that all look cold.

How do you fix a domain that has fallen into spam?

You can recover, but it is slower than starting clean, and there is no single switch. The first job is diagnosis: we confirm that authentication and alignment actually pass, read the DMARC and feedback-loop reports to find what is generating complaints or hard bounces, and look for a blocklist entry or a reverse-DNS gap dragging the whole domain down. Most reputation problems trace back to a specific stream or list segment rather than the entire programme.

Then comes the rebuild. We suppress the addresses causing harm, stop or fix the stream that triggered the decline, and re-warm to your most engaged recipients so the provider sees a run of wanted mail again. Volume returns gradually, the same way a new IP would, because the provider is waiting for fresh evidence and a burst only confirms the old suspicion. Recovery is real work measured in weeks; anyone promising an overnight fix is selling something that does not exist.