Why we don't forward your email

Every service in this category hands you a forwarding address. We don’t, and you still get the address. The difference is the reason your mail arrives.

What forwarding actually does

When someone emails you@example.com and that address forwards to your real inbox, the forwarding server has to re-send the message. It cannot re-send it as the original sender, because it isn’t the original sender — so it rewrites the envelope sender to itself.

That single rewrite is the problem. SPF checks whether the sending server is allowed to send for the envelope sender’s domain, and after a forward the answer is no: a machine nobody authorised is now sending mail claiming to come from somewhere else. DMARC then asks whether the authenticated domain aligns with the visible From: header. It doesn’t. The receiving server sees an unauthenticated message wearing a stranger’s name, and does what it should: files it as junk.

Nothing is misconfigured when this happens. It’s the system working correctly on a message that genuinely can’t be authenticated. And it fails quietly — the sender sees a successful delivery, you see nothing at all, and neither of you finds out for weeks.

The second problem: you inherit someone else’s reputation

A forwarder is also in the path of outbound mail on your behalf, which means it owns everything that goes with that: bounce processing, spam complaints, blocklist appeals, and an IP reputation shared with every other person it forwards for. One user’s spam problem becomes everyone’s deliverability problem. That is a permanent operational job, and it is invisible right up until the week it isn’t.

What we do instead

Nothing we send is a relay of anything anyone else wrote:

• An established email provider owns the hard parts — the MX records, TLS, spam scoring and bounce handling. Mail to you@contactme.co arrives there, not here.
• They hand us the parsed message over a signed webhook. We store it in your inbox and classify it: what the sender wants, whether it’s worth your time, and a one-line summary.
• We then send you a new message from our own verified domain, properly aligned, telling you what arrived. Its Reply-To is the person who wrote to you.

So you hit reply in Gmail, or Outlook, or wherever you already read your mail, and it goes straight to them from your own address. They never learn your address until you choose to answer, and nothing in the chain is a forward, so there is nothing for SPF to fail.

Why not just forward anyway?

Because it works well enough to ship and badly enough to lose you business. SRS and similar schemes patch the envelope problem and introduce their own; large providers apply their own heuristics to forwarded mail regardless. You end up maintaining a workaround for a problem you chose, in exchange for saving one screen of code.

The version without forwarding is less clever and simply doesn’t have the failure mode. That’s the whole argument.

What it means for you

• Your real address never goes public. It’s read only by the job that notifies you, and the public read path is a database function with a fixed column list that doesn’t include it — there is no API shape that can return it.
• The mailbox is off until you switch it on. A published address gets scraped, so that should be a decision rather than a default.
• Spam is filed, never dropped. Your provider scores it before we see it, and anything flagged goes to a spam view you can overrule in both directions.
• Your contact form uses the identical pipeline. Same inbox, same triage, different front door.

More detail on the plans is on the pricing page, and the rest of the common questions are in the FAQ.