General Troubleshooting Tips
Transactional Email converts all SMTP messages to an API call, as long as you've authenticated via SMTP successfully. It can be a good way to troubleshoot whether your emails are reaching Transactional Email but not being sent for some reason, or if there's an issue authenticating.
To view recent API calls, follow these steps:
- Go to Settings in your Transactional Email account.
- Click API Logs.
- Search API requests by keyword, API key used, or use the Search Logs box.
For each API call, we'll also display these items:
- The date and time the request was received (in your local timezone based on your OS or browser settings).
- The method used—this corresponds to the API endpoint that was called, for example: messages/send.
- The IP that made the API request.
- The call time for the request measured in milliseconds (ms) or seconds (s). To get this time, start measuring when we receive the request, and stop measuring when we're prepared the response to send back to the caller.
- The user agent used to make the request (for example: Mandrill-Python/1.0.56).
- A link to view the entire request and response.
Relay Access Denied or Unable to Connect Errors
If you're sending through Transactional Email's SMTP integration, you may see "Relay Access Denied" or "Unable to Connect to Host" errors when you're just getting started. This can be caused by a few things, so we'll cover some common troubleshooting tips next.
Make sure that your hosting provider or internet provider (ISP) allows outbound SMTP connections. Some shared hosting providers only allow outbound SMTP connections on dedicated servers, while others block them completely. In some cases, hosting providers might redirect the connection so instead of connecting to smtp.mandrillapp.com, you connect to their local server instead.
Make sure the port you've selected is one that your hosting provider or ISP has available for outbound SMTP connections. Some hosts block all connections on port 25, for example, so you'd want to try an alternate port.
Check that you're using a valid API key to connect via SMTP, and not the password that's used to log in to Transactional Email's web application.
If you're using Postfix, make sure you have a SASL library (like libsasl2 or cyrus) installed and that it's up to date. Otherwise, you may be connecting but not passing authentication credentials.
For other SMTP libraries, make sure that you're using LOGIN or PLAIN authentication.
If you suspect you're unable to connect to Transactional Email's SMTP servers, you can try connecting manually using telnet on your server. For example, you can open a new connection to
smtp.mandrillapp.comon any one of our supported ports (25, 587, 2525, or 465):
$ telnet smtp.mandrillapp.com 2525
If the connection was successful, you should see a response like this one (though the IP address will vary based on which Transactional Email relay server you connected to:
Trying 18.104.22.168... Connected to smtp.us-east-1.mandrillapp.com. Escape character is '^]'. 220 smtp.mandrillapp.com ESMTP
You may also try pinging Transactional Email's SMTP servers to test your connection status:
$ ping smtp.mandrillapp.com
Generally, SMTP is a 7-bit only protocol which means any non-ASCII characters need to be escaped for safe transport. For example, to send the following subject over SMTP:
Subject: Mandrill likes ASCII, but ❤ Unicode.
Encode the header according to RFC 2047 like this:
Subject: Mandrill likes ASCII, but =?UTF-8?Q?=E2=9D=A4?= Unicode.
For any non-ASCII characters in the body of your message (in either the text or HTML parts), escape those as well, using a content-transfer-encoding like base64 or quoted-printable according to RFC 2045.
Typically your SMTP library or application will handle this kind of encoding automatically.
You'll need to add SPF and DKIM records and verify ownership of your sending domains before you can send email through your account. Transactional Email will not send any email from unverified domains or domains without valid SPF and DKIM records, including public domains like gmail.com, yahoo.com, and more.
A message that is rejected with the reject reason unsigned indicates that the sending domain hasn't been properly set up, and that your account is unable to send and authenticate email from that domain.