Troubleshooting Email Delivery
Use troubleshooting information to identify and address common issues that can occur while working Email Delivery.
This topic provides troubleshooting solutions for problems you might encounter using Email Delivery.
Common Errors Returned by Email Delivery
For a complete list of common API email delivery errors returned by all the services for Oracle Cloud Infrastructure, see API errors.
Common SMTP Errors Returned by Email Delivery
The following table lists the common errors returned by the Email Delivery SMTP service.
|SMTP Status Code||Error Code||Description|
||Message has been accepted but a status code was returned indicating suppression.
Enhanced Status Code 4.7.1 indicated a persistent transient failure (RFC3463).
||IP based throttle; triggered by repetitive use of invalid SMTP credentials or non-approved sender.|
||An unexpected error has occurred during the SMTP conversation.|
||An unexpected error has occurred during the SMTP conversation.|
||The server is unable to persist the message in its delivery queue.|
||The SMTP send burst rate (of messages accepted per minute period) has been exceeded.|
||The SMTP daily send rate (of messages accepted per 24 hour period) has been exceeded.|
The base64 encoded AUTH (PLAIN) secret is invalid.
||The base64 encoded AUTH (PLAIN) secret does not contain NUL field separator(s).|
||The base64 encoded AUTH (PLAIN) secret does not contain second NUL field separator(s).|
||The SMTP client tried to start sending the body of an email message without identifying any email recipients through the required SMTP RCPT command (RFC 5321).|
||The client has attempted to use an unsupported AUTH mechanism with our service.|
||The client has sent an invalid AUTH command to our service.|
||The message has exceeded the size limit enforced by the service (see server response to EHLO for size restriction).|
||Authentication of the SMTP user has failed.|
||The client has sent commands that require SMTP authentication succeeded before the service is able to process (that is, commands are being sent out of order).|
Authorization of the address (either in the envelope or message) has failed for the SMTP user.
The approved sender does not exist, the
||The RFC-822 Internet Address sent by the client is invalid.|
||The RFC-2822 Internet Message is invalid (and unable to be parsed by the server).
Message without any headers or header is larger than 256 KB.
Troubleshooting Undelivered Emails
The following issues can cause an email to be undelivered:
- The recipient is on the Suppression List.
- An authentication failure or an issue with the format of the email message occurred. For example, if the SMTP "From" address is not the same as the "From" address in the email body, the email is rejected. The addresses must match and be an Approved Sender. Refer to your sending application's logs to review any issues.
- Use of multiple addresses in the email From header is discouraged. If you use multiple addresses, it increases the possibility that your mail is placed in a spam folder or discarded (because of Domain-based Message Authentication, Reporting, and Conformance (DMARC) From alignment rules). The performance of your emails is reduced because all addresses have to be authorized as approved senders. A best practice for the SMTP envelope From address is to match the header From address when you submit mail to Email Delivery. If you use mismatched addresses, it reduces the performance of your emails because both addresses need to be authorized as approved senders. Certain future platform features will not be available if you use mismatched addresses.
- Lack of DomainKeys Identified Mail (DKIM).
- View the "dkimSelector" applied to your mail via the Public Logging feature.
DKIM and DMARC can help authenticate your email to help ensure that your emails get delivered to your recipients' inboxes. For more information, see Additional Options to Increase Deliverability.
Refer to Deliverability Best Practices to learn about recommendations that can help lower your email bounce rate, stay off blocklists, lower your complaint rate, and improve your email sender reputation.
If you are unable to resolve the issue, you can go to My Oracle Support and create a service request. See Open a support service request for more information.
Email Delivery does not prohibit connectivity from any source IP range. Any IP that attempts to connect to Email Delivery will be accepted.
Refer to Configuring SMTP Connection for a list of regional endpoints to establish SMTP connections for sending.
To troubleshoot a problem connecting to endpoint network ports
- Ensure that you have the correct endpoint DNS name or IP address for the region and that you have been allowlisted to use the endpoint.
Test connectivity to the endpoint using port 25 or 587. Use a utility such as Telnet or netcat to attempt to connect to the port manually.
- Open a command prompt.
- Use the following command to test the network
telnet <SMTP endpoint> <port>
telnet smtp.email.us-ashburn-1.oci.oraclecloud.com 25
The port is open and the test is successful if you see a "Connected to" message. If you are unable to connect to the ports using telnet, you are experiencing a network connectivity issue.
To troubleshoot a problem connecting to an external mail transfer agent (MTA)
Use the following steps to determine whether you are able to communicate with an external service on the required ports 25 or 587. If you are unable to connect successfully, you are experiencing a network connectivity issue. If you are able to connect to an external MTA, the network connectivity issue is within Oracle Cloud Infrastructure.
- Connect to an external MTA such as Google's mail exchangers.
- Open a command prompt.
- Use the following command to retrieve one of Google's MX server
dig MX google.com
- Use the following command to test connectivity to the endpoint port 25 or
587 against Google's MX
telnet <IP address> <port>
If you are unable to connect to Google's MX servers, this confirms that you are having issues connecting to mail servers (port 25 or 587). It is possible that your egress rules are filtering traffic at the VCN.
If you can connect to an external MTA (that is, you are able to communicate with a public SMTP endpoint on the correct ports) but you cannot connect to Email Delivery public SMTP endpoints on those ports, create a service request with My Oracle Support with this information.
TLS errors when integrating with Postfix
If you are encountering TLS errors when attempting to integrate Postfix with Email Delivery, ensure that the following setting is removed from the Postfix
main.cffile, as it has been deprecated:
smtp_use_tls = yes
Use the following setting instead to turn on TLS:
smtp_tls_security_level = may
Using this setting, the Postfix SMTP server announces STARTTLS support to remote SMTP clients, but does not require that clients use TLS encryption.
If you want to enforce the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, use the following setting:
smtp_tls_security_level = encrypt
For more information, see Postfix TLS Support.
Troubleshooting an Inactive DKIM Key
To activate your DKIM key, you must provision a DNS CNAME record at this location in your Email Domain's DNS:
However, different DNS providers have different user interfaces to specify the location of a DNS record. Some user interfaces accept the full DNS path by default and these will work well. Some user interfaces are relative to the zone by default, so if you paste in the entire string without the trailing period, the user interface will provision the wrong location and that will leave your DKIM key in a "Needs Attention" state. Avoid entries like this:
If your Email Domain is the same as your DNS zone name and if your provider only accepts a zone-relative name, use this DNS CNAME location:
If your Email Domain is in a subdomain of your zone and if your provider only accepts a zone-relative name, use this DNS CNAME location:
For Email Delivery limits issues, see Email Delivery Service Capabilities and Limits and Service Limits for a list of applicable limits and instructions for requesting a limit increase.
When moving providers, one of the key decisions while managing your email is to choose between dedicated IPs and shared IPs to send emails. Usually, the right way to begin is to send emails through shared IPs.
Why are shared IPs preferred?
Common among email service providers, shared IPs are made up of a group of IP addresses that many different companies send through.
Using this method, customers with great sending reputations indirectly make it easier for other reputable senders who are trying to get into the inbox and build up their own reputation while doing so.
Shared IP pools are also the primary option for senders who either do not have the volume or consistent sending patterns to maintain their own dedicated IPs but are trying to build up that volume over time. Both are buoys for building and maintaining a good to, hopefully, great sending reputation.
Even if a sender starts on a shared IP range, that does not mean shared IPs are the only option for them forever. Given the right amount of volume and best practices for email marketing, a graduation plan can be established.
More on our shared pools
OCI Email Delivery has several shared IP pools based on both the type of email sent and the volume. All our pools are curated to avoid any issues and for migration of senders into other pools because of volume constraints or a ramp onto dedicated IPs.
You might understandably have some concerns and risks with sending pools. Another sender can hit a blocklist that makes the IP reputation dip or traffic can see an unexpected surge that causes some delays. However, with proper management by the teams like ours that oversee those IPs, those issues are minimalized with the benefits far outweighing any potential negatives.
Why not dedicated IPs?
Dedicated IPs are just that: Dedicated exclusively for that sender’s email only. Depending on volume, a sender can have one dedicated IP or several. They allow large volume senders to better maintain control over their own sending reputation and to have more control over allowlisting.
A certain level of high-quality monthly email volume needs to be maintained to build a sending reputation on dedicated IPs. If the volume isn’t consistent every month, shared IPs help alleviate that issue.
Consistency and cadence with that level of email is necessary to both build and maintain an IP reputation. If the sender does not have a regular schedule for bulk or marketing deploys, shared IPs help alleviate that issue.
Full control over DNS settings is a must when sending through either shared or dedicated IPs because senders need to be able to make specific updates that better align to their sending domains and improve reputation.