In the vast majority of cases this is simply due to a bad DNS configuration. Please check out our DNS settings page. You might also find one of the following domain provider guides helpful:
To test your setup, have a look at "How do I know if my DNS is set correctly?" below.
There are many reasons why your emails may be classified as SPAM. Here we outline the most common ones.
If your (non SPAM) emails get delivered but end up in your recipients SPAM folders, this is most likely due to a misconfiguration (or lack thereof) of your DNS SPF record or your DNS DKIM record, or both.
To fix your DNS setup, please see "How do I know if my DNS is set correctly?".
Have you recently fixed your DNS records but your emails are still seen as SPAM? Your changes may have not fully propagated yet. In most cases changes propagate within a few hours, but in some rare cases you may need to wait up to 48 hours.
Some mail services classify all emails sent from recently registered domains as SPAM by default. Some domain reputation lists such as Spam Eating Monkey even list these domains. Additionally, domains not that recent but having never sent emails before may also see their emails considered as SPAM.
Such behavior has been observed with large mail services, in particular with Gmail, Outlook, and Yahoo.
If that heppens to you, the solution is to mark a few of these emails as non SPAM, from the recipient side. If you can't ask your recipients to do so, you can do it yourself by sending to your own @gmail.com/@outlook.com/@yahoo.com addresses.
That action teaches to these services that emails originating from your domain are actually legitimate, and the issue usually resolves itself within a day or two.
Another possibility is that your domain has a bad reputation due to a bad email activity in the past (i.e. email addresses of that domain used to send unsolicited emails).
Have a look at common blacklists, look up your domain reputation, and if you see your domain listed somewhere, ask for a delist. Of course this won't work if your domain continues to send unsolicited emails.
It goes without saying, but unsolicited emails or emails with spammy or fraudulent content are most often classified as SPAM. The same applies to malformed emails (are you sending that email programmatically?).
Not only such emails are unlikely to reach to your recipients' inboxes, but they also hurt your domain reputation. And perhaps more importantly, at postale.io we do not allow the sending of unsolicited emails. If you do, you run a high risk of being blocked by our system.
If you have mass emailing/marketing needs, we strongly recommend the use of third-party services built for that purpose, such as Sendgrid and the likes. Those can easily be used alongside our service for your regular - human sent - emails (see here for some guidance).
Finally, if you send emails from a third-party service (Sendgrid, Wix, ...), you'll need to adapt your SPF record and add another DKIM record so that these services are recognized as legitimate senders of your domain name. Have a look here.
If you've haven't verified your MX record yet, please visit https://postale.io/fr/configure/yourdomain.com to verify your MX record first (replace yourdomain.com with your actual domain name).
Once your MX record is verified, login to the admin panel with an administrator address and click on the DNS diagnostic button in your domain page. This will show you everything you need to know about your domain DNS settings and what you need to fix.
For alternative ways to check if your records are set properly, you may use third-party testing tools, such as dnschecker.org or the excellent mail-tester.com.
The Domain Name System is a service acting as a directory for websites and other internet services.
When you enter the name of a website in your web browser, say "google.com", your browser first asks to a DNS server where it can find that site (i.e. what's the IP address of the web server serving that particular site).
The same thing goes for emails. When you send an email to someone, say to "maryline@poupoupidou.com", your email client (Gmail, Outlook, ...) first asks a DNS server where to actually send the email (i.e. what's the email server handling emails for "poupoupidou.com").
Thus, any domain with email addresses needs a DNS configuration. That configuration takes the form of textual records on DNS servers hosted by your domain provider.
If you're using postale.io for your domain emails, you need to set your domain DNS records so that email clients everywhere in the world know that emails sent to your domain are handled by postale.io email servers. Usually, only people knowing the domain provider (a.k.a registrar) credentials used to purchase a domain name have the ability to edit the DNS records of that domain.
The main DNS record for emails is called an "MX" (Mail eXchange) record. For websites, it's called an "A" record. There are many more records for different purposes.
To configure your DNS properly for postale.io, please visit our DNS configuration guide. To learn more about DNS records, check out our blog post "DNS Records Explained".
It's the DNS record for email servers. It tells what email server(s) handle emails for a given domain name. That record is absolutely required to have working domain email addresses.
To know the right MX record you need in order to use postale.io, please have a look at the DNS configuration guide. More information about MX records can also be found in our blog post "The MX Record Explained".
This is another DNS record used for emails. Quoting Wikipedia: "Sender Policy Framework is an email authentication method designed to detect forging sender addresses during the delivery of the email.". An SPF record basically tells which servers/services should be allowed to send emails on behalf of a domain name.
If your domain has an SPF record and an unauthorized server tries to send an email from an email address using your domain name, that email will get a bad score from the recipient service anti-spam and will likely be either rejected or classified as SPAM. On the other hand if an email is sent from an authorized server, it gets a good score and a lesser chance of being seen as SPAM.
To know the right SPF record you need to use for postale.io, please have a look at the DNS configuration guide. You can also learn more about SPF in our blog post "The SPF Record Explained".
DKIM is another DNS record used for emails. Quoting Wikipedia again: "DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails [...].".
A DKIM record allows the recipient mail service to verify the email did originate from where it claims it did and wasn't tampered with. DKIM does so by applying an encrypted digital signature to the email which can be verified by the recipient mail service. Similarly to the SPF record, it gives the emails you send a better score and a lesser chance of being seen as SPAM, and protects you further from impersonators.
To know the right DKIM record you need to use for postale.io, please have a look at the DNS configuration guide. And if you'd like to better understand DKIM, have a look at our blog post "The DKIM Record Explained".
Yet another DNS record to protect your domain email addresses from spoofing, DMARC allows you to apply a policy on unauthorized senders.
SPF and DKIM provide information to the recipient mail service on the legitimacy of an email, but you have no control on what the service does to emails failing at these tests.
DMARC solves this by allowing you to really instruct the recipient mail service what to do with suspicious emails. Not only that, but DMARC also makes SPF and DKIM stricter, preventing spoofing of what's called the "From" header field. Finally, DMARC provides daily reports of sending attempts made with your domain email addresses, and their outcome.
We recommend the use of DMARC along with SPF and DKIM. The combination of those three mechanisms ensures the best possible protection against abusers, thus preserving your brand and improving your domain emails deliverability.
To find out the correct DMARC record to start with, please see the DNS configuration guide. And to learn more about DMARC, check out our blog post "The DMARC Record Explained".
Technically, they're not. Only the MX record is required. But SPF, DKIM, and DMARC are strongly recommended, as without them the emails you send have a much higher chance of being considered as SPAM. If you set those records, it's very unlikely than any (legitimate) email you send land in the SPAM folders of your recipients. To know the correct records you need to use our services, please have a look at our DNS configuration guide.
If you're using a third-party email service like Sendgrid, Shopify, another service or your own server to send emails from @yourdomain.com email addresses, you'll need to include that into your SPF record.
Simply add "include:some.third.party.server.com" right before "~all" in your SPF record. Like so:
"v=spf1 mx include:some.third.party.server.com include:some.other.server.net ~all"
The SPF record above includes the SPF records of some.third.party.server.com and some.other.server.net, which themselves allow some servers to send emails on behalf of your domain name (i.e. from @yourdomain.com email addresses, where yourdomain.com is your domain name). The "mx" part says the server specified in your MX record (which in your case is "mail.postale.io", our service) is also allowed.
If you're using Sendgrid, your SPF record should look like this:
"v=spf1 mx include:sendgrid.net ~all".
Or see Sendgrid's documentation.
If you're using Shopify, your SPF record should look like this:
"v=spf1 mx include:shops.shopify.com ~all".
Or see Shopify's documentation.
You should also avoid using "reply-to" email addresses having a different domain name than the "from" email address. This tends to raise anti-spams red flags, especially if your SPF doesn't allow the sending server to send emails from your domain name. This could mean someone is not only trying to impersonate you/your company but is also trying to get replies (i.e. it looks like a phishing attempt).
Open your email client, and find the menu/button to add an account. The interface will ask for your username (that's your full domain email address) and your password. Enter them.
From there, most commonly used email clients should be able to autoconfigure everything for you, thanks to our built-in autoconfiguration feature. If they don't autoconfigure, they'll ask you to provide some settings instead. Namely: SMTP server and port, POP or IMAP server and port, and SSL/TLS settings. All the settings you need to do that are provided on our email client configuration guide.
Sure! Open Gmail and click on Settings > Accounts and Import > Check mail from other accounts > Add a mail account. Enter your domain email address and follow the steps.
When asked to enter your username, enter your full domain email address again (that's including the @yourdomainname.com part). Other settings you'll need are listed here. Please note that Gmail only supports POP.
You'll find a detailed guide on our blog post "How to Use Your Domain Email Address on Free Gmail", and some information from Google here.
Yes, absolutely. However, please note that profile pictures actually depend on the email client used by your recipients.
With Gmail for instance, only people using Gmail to open your emails will see your Google account profile picture (or people using another email client also showing up the Google profile picture). If you'd like that to happen with your domain email address as well, you have two options:
You can create a signature on the email client you're using to send emails from your domain email address.
For instance on the webmail you can do so from Settings > Identities > your email address > Signature. That signature will only be used when you send from the webmail though.
If you send from another email client, you'll need to create a signature there instead.
Push notifications (a.k.a device synchronization) are supported via two distinct systems. Depending on how you add your domain email address to your email client, you'll automatically be using one or the other:
IMAP IDLE is used when you add your domain email address to your email client the usual way, i.e. as an IMAP account, if it supports it. The extension was created back in 1997 and most clients today do support it.
Exchange ActiveSync is used when you add your domain email address to your email client as an Exchange account. EAS is also widely supported.
We recommend using IMAP IDLE. It's more of an open standard, and support for EAS is shrinking overtime, with Microsoft itself having started retiring it. We'll likely stop supporting it as well in the future.
You may want to have some from/sender/display name for your domain email address, so that your recipients see that name when they get your emails. This can be set in your email client, usually via an account setting called "name" or "display name".
In the webmail for instance you can do that from Settings > Identities > your domain email > Display Name. Please note this will only apply to emails sent from the webmail. Similarly if you set a display name in an email client (say Gmail or Apple Mail for instance), that name will only be used when you send emails from that client.
There's just one exception to that rule. If you're using your domain email as an Exchange account (to enable push notifications), some apps don't offer a display name option. That's the case for the iOS Mail app for instance. As a fallback solution, and in that case only (an Exchange account without a custom display name), the webmail display name will be used instead, if you've set one.
Most email clients can autoconfigure themselves from only your domain email address and password.
To benefit from this feature your domain DNS must have two CNAME records respectively named "autoconfig" and "autodiscover", both pointing to "mail.postale.io". See the DNS guide or the DNS diagnostic tool for details.
Whenever you add your domain email to an email client, the client looks up if your domain has autoconfiguration DNS records that point to something (e.g. autoconfig.yourdomain.com or autodiscover.yourdomain.com that point to a server).
If you have set up autoconfiguration, that succeeds, and the client then fetches an XML configuration file from the server your autonconfiguration DNS records point to.
The file contains all the settings that the client needs (e.g. SMTP host and port, IMAP/POP host and port, and TLS/SSL policies), thus the client can autoconfigure itself without you having to manually enter all the settings yourself.
The exact XML file fetched depends on the client, but below are the main possiblities (here with domain postale.io):
You can click on them to see for yourself that these files simply list the client settings to be used with postale.io, in various formats.
First you should know that not all email clients support autoconfiguration. Some of the clients known to support it include: Thunderbird, Gmail, Spark, Outlook (though that one is not always reliable). If your email client is supposed to support it, you need to configure your domain DNS to enable the feature.
If it still doesn't work, please make sure there are no other DNS records interfering. Some domain providers prefill email related records and that can break autoconfiguration. In particular:
Or, if you're familiar with the records listed above, you can alternatively configure them to use our service. If not, better to remove them, as they are not required.
Outlook autoconfiguration issues
If you're still having issues making it work with Outlook, that may be due to "AutoDetect". It's a service introduced in recent years supposed to improve autoconfiguration, but which is currently not reliable, with known issues that only Microsoft can resolve on their end.
A workaround is to disable the new account setup wizard that uses the AutoDetect service, reverting to the classic wizard with classic autodiscover. But this kind of defeats the purpose of autoconfiguration, which is to not have to configure anything in the first place.
We support calendars and address books through the DAV protocol (CalDAV and CardDAV). What this means is that we provide DAV servers for your calendars and address books. However, we do not provide any DAV client, and it's unlikely we ever will (we focus on emails).
You can use your DAV calendars and address books with any DAV client of your choice. Popular apps include iOS/macOS's Calendar, Thunderbird, OneCalendar, and the Vivaldi browser. Know another great DAV client? Feel free to share!
Note that the webmail also offers an address book. At this time, that address book is entirely separate and unique to the webmail. It is not linked to your DAV address book.
Click the sign up button in the top menu, and fill in the two-fields form. That will create a free trial account and your first domain email address in one shot.
You'll be asked to configure your domain MX record. Once that's done you'll be given access to the admin panel where you can easily manage addresses and/or upgrade your plan.
For a full guide, have a look at our blog post "How to Create a Business Email Address for Free in 3 Easy Steps".
At registration you provided us with an existing email address we can use to contact you if needed. For instance:
Since we need a way to reach you even when your domain email addresses don't work (e.g. bad DNS setup), the contact email should be a working external address (i.e. not one created on postale.io with your account).
You can change that contact email address at any time from the Account page on the admin panel (visible to administrators only).
You can downgrade or upgrade your plan at any time, from the plan page in the admin panel. We'll automatically charge you prorated amounts for the time spent on each plan.
Sure! Login to the admin panel and click on Domains > Add a domain. Enter the domain name you want to bring in and follow the ownership verification step.
This will attach the domain with all of its mailboxes and aliases to the upgraded account, just as if you had created them from that account directly. You'll then be able to manage that domain and create more mailboxes and aliases for it with your upgraded capabilities.
You can fully remove your postale.io account (all domains, addresses, paid subscription, ...) from the Account page on the admin panel. That page is accessible by administrators only.
Beware! This action is not reversible. Once your account is deleted, all of its data (including emails) is forever lost.
Branding, or white labeling, allows you to customize the acces and appearance of our service to display your brand or the brand of your users instead of the postale.io brand. Branding applies per domain, giving you the ability to set up different brandings for different organizations on a single account.
This feature is often useful for companies and resellers (web agencies, freelancers...), who are interested in using postale.io as the email provider for their employees or customers.
Login to the admin panel and go to Domains > yourdomain.com > Edit branding. There you'll find:
Your users can then access the branded webmail from https://mail.yourdomain.com, and use mail.yourdomain.com in their email client settings in place of mail.postale.io.
It got turned into the 1 $US Base plan (with a 30 days free trial), for new registrations only.
Why? Well our free plan got very popular and it started to grow a little too fast for us to keep offering it while maintaining quality of service. Nothing is set in stone though and depending on how our capabilities evolve we may or may not offer another free plan in the future.
If you registered to a free plan when it was offered, no worries, it stays free and nothing changes for you!
Sure! You are absolutely free to resell domain email addresses however you like.
In fact, a significant part of our user base is made of web agencies and other IT professionals who use postale.io for their customers' domain addresses. If you're a reseller, you may be particularly interested in the following features:
On your admin panel. Only if you are an administrator will you be able to act on other email addresses.
Connect to your admin panel with an administrator address. Click on your domain then on 'Edit settings', check 'Catch-all' and choose a target address.
Currently only Premium plans and above allow multiple domains in a single account. If you have such a plan, login to the admin panel and click on Domains > Add a domain.
You can delete a domain from its page on the admin panel, but only when you're logged in with a full admin address of a domain other than the one you want to delete.
If you don't see the delete option, you probably don't satisfy that requirement. It's there to ensure your account always has at least one full admin address, since deleting a domain also deletes all of its addresses.
On the webmail, in Settings > Filters, or on your admin panel, see the 'Filters' section on the email address settings page.
Sure! You can easily make rules from the webmail, in Settings > Filters.
For instance you could make a rule to automatically remove all emails containing a particular text, or having a particular subject, or sent from a particular email address. Or automatically move them in say the Trash folder.
That filtering interface in the webmail is very intuitive to use and requires no knowledge. When you make a filter with it, behind the scene it writes in the Sieve script of your email address.
If you need more advanced rules, you can also direclty write in the Sieve script yourself. That's done from the admin panel, in the email address settings page, click on the 'Custom filter' button within the 'Filters' section. Since both the webmail and the admin panel write in the same Sieve script, you can interchangeably use both ways to make rules.
30 days! All emails in the Junk and Trash folders older than 30 days are automatically deleted. This is a common practice, helping you to keep your storage usage under control.
Yes! We support sub-addressing with the "+" (plus) character.
For instance if you created an email address john@wayne.com, any email sent to an address of the form john+tag@wayne.com will be received by john@wayne.com as well, with tag being any word you like. You can even use multiple tags, like john+west+saloon@wayne.com.
You can easily import or export emails from the webmail. To export emails, select the emails and click on More > Download. Emails can be exported in the Eml, Maildir, or Mbox format.
To instead import emails, click on More > Import. Supported formats for imports are Eml, Mime, and Mbox. Multiple files can be compressed into zip archives. Each file you upload must be under 100 MB, but you can upload multiple files at once (you can split a large archive into smaller ones).
This is with our webmail, but most email clients offer similar import/export features and can be used as well.
One manual way to migrate a mailbox is to use emails exports/imports. You can use an email client like Thunderbird to export emails from the source service into an archive. Many mail services also offer built in export features in their web interfaces.
You can then re-import the archive into your mailbox on postale.io.
Another, more automated way, is to use a migration tool. We recommend imapsync. It's free, open-source, widely used, and pretty straightforward. For instance, to migrate an address abc@alphabet.com with password mYpAsSwOrD from Zoho to postale.io, first recreate the mailbox on our service, and then run:
imapsync
--host1 imap.zoho.com --user1 abc@alphabet.com --password1 mYpAsSwOrD
--host2 mail.postale.io --user2 abc@alphabet.com --password2 mYpAsSwOrD
If you're not familiar with the command line or don't feel like installing the software, imapsync also provides an online interface. It's very easy to use and free for migrations under 3 GB. If you use that online version, we recommend that you change the mailbox password afterward, for extra safety.
By default imapsync will attempt to fully replicate all folders and emails. If you need finer control, the command line tool has many options, like copy only some folders or emails based on various criteria (size, age, ...).
After impasync has finished, you may need to close and reopen your email client or refresh your webmail page in order to see all the changes, especially if new folders were created on the destination mailbox.
Check out our blog post "3 Easy Ways to Migrate Business Email Addresses Between Services" for more information.
If your email delivery fails for some reason, you'll get an error email back, sent from something in the lines of system@mail.postale.io or postmaster@yourdomain.com. That email states that the delivery failed and for what reason (e.g. the recipient address doesn't exist, its mailbox is full, ...).
In most cases the failure reason is actually provided by the recipient mail service, and our service simply informs you about it. In such cases we are not responsible for the pertinence or accuracy of the given error.
In rare cases, the recipient's mail service may not provide any errors, although the email was actually rejected. This is usually because the recipient's mail service considered the email to be SPAM that was not worth delivering, but it does not want to inform the sender. This is a choice of the recipient's email service, over which no one but that service - including us - has any control.
Sometimes you want to get notified whenever you recipient has opened or read your email. This is often called "return receipt", "read receipt", or "email tracking". There are two main ways of achieving it:
This is a feature of the SMTP protocol, the protocol used to transmit emails. You can use that feature if both your email client and the one of your recipient support it. For instance on the webmail, before sending your email, enable the "Return receipt" option on the right options panel. Similar options exist on other email clients.
When an email was sent with return receipt enabled, and if the recipient email client supports that feature, when said recipient opens the email, his/her email client informs him/her that the sender asks for a return receipt.
The recipient can then choose to either accept to send the receipt, or ignore/refuse it. If the recipient accepts, the sender gets an email back stating that the email was opened by the recipient. If the recipient refuses, well, nothing happens.
As you can see this is not very reliable:
On the other hand, this approach is respectful of the recipient's privacy.
A more powerful way is to instead rely on an invisible 1x1 pixel included in emails you send. That pixel is usually provided by a third-party service, and contains a bit of code. Whenever an email containing it is opened, the associated service collects information and sends a receipt email to the sender.
This technique is more invasive. While useful for marketing campaigns, we discourage its use in most cases.
At postale.io we do not provide tracking pixels, mainly for privacy reasons. There are however good services out there providing them. A popular one is pastepixel.com.
You can delete an address from the address page on the admin panel, but only under the following conditions:
If you don't see the delete option, you probably don't satisfy these requirements. They're here to ensure your account always has at least one full admin address.
If instead you'd like to delete your entire account (i.e. all domains and addresses), please have a look here.
Your username is always your domain email address. For your password:
Note that you can always change your password from your admin panel.
Same answer as for the admin panel. The credentials for the webmail and the admin panel are always the same.
If you are a full admin (usually the domain email you created your account with, though other admins can be added later), you can get a password reset link from the password reset page. Alternatively you can contact us.
If you're a regular (i.e. non admin) user, please contact your administrator, as they can reset your password from their admin panel.
If you're absolutely certain you're using the right credentials to login but it's not working anyway, it means an administrator has changed your password. Please contact an administrator.
From the admin panel, in your mailbox page if you're an admin, or in the 'Password' page otherwise. Credentials are the same as for the webmail.
If you're not an administrator, your admin panel will only allow you to modify settings related to your own address: change your password, set an out of office automatic reply, etc.
A non administrator does not have access to any action on other addresses of the domain or on the domain settings. Only administrators have such options.
Want to enable 2FA on an address? Easy! Login to the admin panel, open the address page, and click on the 'Edit 2FA' button.
There you can choose between Google Authenticator or email as the second authentication method. Enter the verification code, and "voilà", 2FA is enabled on the address. You can change the method or disable 2FA at any time by going back to that 2FA settings page.
Please note that 2FA only applies to web interfaces (webmail and admin panel), not to email clients.
We currently support the following payment methods:
The availability of methods other than cards depend on your location and device. See below for more information.
You can choose a payment method when subscribing to a paid plan for the first time, or when updating your payment method if you subscribed already.
However, please note that some payment methods may not be available to you, depending on your location and device. Using a card is the only method that is always available.
This method is always available.
This method is not always available. If the option doesn't show up, it's not available to you.
There is often a workaround though: if you see the Google Pay or Apple Pay option and have a PayPal card in your Google/Apple Pay account, select Google/Apple Pay as payment method and then select the PayPal card when Google/Apple asks you to choose a payment method.
This method is not always available. If the option doesn't show up, it's not available to you.
It can also be used to pay with PayPal indirectly (see 2. PayPal above).
This method is not always available. If the option doesn't show up, it's not available to you.
It can also be used to pay with PayPal indirectly (see 2. PayPal above).
This method is not always available. If the option doesn't show up, it's not available to you.
Yes.
Safely handling payments is a whole field we don't master and don't want to tackle. Instead, we're delegating that part to Stripe, one of the major and most trusted payments processing platforms out there.
Being widely used by small and large companies across the world, Stripe maintains high levels of safety measures, both legal and technical.
On the legal side, some notable feats are Stripe having a PCI Service Provider Level 1 Certification (the highest level of certification in the payments industry), Money Transmitter licenses, and being FDIC insured. On the technical side, Stripe forces HTTPS on all communications via HSTS, and encrypts sensitive data at rest with an AES-256 algorithm, amongst many other security measures.
Find out more from Stripe's security documentation.
No.
This may come as a surprise if you have subscribed to a paid plan, as you are billed automatically every month or year, and you may have seen your credit card or other payment method being preset in the billing tab of your plan page.
We delegate payments processing to Stripe, a third-party service specifically designed for that purpose. When you enter your payment details, you are actually providing them to Stripe, not to us. They are the ones processing your payment method on our behalf.
We never have access to your payment data ourselves, and never will. Stripe simply provides us with an arbitrary ID identifying your payment method on their platform, along with some basic information to help you recognize it (last four digits of credit card, PayPal email address, ...). That's what we display on the billing tab.
Stripe has to store your payment method details in order to automatically charge it for your subscription renewals. As a payment platform, Stripes takes safety of such data very seriously, with for instance AES-256 encryption at rest. Find out more about Stripe's security here.
When you delete your postale.io account, your Stripe data is also deleted, including any payment method information.
Go to the billing tab of your plan page, and click on the Edit button of the "Payment method" section. The new payment method you provide will be used for all future invoices.
You can change some of the billing information that appears on your invoices:
To set these, go to the billing tab of your plan page, and click on the Edit button under the Billing information section.
Changes apply to all past and future invoices, with the exception of the tax ID which applies only to future invoices. By default, only the billing email address is set (to the one from which you first upgraded).
When you subscribe to a paid plan for the first time, you are instantly billed for the first cycle (month or year). You are then billed every cycle on the same day for the subscription renewal. For instance if you subscribe to a monthly plan on February 15, you'll be billed on the 15th every month.
If you downgrade back to the free trial before the end of a billing period, you are not refunded for the remaining part of the cycle. However a subsequent re-upgrade to the same plan won't trigger any additional charge, as you have already paid for the cycle. A re-upgrade to another plan will also take into account the amount already paid.
Either downgrade back to the free trial, or delete your postale.io account.
You are always billed to the prorata of time you spend on each plan.
For instance, let's say you subscribed to Premium at 5 $US/month on March 1st, and you upgrade to Premium Plus Small at 10 $US/month on March 15. On March 1st you were billed 5 $US. On March 15 your invoice looks like this:
Similarly, when you downgrade to a lower cost plan any overpaid amount is considered as credit that will be deduced from future invoices.
Every cycle (month or year) your payment method is automatically charged for your plan renewal. At some point a payment may fail for any reason (insufficient funds, card is expired, ...).
If that happens you'll be notified of the failure via email. The payment will be retried automatically a few times over several weeks, during which your plan stays active as usual, giving you time to take corrective action (manually pay the invoice or change your payment method).
After all retries have failed, your plan will be deactivated. This means you won't be able to send or receive emails with your domain addresses anymore. You'll still be able to access your mailboxes and the emails already in it.
You can easily reactivate a deactivated plan at any time (or upgrade/downgrade to another plan) from the plan page. That will resume your subscription, and instantly bring your email capabilities back. Please note that the period of time during which your plan was past due but active (a.k.a. grace period) is still due.
You can find your invoices in the billing tab of your plan page.
Only invoices with status "open" or "uncollectible" can be paid. On your invoices list, simply click on the invoice you wish to pay. It will open a page where you can provide payment details to pay the invoice.
Manually paying an invoice is useful if a renewal payment failed and you want to make sure the invoice is paid before your plan gets deactivated.
Our company being registered in France, only consumers in the EU are subject to VAT.
No. Cold or unsolicited emails are generally considered SPAM, and services allowing these emails understandably get a downgraded deliverability.
As a domain email service, maintaining a high deliverability to all of our users is of paramount importance. Consequently, our terms of service forbid sending any form of unsolicited emails.
Please note that accounts violating this policy will be blocked.
No. We're not a mass emailing service, which is one of the reasons we're able to maintain a good reputation and a high deliverability.
For mass emailing or marketing needs, we recommend the use of third party services built for that purpose, such as Mailchimp, Sendgrid and the likes. These can easily be used alongside our service for your transactional emails (see here for guidance on SPF configuration).
No. Warm-up emails are generally frowned upon if not out right banned by legitimate email services, as they represent an attempt to artifically improve a sender reputation in order to circumvent SPAM filters. It's a technique mainly used by cold emailers.
As an example, in 2023 Google forced multiple email services to stop their warm-up activity through Gmail, as it is in violation of their policy. Here are a few blog posts from services announcing the shutdown of their warm-up offerings as per Google's request:
As a legitimate email service ourselves, we have to abide by the same rules. Therefore, sending warm-up emails from our service is forbidden, along with any form of unsolicited emails.
There are no fixed rates or limits. Instead, an email address, a domain, or an entire postale.io account can be blocked for sending any amount of unsolicited emails, which our terms of service forbid.
The general idea is that legitimate use should not be impeded, while abuses should be blocked. To achieve that, we maintain a variety of mechanisms. These may include but are not limited to rates or limits that vary depending on many factors.
This is part of our internal protection against abusers and shoulnd't impact any "normal" usage. If you have particular needs and feel like you are limited in some way, please contact us.
Some example of what can be considered as abuses are sending fraudulent emails, unsolicited emails, warm-up emails, or large emailing campaigns.