This information is for postmasters - the administrators of other mail servers - only.
If you do not operate a mail server, this is not the right place for you.Take me back to safety

Contents

  1. Pregreet
  2. DKIM and SPF, Spam filtering
  3. DMARC
  4. Mailing lists
  5. Spam mitigation
  6. Further reading

Pregreet — Top

We are pretty strict in terms of what we let in. This is a corporate mail service and a lot of sensitive users rely on our secrurity. If you don't have your DNS records set up correctly or your IP/Subnet is in a "bad neighborhood" you are very likely rejected at or before the HELO. If you have a dynamic IP or you are in a subnet that is publicly known to be assigned to (private) customers you will be rejected. In the case that you really think that this is necessary contact any of the usual postmaster adresses and ask to be whitelisted.

Make sure your IP and domain has a good reputation. A malfunctioning MTA (or no MTA at all for mass mail) will very likely cause rejections. Mailservers that do not honor hard bounces (permanent error, rejection) can be limited or blocked. Make sure your MTA adheres to the standard! [1]

DKIM and SPF, Spam filtering — Top

We are checking all incoming mail against the published DNS records. You need to have your DNS records set up correctly or you will very likely end up in the Spam folder instead of user's inboxes.

In addition to these measures, our users report spam and ham. When your domains, IPs or MTAs send mail to honeypots or spam traps you will be blacklisted irrespective of if it's abuse or a breach of a legitimate service. Therefore make sure your security measures are taken care of.

You have run a mailserver for 15 years on the same IP and domain but your mails are rejected or land in user's spam folder? While in the past it was still possible to run a mailserver on reputation alone, the major mail service providers like Gmail, Yahoo, Apple have really tightened the thumbscrews since 2023 so much so that even normal users' plaintext mails are landing in spam. Yahoo broke mailing list subscriptions for hundreds of thousands of users.

However, the reality is that the times for mail servers without DKIM, SPF and DMARC are simply over and you should get your act together if you want your mails to be delivered. We are not enforcing any strict policy adherence and instead rely on many factors to protect our users. In simple terms this means that an MTA with perfect DNS records and signing may be rejected if it has a spammy reputation while an MTA without any security measures but an excellent reputation may be let trough.

DMARC — Top

We accept DMARC aggregate (rua) and failure (ruf) reports. If you would like to enter a non-disclosure aggreement with us (for privacy and security reasons) we are open to privately exchanging failure reports (TLS support mandatory).

We suggest you to send us aggregate reports so that DKIM/SPF/DMARC problems can be diagnosed. Aggregate reports are monitored, we report abuse and take action when we see a lot of bad activity from a particular neighborhood. Please make sure your DMARC reports conform to the standard [5], for example with OpenDMARC.

We have pushed to iron out many corner cases in widely used DMARC report parsers so that they digest most reports from the many report generator implementations in use around the globe, if you send out broken aggregate reports that don't adhere to the standard, other postmasters are going to be annoyed with you.

In addition to recieving DMARC aggregate reports we also send them, which means - unlike most providers - we are fully compliant with [5, Section 8]. This includes high-volume mailing lists and other long transmission chains.

You can check our reporting from commericial DMARC analysis providers, for example on dmarcian.com.

Mailing lists — Top

We host several small-volume mailing lists for both commerical and non-commerical purposes.

Many of our mailbox users are subscribed to high-volume (over 3000 messages per day) mailing lists.

That means that a lot of mail is forwarded and relayed. Outgoing mail is always DKIM signed by our published key with selector dkim. Our own mailing lists support VERP and bounces are always handled by the mailing list manager, we do not forge sender addresses whereever possible. We do not use SRS. ARC - both passive and active - is currently being tested but at the moment we only verify ARC messages in production. Our ARC results are included in our DMARC aggregate reports as local policy results. If you are signing ARC and would like to be added our trusted ARC sealers domain whitelist, contact us.

It is not to be expected that DKIM2 is rolled out any time soon, which fixes many of the shortcomings of the DKIM/SPF/DMARC stack, particularly for mailing lists. So we will roll out ARC checking for incoming messages, which will also be part of our DMARC aggregate reports.

Please contact us if you would like to join our postmasters mailing list.

mlmmj

The mlmmj Project is a very fast and powerful mailing list manager. As mail servers usually have a very long service life and cannot be upgraded easily because of the very large software stack, many are still stuck on older sofware. As there has been a lot of upstream development in mlmmj in the past year, it would be desirable to have a packaged current version of mlmmj. We are currently working on getting the current mlmmj version backported to Debian 12. In the meantime there is a GPG-signed build available here:

  mlmmj 1.6.0 for Debian 12 Bookworm [Signature]

  mlmmj 1.8.0 for Debian 12 Bookworm [Signature]

Spam mitigation — Top

If you use spamassassin, you can now use the new

<EMOJI>
and
<EMOJI_BROAD>
replace tags to match single emojis (look in 25_replace.cf). They should automatically be available when spamassassin rules are updated via cronjob (sa-update). John Hardin wrote example subrules that are available in the upstream repo under 20_emojis.cf to match emojis in the from name. In our experience all emails that have emojis in friendly from are spam.

Gmail for example rejects or quarantines mails that use Emojis to imitate parts of the user interface. However, a lot of legitimate notification emails nowadays use emojis in both the subject header and body so while its a spam indicator these mails shouldn't be blocked or junked outright.

Further reading — Top

  1. The SMTP standard RFC2821 on the IETF website
  2. DKIM on Wikipedia
  3. SPF on Wikipedia
  4. DMARC on Wikipedia
  5. The DMARC standard RFC7489 on the IETF website
  6. ARC on Wikipedia
  7. Maintained OpenARC Fork
  8. dmarc-report-viewer Project
  9. RFC2142 — Mailbox names for common services, roles and functions


Last change: April 3rd 2026 JM