Have anyone looked into the email forward service like simple login
Have anyone looked into the email forward service like simple login
We’ve already got a section on the site:
I think he’s referring to this service specifically, renamed topic and moved to Tool Suggestions.
Does not support GPG as of yet. Not sure what would be the advantage of this tool. I feel like this is a saturated market.
But it is good.
Thank you @rollsicecream for sharing our PR
We are the official team behind Forward Email.
We are sharing a few highlights below about our service:
dig arrl.net mx)
dig disneyadsales.com mx)
dig alumni.tufts.edu mx)
mandarin (npm packages). No other service comes close to us in terms of internationalization support.
Some questions we receive frequently are listed below, and we’re happy to answer more.
P.S. We’d love to be included in the Privacy Guides list and have already submitted a PR adhering to your existing code practices – happy to make changes as requested. We’re also available at
firstname.lastname@example.org and we have a Matrix Chat channel
Yes, we have a list of reviews on Trust Pilot at https://www.trustpilot.com/review/forwardemail.net.
We haven’t since 2017 and don’t plan to. We abide by a set of principles (see link below to the SQLite article which includes them in a section titled
Principles); which keeps us in tune with our product and customer base. We reached the limit for links to be posted in a first-timer here on PG so we referenced the section, but it’s available at the link below.
Yes, our status page is linked in the Resources dropdown of our website, on the footer of every page, and our website also updates in real-time of any errors (and automatically presents a notification if necessary of any issues). We also have a TTI (time to inbox) monitoring feature that is public, it’s on the footer of every page of our website and shows response times from Gmail, Outlook/Hotmail, and Apple iCloud. An example screenshot is below from the present time (it updates every 5 min):
We have an entire article dedicated to this at https://forwardemail.net/blog/docs/best-quantum-safe-encrypted-email-service.
Unlike every other email provider, we use individually encrypted SQLite mailboxes with
ChaCha20-Poly1305 encryption (using your strong passphrase, which only you have; you can audit our source to see that we do not store this anywhere and it’s only presented client-side when rendered in-memory). Other email providers use shared relational databases to store your emails, and most of them that use MongoDB and PostgreSQL have LUKS encryption, but NOT encryption at rest (of the actual database). SQLite encryption allows us to have both LUKS encryption AND the actual database encrypted itself. Even if a bad actor got access to the block storage device with
yourmailbox.sqlite they still couldn’t open it. If a bad actor has access to the shared relational database of any other email service provider, they have full access to your mailbox.
Yes, see our website FAQ section (note if you hit CMD+F or CTRL+F it will expand everything so you can easily search). We haven’t yet added something like Algolia or TypeSense yet but plan to do so in a privacy-focused way.
Also, can we edit this title? From
Forward Email (email aliasing service) to
Forward Email (encrypted IMAP/POP3/SMTP/API service) or something? Having “email aliasing service” makes it seem like we only support email forwarding or aliasing, but we actually support everything.
We now support PGP and WKD, see the footer of our website with our PGP and the info icon link to the FAQ section regarding PGP and WKD support.
Edit: Supported as of December 2023.
You’re right. Though @ph00lt0 has made this comment in July of the last year, so it’s normal that he said that.
Yes seems you now do, but please note my comment was from about 6 months ago.
forgot the word “now” Looks like I already included the word “now”, mainly wanted to update you!
@forwardemail did you guys get a public audit yet? I couldn’t find it so far.
I am not entirely sure about any criteria we might miss for this. But I think we should follow the same criteria as for other mail products: Encrypted Private Email Recommendations - Privacy Guides
Others have this:
Also should you want to make it easy for everyone maybe you could go through the requirements also and tell us if you notice any shortcomings on our or your ends. It is quite possible that some things aren’t applicable to a forwarding service. I’ll go though the list myself later.
Hi @ph00lt0 – just wanted to make sure you knew we’re not just an email forwarding service; we’re a complete email service (IMAP/POP3/SMTP/API). Early in 2024 we’re adding calendar, contacts, and newsletter support (most likely within the next 2 weeks we’ll have public availability).
RE: Audit: Correct, we don’t have an audit yet (by a third party), but we’ve already reached out to Cure53 and Assured, and that’s planned for early 2024 as well. Unlike any other provider, anyone could audit our source code (the complete backend as well). However we don’t have a third-party source that has access to our servers for auditing yet, but we plan to do so (as mentioned) to continue to build public trust.
RE: Requirements for Inclusion: Regarding the requirements outlined, we’ve answered everything in detail with response to each section (see below). We also provided some notes for each where relevant, and happy to answer further questions.
NOTE: This section “Technology” below is a response driven section derived from the current page of Privacy Guides minimum to qualify email section as of January 2, 2024 with respect to our service. We put a , a , or a where appropriate, and provided notes too. Let us know of any further questions.
Yes, we use encryption at rest, encryption in transit, support E2EE, and the actual individual SQLite mailbox databases themselves are encrypted using ChaCha20-Poly1305.
Yes, we support exporting to Mbox, EML, and we also support users downloading their entire SQLite encrypted database that we store on our side (instantly, at any time). Users can also make instant backups at any time, and see when their last backup was made. We also provide instructions for users as to how to open the SQLite guide and which open-source tools to use. Users can export and migrate at anytime using our migration guide in our FAQ.
Here’s a few screenshots showing this:
Yes, users can add as many domains as they want (unlimited - we don’t charge per domain or per user like other providers).
Yes, we operate on our own infrastructure, and we do not rely on any third parties. We don’t use Amazon SES, Mailgun, or any other provider. We use and dogfood our own service. Dig for example:
dig forwardemail.net mx
forwardemail.net. 3581 IN MX 0 mx2.forwardemail.net.
forwardemail.net. 3581 IN MX 0 mx1.forwardemail.net.
Encrypts all account data (Contacts, Calendars, etc.) at rest with zero-access encryption.
Integrated webmail E2EE/PGP encryption provided as a convenience.
Support for WKD to allow improved discovery of public OpenPGP keys via HTTP. GnuPG users can get a key by typing:
gpg --locate-key email@example.com
Support for a temporary mailbox for external users. This is useful when you want to send an encrypted email, without sending an actual copy to your recipient. These emails usually have a limited lifespan and then are automatically deleted. They also don’t require the recipient to configure any cryptography like OpenPGP.
NOTE: We consider this to be a security issue and anti-pattern and we do not support temporary mailboxes for recipients E2EE. We do provide plenty of documentation and plugin links for tools that can be used for OpenPGP in our FAQ.
Availability of the email provider’s services via an onion service.
NOTE: Yes, we support this, e.g. similar to Gmail, you can do
firstname.lastname@example.org. We also support regular expressions and webhooks, and you can even put in an IP address or domain name as a recipient to forward everything across.
Catch-all or alias functionality for those who own their own domains.
Use of standard email access protocols such as IMAP, SMTP or JMAP. Standard access protocols ensure customers can easily download all of their email, should they want to switch to another provider.
Received header field.
Accepts anonymous payment options (cryptocurrency), cash, gift cards, etc.)
NOTE: We previously accepted BitPay and tried Coinbase Commerce, but those providers had issues with reliability and developer support (from our in-depth experience) - and so we will eventually support crypto in a manner similar to the payment flow of Mullvad, a VPN provider. We do however support PayPal and Stripe (all payment methods). We plan to offer gift card vouchers on Amazon and elsewhere in 2024 for anonymity. Keep in mind that owning a domain name requires a purchase from a registrar, and most registrars do not accept crypto.
Hosted in a jurisdiction with strong email privacy protection laws.
NOTE: We do not store passwords for IMAP (and the databases themselves are individually encrypted, so we don’t have access to begin with. Despite having access to
your-mailbox.sqlitewe can’t open it – only you can, via in-memory SMTP/IMAP/POP3 access. Additionally for email forwarding, we operate entirely in-memory and do not store logs nor do we store emails to disk. We are hosted in the United States and operate from the United States.
Protection of webmail with 2FA, such as TOTP.
NOTE: We support passkeys, Webauthn, and 2FA via TOTP. We do not support SMS-based 2FA due to the potential attack vector of a man in the middle attack.
Zero access encryption, builds on encryption at rest. The provider does not have the decryption keys to the data they hold. This prevents a rogue employee leaking data they have access to or remote adversary from releasing data they have stolen by gaining unauthorized access to the server.
No TLS errors or vulnerabilities when being profiled by tools such as Hardenize, testssl.sh, or Qualys SSL Labs; this includes certificate related errors and weak DH parameters, such as those that led to Logjam.
NOTE: See bottom of this reply where we have provided a section with links to the latest Hardenize and Qualsys SSL Labs test results (where we get A+ results ).
A server suite preference (optional on TLSv1.3) for strong cipher suites which support forward secrecy and authenticated encryption.
A valid MTA-STS policy.
NOTE: We set ours to “enforce” mode so MTA-STS is always enforced. We also support MTA-STS for outbound SMTP and MX servers (we support it everywhere basically).
Valid DANE records.
NOTE: We await the support for Node.js to have TLSA record DNS lookup (see GitHub nodejs issue #39569), and then we can support DANE.
Valid SPF and DKIM records.
Have a proper DMARC record and policy or use ARC for authentication. If DMARC authentication is being used, the policy must be set to
NOTE: We use DMARC, ARC, DKIM, SPF, MTA-STS, SRS, and more.
NOTE: We have strict
p=rejecteverywhere and we also instruct users how to set this up in addition to DKIM, MTA-STS, and SPF (see our FAQ).
A server suite preference of TLS 1.2 or later and a plan for RFC8996
SMTPS submission, assuming SMTP is used.
Website security standards such as:
Must support viewing of Message headers, as it is a crucial forensic feature to determine if an email is a phishing attempt.
Here is a link to our SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=forwardemail.net
Here is a link to our Hardenize test: https://www.hardenize.com/report/forwardemail.net/1704231279
We wanted to also mention that we use DNS over HTTPS everywhere using a package we made called Tangerine (instead of using the built-in Node.js DNS module, which uses
c-ares under the hood). This allows us to use privacy-focused DNS servers, smart DNS rotation, and DoH across our entire application stack (with support for caching and
1:1 accuracy globally around the world with our service). See the “Tangerine” repo on our GitHub.
Sorry for tagging you, @forwardemail.
You advertise as being a complete email service provider. Ok. But unless I got your registration process wrong, the user needs to provide an existing email to use it. Can you explain that?
Hi there @banana1993 - thanks for your question, happy to answer.
You can sign in with Apple (privacy masked address) or use any other service, and then change your email address after. We don’t actually enforce email verification codes for signup, only a Cloudflare Turnstile captcha (it’s a captcha alternative that’s easier and way less annoying than having to put together a puzzle, or click on some weird AI-generated image like hCaptcha and reCaptcha ask you to; which every other provider seems to use).
We mainly support custom domains, but we also have a few vanity / global domains available for paying customers (e.g.
email@example.com). We are adding more and also going to allow users to use these for registration (and also use them for SMTP/IMAP/POP3 as well).
Damn you work fast haha. Thanks for the detailed answers. This is super valuable. I indeed didn’t understand that you are a full on email provider. I should make a test account soon I guess
I do think not being audited is a problem as I believe we should enforce the high standards here. Glad to know your pick on reputable auditors though. Looking forward to see that report coming our way ;).
Without having verified the answers the only other left issue that needs to be addressed would be DANE. But I do also see some other DNS related configuration items that should be improved on the website:
Amongst f.x. outdated cipher suits and TLS versions. This should be easy to fix. (You probably would get these recommendations in an audit too, so you can make a bit harder for them to find something :P)
Oh and feel free to ignore the % on these tests i linked above. Ipv6 is not a privacy or security concern.
Hi @forwardemail noticed you introduced DANE, well done!
I probably will follow with more questions later, but something I happen to notice. In your DNS records for custom domains, you ask for an email address (I assume of the associated accounts). Wouldn’t this result in large amounts of spam messages as this DNS record can be indexed? I wonder why you chose to do it the way. Usually I see a secret string here for confirmation, but a hash would do the trick even. Is there any technical reason one would need to expose the user’s mail in the DNS records?
@ph00lt0 That is for the free plan; as we started as a free forwarding service in 2017. Our initial service (which is still widely used) was purely using DNS records; there was no database or sign-up required. If you are on a paid plan, then the record is encrypted with a hash. There’s a note about the differences on the Pricing and FAQ pages. In the future we’re going to make it so there are encrypted records by default, but we will still always have the free plan available because of it’s simplicity (you can set up email forwarding, regex, webhooks, and more from simply your domain registrar or DNS provider).
I think this is a considerable downside. It basically defeats the anonymity of an alias service.