Configure Relay

An email relay is the heart of modern email infrastructure. Your email server might not have access to port 25 outbound. It might have a bad IP reputation and your emails are generally flagged as Spam. Or you are sending high volumes of emails, but you are unable to set up traffic shaping. Other email providers feel overwhelmed with the amount of emails received and reject them.

Whatever the reason you want to use an email relay, p25.dev was built as an industry grade email relay.

Configuration

The relay hostname is relay.p25.dev.

The available ports are 25, 587, 2587 (Authentication required!)

Your credentials

On your configuration dashboard, on the page "SMTP Auth", you find your username and password. The password is blurred to avoid anyone from shoulder-surfing and stealing your password. You can reveal it by clicking on the "eye" symbol.

Config snippets

mox

Stalwart

Postfix

Restrictions

We try to be generous in forwarding your emails, but we need to be careful to protect our IP reputation.

You must DKIM sign all your emails. We will not accept unsigned emails. Software such as mox and Stalwart DKIM sign all emails by default.

You need to configure your DNS based on the mox or Stalwart configuration for DKIM. This is highly specific to your setup, and we can't give general guidance.

You must use a From/MAIL FROM domain you own in p25.dev. If you added a domain to p25.dev, and you try to send an email from the same domain, your MTA will usually comply, but there are reasons to deviate (see the section "Bounce address" below). If we don't recognize your domain, we will hard-bounce with the error message: Sender address rejected: domain not owned by user.

Note that we check domains based on your SMTP Auth credentials. No other user can send emails from your domain via p25.dev.

Bounce rate

When you start sending emails, you'll see the numbers for delivered emails increase on your Dashboard. Sometimes you might email an address that does not exist. You will receive a notification, also called a Bounce.

We will temporarily block this destination so that you don't send an email there again. All temporarily blocked addresses are visible on your dashboard. You can't manually remove them. They will expire within a few hours and be automatically removed.

Because you caused a Bounce, you will see the bounce counter on your Dashboard increase, and the bounce rate as well. If you pass a daily bounce rate of 5%, we will temporarily block your account. If you send more emails, you will receive a hard bounce with error message: Sending suspended: bounce rate too high.

High bounce rates are usually a sign for misconfiguration. You might be using a large list of recipients, of which some addresses are outdated. Maybe you are guessing available addresses and just try reaching them (which you should never do). Such behavior would be seen as spammy. Not only by other providers, but also by p25.dev.

Sending limits

On the pricing page, you can see our generous sending limits based on your subscription tier. If you reach the daily sending limit you can't send any more emails via p25.dev on that day. You will receive a hard bounce error message: Daily sending limit reached. In this case you need to wait until 0:00 UTC for your limit to reset.

Bounce address

If you are very technical, you might have seen that we change your MAIL FROM address when relaying email. The address looks a bit cryptic, like so: SRS0=7+br=EY=p25.dev=mail@bounce.p25.dev. It is based on a protocol called Sender Rewriting Scheme. This scheme contains enough information to redirect a potential Bounce back to your original email address.

Note that this will not affect how a recipient sees your email and your "From:" information. The MAIL FROM is a technical field and usually not visible (often times not even accessible) to the recipient of an email.

Here is an explanation why we chose to use a custom bounce address with SRS0:

Bounce rate

All bounces will return to the MAIL FROM address. If we used your domain name, we would not see the bounce. For us, it is important to keep track of bounce rates per user so that we can work on reputation and potential problems.

SPF record

If you don't allow our IP address in your SPF record, relayed emails would be rejected by most email providers. We could ask our users to allow our IPs, and constantly monitor if they do so, but we chose for the easier (for the user) route of rewriting MAIL FROM on our end, transparent for the user.

SPF record (again)

Because we control the MAIL FROM domain, we set a valid SPF record so that all receiving email providers are happy.