In this article I detail how I setup my privacy focused email inbox with a custom domain to enable flexibility in case I ever want to move mail servers.
I have some redacted information which is designated in strike through text. This revolves around my reverse engineering process of PTR validation. I left it here in case people wanted to see the evidence that allowed me to come to a conclusion on how PTR is validated by the mail server software.
- Chris Were Digital - Posteo - Email Service Review
- Tom Spark Reviews - Posteo Email Review - Is it Good?
- Tom Spark Reviews - mailbox.org Review - Is it Good?
I decided on mailbox.org.
The main reasons I did not go with Posteo
- Their domain could be confusing to type for some people.
- They didn’t have external domain support
- They wanted 1 year payment upfront.
I went with Ionos aka 1&1 for the domain provider.
I choose mailbox.org as the mail server.
- Buy domain and ensure private whois is enabled (default in EU/UK at time of writing). For this example I am using:
- Buy mailbox.org package. Check usage on your current mail provider to gauge how much storage you need.
- Add external domain as per their instructions here: Using custom domains
- Add MX as per their instructions (you may need to click “disable service” “web hosting” on the DNS entry if using Ionos).
- Add SPF as per their instructions although I suggest tailing it with
-ato ensure no one can spoof you.
- DKIM improves spam score with Google so I enabled that as per mailbox.org instructions.
Add PTR as per below instructions.
Autodiscover is only useful if the custom domain is the primary one on mailbox.org.
DMARC I don’t think adds any benefit unless you are good at data analytics. So ignore it.
and 7 are only essential if you are sending emails from this domain or want to prevent someone spoofing you. For receive only it’s not a concern.
Google/gmail doesn’t seem to worry about PTR but it may help spam score.
I had some mail being flagged by 365 spam filters.
365 spam headers don’t explicitly state the reason for marking it as spam and it seems to lumber a lot under the generic header
SFV:SPM see: Anti-spam message headers
Change the A record to point to mailbox.org’s IP address so we can workaround the whole PTR issue. It takes a while to propagate.
PTR work around example
my-domain.co.uk -> 18.104.22.168 -> lookup PTR -> mailbox.org - > 22.214.171.124 = FCrDNS (Forward Confirmed Reverse DNS)
The A record IP must be a static domain/IP for this to work.
PTR and rDNS are the same thing just different names. PTR must be set on the server side.
How the mail server checks PTR
There isn’t a tonne of documentation on how the email server does the PTR check.
It doesn’t seem to care if my domain here doesn’t match the PTR domain. It only seems to care if the PTR of the IPv4 points to a domain and if that domain points to the same IPv4. This is presumably because my domain could have multiple origin IPs due to multiple outbound SMTP server cluster.
In this context “client” means the sending SMTP server:
mout-u-204.mailbox.org and “sender” means the senders domain:
It probably depends how strict the mail server is. It may check PTR of the “client” and the “sender”
which appears to be the case for 365. My email stopped getting flagged as spam once I made these changes. After further investigation detailed below and examination of email headers I see that the SPF record didn’t propagate to exchange servers at the time I was having issues. So the fact I made my “sender” domain have a reverse PTR was a false positive and had no effect I now believe. So I will make my domains point to my web server which unfortunately has a no FCrDNS IP but it shouldn’t cause me any problems.
Looking at the postfix/postconf man pages
Of course exchange servers don’t run postfix but it’s probably the most popular mail server.
reject_unknown_client_hostnamemailbox.org cover this.
reject_unknown_reverse_client_hostnamemailbox.org cover this.
reject_unknown_helo_hostnamemailbox.org cover this.
reject_unknown_recipient_domainOut of our control if recipient mail server is setup incorrectly.
reject_unknown_sender_domainWe have an A record and a MX record.
It looks like mail servers don’t perform PTR on “sender” domain. They only perform this on the “client” domain.
Run domain through the testing tools listed below.
Example fully configured received headers and source
I have removed most text and left the relevant parts.
Authentication-Results: spf=pass; dkim=pass (signature was verified); dmarc=bestguesspass action=none;compauth=pass reason=109 Received-SPF: Pass Received: from mout-u-107.mailbox.org (126.96.36.199) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; Received: from smtp1.mailbox.org ([188.8.131.52]) X-Forefront-Antispam-Report: CIP:184.108.40.206;IPV:;CTRY:DE;EFV:NLI;SFV:NSPM;SFS:(10001)(189003)(199004)(956004)(1096003)(6916009)(5660300002)(336012)(3480700007)(9686003)(26005)(558084003)(58800400005)(8676002)(7116003)(246002)(356004)(7636002)(7596002)(86362001)(35100500004)(220243001)(558944008);DIR:INB;SFP:;SCL:1;SRVR:AM0PR02MB5025;H:mout-u-107.mailbox.org;FPR:;SPF:Pass;LANG:en;PTR:mout-u-107.mailbox.org;MX:1;A:1;
Example 365 header flagged as spam
before I setup PTR before SPF propagated and before DKIM
Authentication-Results: spf=pass; dkim=none (message not signed); dmarc=bestguesspass action=none;compauth=pass reason=109 Received-SPF: Pass Received: from mout-u-204.mailbox.org (220.127.116.11) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([18.104.22.168]) X-Forefront-Antispam-Report: CIP:22.214.171.124;IPV:;CTRY:DE;EFV:NLI;SFV:SPM;SFS:(10001);DIR:INB;SFP:;SCL:5;SRVR:DB8PR02MB5833;H:mout-u-204.mailbox.org;FPR:;SPF:None;LANG:en;CAT:SPM;
Analysing the X-Forefront-Antispam-Report message we see the following interesting header fields
SFV:SPMThe message was marked as spam by the content filter.
SPM: SpamThe category of protection policy, applied to the message.
SCL:5An SCL rating of 5 or 6 is considered suspected spam.
SPF:NoneThis was the red herring that I didn’t notice earlier. Further up the headers is two SPF pass results from other servers so I assumed it was good. It turns out the SPF wasn’t fully propagated to exchange servers and I started going down a rabbit hole assuming it was a “sender” domain PTR issue as there was nothing else to blame.
Nothing here is suggesting that 365 does a PTR against my “sender” domain.
2020-02-04 18:11: mailbox.org calendar wont send email notifications unless you set the timezone in the settings to match that of the event’s time zone. So do that first and it becomes the default for new events.
Update 2020-02-04 19:41: After I exported the old and new events
.ics files to
diff. It appears changing the primary alias and removing the old one will break email notifications for any calendar events created before that.
Update 2020-02-07 19:30: I am still having issues getting calendar to reliably email me event notifications.
Can you still use HTTP redirects with A record on Ionos? 1&1 HTTP redirect points the A record to
http://clienthosting.eu/ so it’s not possible to use this in conjunction with the PTR work around.
I accidently deleted the mailbox.org security key
This isn’t a problem once the custom alias is already added. It’s only used to prove that you own the domain.
My final DNS entries look like this
Related blog posts
Useful tools for testing
- mxtoolbox MX lookup
- mxtoolbox SPF lookup
- mxtoolbox A record lookup
- debouncer PTR check
- google toolbox messageheader
mailbox.org useful knowledge base articles
- What data do they store and for how long
- Can I trust the staff at mailbox.org
- Mailbox encryption
- Encryption of calendar and address book
- Move away from Gmail to mailbox.org - step-by-step
Other useful resources
Let me know what you think of this article on twitter @M3PGS or leave a comment below!