It can be much harder to send emails today than it was in the past. Spam has become a major problem, and every provider is taking actions to curb it. Unfortunately, many of these actions can also make it much more difficult to send legitimate emails.
Many residential ISPs don't allow outgoing connections on port 25. If your residential provider blocks port 25, then you won't be able to establish an SMTP connection. In this case, you may consider renting a virtual private server to run this chapter's code.
Even if your ISP does allow outgoing connections on port 25, many SMTP servers won't accept mail from a residential IP address. Of the servers that do, many will send those emails straight into a spam folder.
For example, if you attempt to deliver an email to Gmail, you may get a response similar to the following:
550-5.7.1 [192.0.2.67] The IP you're using to send mail is not authorized
550-5.7.1 to send email directly to our servers. Please use the SMTP
550-5.7.1 relay at your service provider instead. Learn more at
550 5.7.1 https://support.google.com/mail/?p=NotAuthorizedError
Another spam-blocking measure that may trip you up is Sender Policy Framework (SPF). SPF works by listing which servers can send mail for a given domain. If a sending server isn't on the SPF list, then receiving SMTP servers reject their mail.
DomainKeys Identified Mail (DKIM) is a measure to authenticate email using digital signatures. Many popular email providers are more likely to treat non-DKIM mail as spam. DKIM signing is very complicated and out of scope for this book.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a technique used for domains to publish whether SPF and/or DKIM is required of mail originating from them, among other things.
Most commercial email servers use SPF, DKIM, and DMARC. If you're sending email without these, your email will likely be treated as spam. If you're sending email in opposition to these, your email will either be rejected outright or labeled as spam.
Finally, many popular providers assign a reputation to sending domains and servers. This puts potential emails senders in a catch-22 situation. Email can't be delivered without building a reputation, but a reputation can't be built without successfully delivering lots of emails. As spam continues to be a major problem, we may soon come to a time where only big-name, trusted SMTP servers can operate with each other. Let's hope it doesn't come to that!
If your program needs to send email reliably, you should likely consider using an email service provider. One option is to allow an SMTP relay to do the final delivery. A potentially easier option is to use a mail sending service that operates an HTTP API.