2

We have several users that complain about not receiving only some of the emails our webservers send through AWS Simple Email Service. Most of those users not receiving emails are users with hotmail.fr email addresses.

We are currently using AWS SES without dedicated IP addresses (I'm in the process of collecting info whether using dedicated IP addresses could be a good solution).

The reputation of said emails is 9.9/10 according to mail-tester.com (DKIM, etc. are already enabled), and we're talking mainly about transactional emails here, so I don't think the problem comes from the quality of the email.

I have sent a support ticket to AWS and they replied the following

In regards to the list of messages to hotmail addresses in which you kindly provided, I have run a log dive on each of the emails and noted the following during my analysis:

Each of the messages was sent by '@.com' and returned a 250 SMTP status code. This means that the SES endpoint successfully delivered the email to the recipient mail servers. However, each of the emails that were sent to hotmail domains also returned with the message ' SMTP response message: Queued mail for delivery -> 250 2.1.5'. This includes emails sent to '*@hotmail.com, *@hotmail.fr, ***@hotmail.fr etc'.

As SES successfully sent each of the emails and because we have no further visibility into how the recipient server 'hotmail' deals with request and why is was queued, it is not possible for me to say why the Microsoft mail servers did not forward the email to the recipient.

As only Microsoft (hotmail) and Google (gmail) will have more information as to why the messages were queued, I would recommend reaching out to the respective teams to find out more information. Each Email Service Provider has their own rules and policies in place, and they have the last word regarding how the email is going to be accepted, rejected, queued or classified.

I am still in the process of figuring out how I can contact Microsoft/hotmail regarding this (I'm trying to find the appropriate contact form but is seems I cannot find the appropriate catrgory). In the meantime I'm also trying to find some stuff regarding this famous 250 SMTP code, but is feels like it's quite similar to a 202 Accepted HTTP code in a sense that the delivery actually worked, yet our users still don't receive the messages)

If you could help me shed some lights on this 250 SMTP code OR if you've veer had any experience with debugging users not receiving emails, I would gladly take the help.

  • The user needs to check in their "Junk" folder. – Michael Hampton May 1 at 19:18
  • We tell them to check there too, but it's not in there either apprently – Cyril Duchon-Doris May 1 at 19:51
  • Please contact hotmail, the server seem to tarpitting you. Check your sender IP reputation to be sure no mass spam was used from that IP – yagmoth555 May 1 at 21:58
  • @yagmoth555 do you have any idea how I should contact Microsoft about this ? I can hardly find any support email and the pages I find on their website require me to pay 300$ for company support before I can submit a ticket... – Cyril Duchon-Doris May 15 at 11:53
2

To contact Microsoft for removal from their internal blacklists you need to use this form: https://support.microsoft.com/en-us/supportrequestform/8ad563e3-288e-2a61-8122-3ba03d6b8d75

Provided you are honest in your submission, are not in fact sending spam, and have configured your domain and mail servers correctly you can expect to be removed in 2-3 business days.

Before contacting Microsoft:

  1. Check other blacklists to make sure you're not on a public list (MXToolbox and other sites offer easy lookup tools.)

  2. Make sure your mail server isn't actually being used to send spam (open relay.)

  3. If you are sending bulk or transactional email make sure you're following best practices:

    • Authenticate you email with SPF, DKIM, and DMARC (SPF at a bare minimum.)
    • Include an unsubscribe mechanism for bulk mail. (Includes an in-message link and the List-Unsubscribe-Post and List-Unsubscribe headers.)
    • Don't send email to dead addresses. One mistake bulk senders and transactional senders make is continuing to send to an address that doesn't exist anymore. The big recipients like Microsoft and Gmail will often lower the reputation of senders who do this.
    • Use different sending addresses for bulk mail and transactional mail and be consistent.

Microsoft has a deliverablity guideline document: https://docs.microsoft.com/en-us/office365/securitycompliance/reference-policies-practices-and-guidelines and Google's guidelines for bulk senders also contains good universal advice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.