Note: Our documentation pages are a work in progress! If you can't find the answers you need, please email us to let us know. We'll be happy to answer your questions.
Okay, sometimes asked questions.
Probably not. The ideal behind Purelymail is that you pay for what you actually use in terms of resources. While the Simple Plan charging a flat yearly amount already stretches that a bit, it's still basically just insurance against a moderate amount of overspending.
A lifetime subscription is different- it's a longterm commitment where the company takes your money in exchange for a promise to always provide you service. But how much service? No company could afford to let you store an infinite amount of mail with a lifetime plan.
A lifetime subscription eventually makes a liar of the company that sold it, when they start losing money on their guarantee and have to trick users into giving it up or renege on their promise.
(Also more selfishly, we might eventually add a bunch of useful services we'd want you to pay for.)
This can happen, and generally we want to fix it. Please contact us so we can help!
Part of the root reason for this is that IMAP, the protocol most apps use to access mailboxes, is really bad with large mailboxes. If both the client and the server don't use a set of inconsistently implemented extensions, this might result in ridiculous situations like retrieving every email in your mailbox and then just showing the top 50.
With our architecture, there's no real reason that a mailbox should have a size limit, but it's often IMAP that holds us back.
We're working on this. Right now, our implementation means that search indexes have to be fully retrieved from storage before a search can be processed, when a search might only need parts of them. Generally once the indexes have been retrieved, the search itself is quite fast.
Currently trial accounts have access to all the same features as regular accounts, however their rate limits for certain sensitive actions- like sending an email to an address not within the same account- are very low. This is to protect the service from being used by spammers.
Not at the moment.
A wildcard subdomain is a feature offered by some mail registrars where mail can be received by any direct child of a domain- so "subdomain.purelymail.com" and "anythinghere.purelymail.com", but not e.g. "subdomain.subdomain.purelymail.com".
Right now you'd have to add these subdomains one by one as effectively separate domains that route to the original domain.
Note that, if we ever implement this, subdomains are inherently limited. While there's not as many problems receiving mail, sending it can only use SPF authentication, and not more modern and powerful authentication like DKIM.
Effectively yes, though not as a specific thing. An email alias simply routes email from one address under your account to another. This can be accomplished with routing. You can reply to any email routed to one address as the alias it was originally sent to as well. The alias will be automatically filled in in webmail, but you may need to create something like an 'Identity' in a third-party client to have that happen.
Accounts have rate limits on:
Contact support if you need these rate limits adjusted for your account. So long as you have a legitimate need, we're happy to raise them.
While we don't have an infinite amount of developers, we do have one advantage; time. So it may take a while, but we do slowly add features while shoring up the base.
It does mean that we have to prioritize what we do, so while a particular feature may be something we'd be open to adding, it might take a long time before we get there.
Generally we prioritize X's that relate directly to the mail experience first, then mail-adjacent X's that provide significant value, and so on.
Feel free to ask us about any specific feature you have in mind.
Not at the moment, no. Suggestions may be considered.
(And no, it's not staring at you, it's politely waiting for you to move out of the way.)