We field questions daily from customers who need to configure some special software or piece of equipment to send them email, but can’t because their SMTP logins require authentication (e.g. a username and password), or their software/hardware cannot be configured to connect to specific SMTP ports, or maybe because their logins require SSL/TLS for transmission security but their device doesn’t support that (and isn’t sending anything sensitive anyway).
Of course, software can be updated; there are always newer or more expensive devices that have more robust email sending capabilities. However, additional time and/or cost is rarely the ideal solution. If the program/device will not be sending sensitive data and the email stream does not require end-to-end protection (e.g. for HIPAA compliance), then there is a very easy work around to get the device to send your mail.
Background: How Email Delivery Works
In order to understand the solution to this problem, it helps to understand how an email message flows from sender to recipient.
- The sender uses an email program like Outlook or Mac Mail to compose and send a message
- The sender’s computer talks to the sender’s ISP or email provider, using whatever server names, ports, username and password, and other criteria that may be provided. The message is communicated to that outbound email server.
- The outbound email server uses DNS to determine what servers accept inbound email for the message recipient.
- The outbound email server then connects to one of the servers listed in the MX Records of the recipient’s DNS on port 25 without encryption (though SMTP TLS may be used). The message is communicated to the recipient’s inbound email server.
- The recipient’s servers then take the message, perform any needed filtering, logging, archival, and then (presumably) deliver it to the recipient’s inbox. In certain circumstances, the message may go “missing” due to other factors, but for our purposes here we will assume a successful delivery.
The key point here is that, in both steps 2 and 4 above, the message is communicated between different computers using the SMTP protocol. However, step 2 requires lots of information from your email provider to establish security and to prove you have permission to send the message. In step 4, no authentication is needed, no special security is (usually) needed, and communication is always on the standard SMTP port 25. Also, the number of messages that you can send in a specific time frame is typically not limited.
The Unlimited Sending Trick
So, here is what you need to do to send unlimited, unauthenticated, insecure email messages to addresses in a specific single domain.
- Server: Determine the inbound email servers for the recipient’s domain. Technically speaking, these are the MX Records located in the DNS for that domain (you can use this online tool to look these up for any domain). Simply pick one of these servers and use it as the “SMTP Server” in your device/software configuration
- Port: Always use port 25.
- Login: No username or password will be required; your program/device should have the option to allow SMTP without login authentication.
- SSL/TLS: Do not configure your device to use SSL. If your device supports TLS and the recipient’s inbound email server also supports TLS (check here), then we recommend using TLS instead of SSL to secure the email delivery (all LuxSci-hosted email domains support TLS for inbound email).
With this setup, your email program/device will behave like an actual email server. In other words, it will bypass steps 1-3 from the section above and deliver email directly to the recipient’s inbound server. By skipping step 2, you are essentially circumventing the requirements of your email provider or ISP that were causing the sending issue in the first place.
What’s the Catch?
You may be thinking that this looks a little too easy. In fact, because the SMTP email delivery protocol was developed long before security and spam became real concerns, spammers often use this exact method to deliver spam messages directly to their recipients. As a result, email providers have developed ways to defend against improper or unwanted email while at the same time allowing legitimate email flow to continue unabated. Therefore, the real trick becomes making sure your email looks legitimate so that it gets through the recipient server’s defenses successfully.
The following is a list of common delivery issues that may arise when trying to sidestep the normal outbound email process, and the solutions to them (if any).
- Sending is blocked: ISPs often block outbound email connections on port 25 to servers other than their own. This is to stop spammers from using the method described above to send spam through their servers. If your ISP is blocking port 25, then you need to either get special permission from your ISP to use port 25, use a different ISP, or find some other way to get your email program/device to send email. The trick discussed in this post will not work over any other port except 25.
- SPF and DKIM: Your email provider may have setup SPF (Sender Policy Framework) and/or DKIM (DomainKeys Identified Mail) for your outbound email so that recipients can tell if messages from you are legitimate or forged. If they have (and you should ask them if you are unsure), then the recipient’s mail servers may reject your messages as spam unless you take additional steps.
- For SPF: You need to update your domain’s DNS to add the IP address of your program/device to the allowed list for SPF. If your IP address changes frequently, then this is not an option and SPF may block you from getting your email delivered.
- For DKIM: You need your program or device to add a DKIM signature to your email (though most devices will not support this). If you have DKIM protection, you may not be able to send messages directly in this server-direct manner without them looking fraudulent.
- For Either: If you can get your recipient to “white list” your from address in his/her email filters, this may opt your messages out of their SPF/DKIM checks and let them through to their inbox anyway.
- Filtered: Messages sent directly from your program/device which do not pass though your regular outbound email service will look different to the recipient servers (beyond differences in DKIM and SPF). This may result in the message being flagged as spam or filtered in some other way. If this is happening, you’ll need to request that your recipient add your From address to his/her allow list (or add the IP address of your program/device to the allow list if that is possible).
- Rate Limited: Inbound email servers are not all-together ignorant; they do track who is sending them messages, how many, and how many at once. Different email servers will have different methods to rate limit inbound email to prevent too much email from coming in at once and to restrict spammers, viruses, and email bombs from creating serious issues. If you send many messages at once or many messages in an hour or day, you may find some of your messages rejected due to rate limiting. In such cases, it would be up to you to wait and re-send the message later. If you find this happening to you, we recommend that you contact the recipient’s email provider and discuss with them your specific mailing requirements and find a solution to get your email though without rate limiting rejections.
- TLS Required: Some recipient email servers may only accept inbound email from you if that message arrives over a TLS-secured email channel. In such a case, your direct deliveries will be rejected or will bounce. If this is happening, then you will need to use a program/device that supports TLS (many should) or find some way to send though your regular outbound email provider (providing it supports TLS, like LuxSci does).
- Encryption Needed / HIPAA. If the messages that you send need to be encrypted from sender to recipient due to regulations such as HIPAA, then you must at a minimum use TLS for the connection. You should never use this direct-sending method without TLS to get your messages through, as that would be considered willful negligence in skirting compliance requirements on your part and could bring heavy penalties on you. In general, you must use a compliant email system and ensure that every message is sent properly.
Any other solutions?
If the direct delivery trick doesn’t work, there may be other solutions. These involve getting a paid email service account with a reputable provider. For example, a LuxSci High Volume account would allow:
- Sending as much email as you need
- TLS support
- DKIM support
- SPF support
- HIPAA-compliant sending (with Premium High Volume)
- Alternate ports for sending in case port 25 is blocked by your ISP.
However, High Volume itself still requires authentication for sending. You could have authentication by your IP address (though without alternate ports, HIPAA-compliance, DKIM, and SPF) using LuxSci Outbound Message Filtering service (though our partnership with McAfee).
