This is a summary of questions that we've received to our support, intercepted from Reddit, et cetera. Please contact us if you have a question that this page doesn't answer.Contact support
$0.0005 per hour for each email address (which sums up to $0.36 for a full month). In other words, billing is calculated per hour, and charged per month.
We add features to the control panel all the time, and it currently support signup, adding domains, changing destination server address and port, tracking messages, viewing statistics and configuring accounts and account lookup method.
A message may be at most 50 MiB, when attaching files within an e-mail message they will be larger than on disk. The general rule is that files become 1/3 larger in size, so you will only be able to send files up to 30 MiB.
Otherwise someone could add for example hotmail.com, point it at Hotmail's server, and send "outbound" messages.
Either by manually populating the list of valid addresses for your domain, or enabling automatic address creation using "SMTP callout" (requires billing to be enabled, but doesn't cost extra). Some servers, such as certain versions of Microsoft Exchange, doesn't support rejecting invalid users, making SMTP callout ineffective. In that case, you can export all addresses using the Windows command ldifde -f filename.txt -l proxyaddresses -r "(proxyaddresses=*smtp:*@*)" and manually add those addresses to the list.
By default, you don't have a spam folder. We simply reject everything we
believe is spam, thus notifying the sender that the message wasn't delivered
with a link so that the sender can report the incident. If you want to use a spam
folder, containing a copy of each spam that was rejected, simply change spam action
to "reject but deliver with tag". Each message will be tagged with a header called
and you can create a rule in your email server or client application to place those
messages in a spam folder. If you use for example Postfix with procmail, you can create a
rule such as
:0 * ^X-Inumbo-Spam.* .Spam/
Most importantly, disable SPF checks in your server. It might also be a good idea to disable any anti-spam in your server, in case it would start rejecting messages from us.
In most cases, it's sufficient to change the mail server port from 25 to something random, and make Inumbo deliver the messages to that port instead. If you really want to fully prevent delivery from other sources, you can send the messages with SASL authentication. We don't recommend filtering by IP address, because they could change at any time. However, traffic from Inumbo is generally sent from the IP addresses that the MX (such as foo.bar.us1.protection.inumbo.com) resolves to.
In theory, thanks to its design, email (SMTP) can be made fully redundant, with 100% availability. We try to achieve that by using different DNS providers (on different TLDs) and deploy many nodes in each mail cluster, in different cities, and sometimes mixed providers (depending on your preferences; there's a trade-off between vendor trust and availability). This page will be updated with a specific SLA.
Yes, and you probably should. After adding, verifying and configuring a domain, you can connect to the hostname that your domain's MX should point to using for example nc or telnet and try sending a message using SMTP commands, for example:
$ nc example.com.us1.protection.inumbo.com 25 220 us1-rack-iad1.inumbo.com ESMTP mail from: <> 250 2.1.0 Ok rcpt to: <firstname.lastname@example.org> 250 2.1.5 Ok data 354 End data withand make sure that it's delivered. You can check the email tracking page for debugging.
. subject: test test . 250 2.0.0 OK: queued as fb3ad2a4-0b5f-11e5-8514-c53e51fb8e7e
One of our clusters are hosted at Bahnhof, a privacy-oriented Swedish "Free Speech ISP". Unlike our other mail cluster, it doesn't store or submit any logging data, making it impossible to for us, or anybody else, to retrieve email metadata historically. Thanks to the transaction safety of SMTP (and Inumbo), the absence of logs doesn't pose a significant disadvantage (because the sender is always made aware of a message not being delivered).
Google Apps, in order for you to contact us even in the unlikely event that all our providers go dark simultaneously.