Using Posteo with a Custom Domain

Originally published in October, 2017 – over three years later in 2021 I am still happily using Posteo!

I have been taking back control over my data. One of the biggest jumps I made was to ditch Gmail in favor of a privacy-conscious email provider, Posteo. Of all the email providers suggested by, I chose Posteo because of their commitment to sustainability, transparency, and self-sufficiency. They support full encryption of all user data, and yet do so in a way that supports the standard IMAP, CalDAV, and CardDAV protocols for easy syncing.

Their documentation is extensive, they’re reasonably priced (€1 a month), and their migration services are sublime. I enabled both their crypto mail storage and TLS-sending guarantee features. They both come with important caveats, so be sure to read the linked information.

To put the cherry on the cake, they are recommended by the Free Software Foundation for being fully compatible with LibreJS. Finally, Posteo’s support is prompt and helpful, too. Just email [email protected]! Way back when, I used the now-defunct app “DAVdroid” to sync an Android, but now with an iPhone I just use the native apps and Posteo’s instructions.

Posteo does not support one key feature: receiving email at a custom domain. Posteo has a good reason for this: doing so would require they store the assignment of the domain as unencrypted user information, which violates their privacy promises. But I need a custom domain because (a) my eponymous email is on all my commits and (b) I don’t want to go handing out my Posteo address to everyone.

After trying many different methods in the past three years, the best so far is using Forward Email. Their open source servers are designed such that emails are received, spam filtered, and forwarded entirely in-memory, with no logging. It has a free version, but the premium version at $3 a month is easier to setup and keeps your configuration private.

My most recent method required two additional mail services:

Even earlier when I used Gmail (eww) I had MailGun forwarding my custom domain. All of this placed my email on too many servers!

Despite how much better Forward Email is than my previous solutions, for anything sensitive I use a sub-address of my Posteo email (like [email protected]). This minimizes the servers touching the email and provides all of Posteo’s encryption support, including DANE and DKIM.

Incoming Email

Setting up incoming email is pretty straightforward, just follow their setup guide. If you’re reading this guide, you care about your privacy, so you probably want to setup a paid plan first so you don’t have to reveal your Posteo email to the world.

When you’re done you should have two MX records one two TXT records:

$ dig MX +short

$ dig TXT +short
"v=spf1 a mx -all"
"forward-email-site-verification=<your key>"

So far their spam filters have been pretty good. I received one piece of spam (which passed SPF and DKIM validation), so I reached out to support and Nick (the developer) said they accept spam reports at [email protected].

If you’re wondering about the legitimacy of the service, from my digging it seems serious. The developer is active on Twitter and GitHub and it’d be a lot of work to implement the in-memory server just to ignore it. I did notice that some of the advertised “premium features” are still under development (like the extension), but 2020 was also a hell of a year and this is forgivable. I’m enjoying the much improved setup!

Outgoing Email

Setting up outgoing email takes quite a bit more work (all because of spammers).

The first thing to setup is a sender identity in Posteo. This is necessary to add your custom domain’s email to Posteo’s webmail interface. If you use another mail app (like on an iPhone) you need to follow its instructions to add your “sender identity” there too.

Because of spammers, Posteo prevents sending email under an alias for the first week of a new account, resulting in the error:

Spam protection: You can only send e-mails with your Posteo address.

So you will need to wait an entire week before it works. Thanks to the multiple readers that found this out and let me know of their updated policy.

Please note that since Posteo does not officially support custom domains, they don’t prevent other users from potentially spoofing an email at your domain, hence this policy. Fortunately, Posteo deals only with paid accounts and will respond to any abuse report appropriately. If you need to authenticate your email, you should use your Posteo alias and rely on DKIM, or use a communication method more secure than email (like Signal).

Meanwhile, we need to add a two more DNS records to stop spammers (of course) from spoofing our domain:

SPF is arguably the most important tool in preventing your domain from spammer abuse and so getting blacklisted. If you setup Forward Email then you already have an SPF record, so we need to modify it!

Go back to your DNS registrar and add next to so it looks like this:

$ dig TXT +short
"v=spf1 a mx -all"

Essentially this tells mail servers that email from your domain is only allowed from mail servers hosted at IP addresses which the SPF records of and specify (we’re just delegating using “include”). This makes sense because you want to send email from Posteo using your custom domain, and Forward Email needs to send email to Posteo using it too.

DMARC lets us publish a policy we want other mail servers to follow for email that fails validation. At your DNS registrar, add a new TXT record (like you did for SPF) but for the _dmarc subdomain instead of the root (or @) that looks like this:

$ dig TXT +short
"v=DMARC1; p=none; rua=mailto:<your email>"

This sets a DMARC policy that won’t reject or quarantine your emails, but will send one aggregate report a day to the given email address. The DMARC FAQ recommends setting the policy first to none and reviewing reports to be sure your email is being validated before changing it to reject, but even having it set will increase your email’s legitimacy. In fact, Posteo has their DMARC policy set to none. (I even read somewhere that most spammers won’t even bother with domains that have a DMARC record set.)

After reviewing a few reports, you can remove the rua part to stop requesting them, and change none to reject if all the auth_results records are passing (ignore the indication that DKIM is failing, this is expected, but DMARC only requires one of DKIM and SPF to pass, and you should verify that SPF is passing). I found these reports a bit annoying, and so I send them to a service by Postmark, which receives DMARC reports, analyzes them, and then emails a weekly summary. Thanks Pete Keen for the tip!


With these records set up, now you should test your email! I used mail-tester to see how “spammy” my emails are and received a near-perfect 9/10 score from my custom domain via Posteo (the missing point was due to lack of DKIM).

Posteo’s postmaster page has a lot of great detail, and assures us that we may send email through their SMTP servers using our custom domain. It explains that these emails will lack a DKIM signature, which is a small downside. DKIM provides authentication that you own the sending email account, and if you need that you can use your real Posteo email. While DKIM would be great to have, at least it’s not necessary to avoid the spam folder.

I’d like to note that we can only secure our end of email…half the emails I send still go to Google’s servers because of the prevalence of Gmail. So I despite how great Posteo is, I don’t recommend email as a medium for personal communication and instead rely on Signal.

I hope you ditch Gmail too and make your life a bit more private!