Reply to any FirstSales email and reach a person

Notifications from FirstSales now have a working reply-to address. Hit reply on any of them and your message reaches support. Those emails also send from a dedicated transactional domain, kept apart from the domains your campaigns send on.

What changed

System email used to come from a no-reply address. If you replied to a warmup alert or a billing notice, your message went nowhere. Nobody read it and you got no bounce telling you that, so a reasonable reply about a real problem could sit unanswered with the sender assuming it had been received.

Every system email now carries a reply-to that reaches the support inbox. Alerts, billing notices, invitations, security notifications, and digests all work this way. You can reply from your phone at the moment you read the alert, quoting the alert itself, which is usually the fastest way to describe a problem accurately.

The second change is where these emails come from. Transactional email now sends from its own domain, separate from the domains you use for outreach. These two kinds of email have opposite requirements. Outreach domains are warmed slowly and carry sending reputation you have built up over weeks. Transactional email needs to arrive immediately and reliably, every time, regardless of any campaign activity.

Mixing them created a link between the two. Anything that affected the reputation of your outreach domain could delay the alert telling you about it. Splitting them means the alert about a deliverability problem does not travel through the domain having the problem.

How to use it

Reply to any FirstSales email the way you would reply to a person. Keep the original message quoted below your reply. That quoted text carries the workspace, the campaign, and the timestamp, which saves support from asking you for all three.

If an alert is telling you something you believe is wrong, replying to it directly is the most useful thing you can do. The alert body contains the exact reading that triggered it, so support can compare what the system measured against what you are seeing.

You do not need to do anything about the domain change. It applies automatically and affects only email sent to you by the product. Your campaign sending domains are untouched.

Why it matters

A no-reply address teaches people that the product does not want to hear from them. It is a small message, repeated on every email, and it works against you in a way that is difficult to measure. The people most likely to reply to an alert are the ones paying attention, which makes them exactly the people worth hearing from.

There is a practical side too. Alerts arrive when you are away from your desk more often than not. Being able to answer one from a phone, in the moment, means the response happens at all. If it requires opening the app on a laptop later, most of the time it does not happen.

Separating the sending domains matters for a narrower but sharper reason. The worst moment for a notification to be delayed is during a deliverability problem, and that is precisely when a shared domain would be most likely to delay it. Alerts about sending problems need to be independent of the thing they are reporting on.

What still comes from a no-reply address

Nothing. Every system email has a working reply-to now. If you find one that bounces or goes unanswered, that is a bug worth reporting, and replying to it is the right way to report it.

Effect on your own deliverability

None. Your outreach domains, their warmup state, their reputation, and their sending schedules are all unchanged. The transactional domain is a separate domain used only by the product to email you, and it carries no relationship to the domains your campaigns send on.

If you allow list FirstSales email inside your own organisation, the address these now come from has changed. Anyone who filters product notifications into a folder may need to update that rule once. Everyone else will see no difference apart from the reply working.

A note on quoting alerts

When you reply to an alert, resist trimming the quoted text. It looks like clutter and it is the most useful part of the message for whoever reads it. It contains the specific values that triggered the alert, which is what makes it possible to tell a real problem from a threshold that needs adjusting.

Why transactional and outreach email want different things

The two kinds of email have requirements that pull against each other, which is the reason for keeping them apart.

Outreach email is rate limited on purpose. A new sending domain starts slow and builds volume over weeks, because sending a thousand cold emails from a domain with no history is the fastest way to get that domain filtered. Everything about the outreach path is built around restraint.

Transactional email wants the opposite. A password reset, a failed payment notice, or a security alert should arrive within seconds, at any volume, with no ramp and no throttle. Nobody wants their login email held back to protect a sending reputation.

Running both through the same domain forces a compromise that suits neither. Worse, it couples them: a campaign that triggers a spam complaint affects the domain your billing alerts travel on. Separating the two means each can behave the way its job requires, and a problem on one side does not reach the other.

If a notification does not arrive

Check your spam folder first, then check whether your organisation filters mail by sender domain. The transactional domain is new, and a strict filter that was allow listing the old sender will not recognise it yet.

If neither explains it, reply to any other FirstSales email you have received. That reaches support with your account already identified, which is enough to look at the delivery record for the message you did not get.