opsira

Do not send important mail from a domain nobody has heard of

In short

We built a document signing flow, wired the notifications to a new domain, and turned that sending off again within days.

The problem with new domains

Receiving systems weigh sender reputation heavily, and a domain with no history has none. That is not the same as bad, but it means every filter treats you cautiously, and low volume means you build reputation slowly.

The mail people put on a new domain first is usually the mail that matters most: signature requests, password resets, order confirmations. Exactly the messages where landing in spam is worst, because the recipient is waiting for it and will not go looking.

What we did instead

We disabled automatic sending from the new domain and distributed the notifications from an established mailbox instead. Less elegant, and it worked immediately, which the elegant version did not.

The signing platform kept generating the links. Only the delivery moved.

How to warm a domain, if you want to

Note that this only works if you have engaged recipients to start with. For a business whose entire mail volume is a handful of transactional messages a week, there is no realistic warming path, and borrowing an established domain is the honest answer.

Separate the streams

Once you do have volume, keep marketing and transactional mail on different subdomains. Marketing attracts complaints, and complaints damage the reputation of the domain that sent them. Sharing one domain means a promotional campaign can send your password resets to spam.

The test

Before trusting a new sending setup with anything important, send to accounts on the major providers and check where it actually lands. Delivery reported as successful by your provider means accepted, not read. The two are very different.

Need help with any of this?

These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.