If you do not operate a mail server, this is not the right place for you. — Take me back to safety
Contents
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
- The SMTP standard RFC2821 on the IETF website
- DKIM on Wikipedia
- SPF on Wikipedia
- DMARC on Wikipedia
- The DMARC standard RFC7489 on the IETF website
- ARC on Wikipedia
- Maintained OpenARC Fork
- dmarc-report-viewer Project
- RFC2142 — Mailbox names for common services, roles and functions
Last change: April 3rd 2026 JM