Do you read my email?

The path of a message

When someone writes to hello@yourdomain.com and the domain’s MX points to mxproxy, this happens, in this order:

1. Connection. The sender’s server connects to our MX (port 25). We offer STARTTLS, and the conversation is encrypted whenever the sender accepts. We only accept recipients on domains verified at mxproxy: an address with no forwarder and no catch-all is refused (550) before the content is sent. We are not an open relay.
2. Authentication. With the message received (up to 25 MB), we check SPF, DKIM and DMARC. If the sender’s domain publishes DMARC p=reject and the message fails, it is refused. The result goes in the Authentication-Results header, which you see in your inbox.
3. Spam. If your domain uses the filter, rspamd, running on our own server, gives a score. The level you chose decides: refuse, mark ([SPAM] in the subject and the X-Spam header) or let it through. rspamd looks up public blocklists over DNS with the IP and domains of the sender and of the links; the content never leaves the server. If rspamd is down, the message goes through without a verdict instead of being lost.
4. ARC and SRS. We seal the message with ARC, so the destination knows the original authentication passed even after forwarding, and rewrite the envelope sender with SRS (SRS0=…), so SPF passes at the destination and a bounce goes back to the original sender. The sender you see (From:) does not change.
5. Queue. We store the message in the database queue and only then answer 250 to the sender. If anything goes down after that, the message is not lost. The content (headers, body and attachments) stays in the queue only while delivery is pending.
6. Delivery. The queue delivers to each destination’s server (Gmail, Outlook...), with STARTTLS whenever the destination offers it. If the destination domain publishes an MTA-STS policy that requires TLS, we deliver only with a valid certificate (details). Temporary refusal: we retry at growing intervals for up to 5 days. Permanent refusal or giving up: the sender gets a bounce with only the original message’s headers.
7. After delivery. When the destination server confirms receipt, the message content is deleted from the queue in the same step that marks it delivered. On a permanent refusal or when we give up, the content is deleted as soon as we create the bounce. Only a record without content remains (envelope sender, recipients, status, attempts, last error, size and timestamps), deleted automatically after 30 days. The queue is not a mailbox: not even while a message waits can it be opened from the dashboard or the API.

What you send through our SMTP (port 587, to reply as the domain from Gmail or Outlook) goes through mandatory STARTTLS and a login, gets your domain’s DKIM signature and follows the same queue, with the same retention.

Who has access

• Software, not people. The checks above are automatic.
• You and your team see the message log: sender, recipient, subject, size and status. Never the body or the attachments.
• Our team has no screen to read email: not even the admin dashboard shows content. Whoever runs the server has technical access to the database that holds the queue, with the content of messages still waiting for delivery. We would only open a specific message to investigate a delivery problem at your request, look into an abuse report or comply with an order from a competent authority.
• Channels you turn on. If you link a webhook or a Telegram chat to an address, each email produces a summary (sender, subject, start of the text and attachment names) that goes there. The message stays in the channel’s queue only until the summary goes out (or we give up); then its content is deleted. Without a channel, nothing leaves except the delivery to the inboxes you set up.
• Subprocessors. The server is Hetzner’s; the full list is in the Privacy Policy.

What we never do

• Read email as a routine, out of curiosity or to “improve the product”.
• Use the content for advertising, profiling or training AI models.
• Sell or rent data, or show ads.
• Keep email to be read later: mxproxy is not a mailbox.
• Send the message anywhere other than the destinations and channels you set up.

The full rules are in the Privacy Policy and the Terms of Service; the technical details of encryption and delivery, in Security and delivery.

Frequently asked questions

Want to try it with your domain? The free plan needs no card. Create a free account