Weird transactional email question

(Andrew Stroup) #1

Sooo … I’ll start off with “I thought I had a good understanding of how to setup SES or Mandrill”, but apparently I’m missing something here.

So to preface my setup is > AWS (EC2, Redis, postgres) > because of the constraints of my organization.


When setting up the Discourse server I used SES and my account (let’s call it for simplicity), which was added using the ‘Verify a New Email Address’ process for individual email addresses.

The SMTP settings within app.yml look like the following:


Using the account, I am able to successfully:

  • send an email to other email addresses
  • send emails to my domain email addresses

I then use my (successfully verified by SES) with Discourse and here’s what happens:

  • I can send emails to accounts
  • BUT not to email addresses (including the one I’m sending it with).

NOTE: Neither or are verified domains within SES.


My organization also has a Mandrill account used across the organization by several different domains (successfully). I have done the following:

  • added to the list of sending domains
  • have verified the domain and DKIM but receive an SPIF error because it’s not a top 10 record)
  • created an API key and added the updated SMTP info into the app.yml file, which looks like the following

DISCOURSE_SMTP_USER_NAME: [Mandrill user email address]

When attempting to send emails via while using Mandrill I can’t send an email from Discourse to OR email addresses, BUT I receive confirmed delivery via the Mandrill API logs …

Method: messages/send-raw.json
Time: May 11, 2015 3:47 pm
Call time: 69.4ms
IP: [Discourse server EC2 elastic IP address]
User Agent: Mandrill-Python/1.0.56

Full Request

    "send_at": null,
    "from_name": null,
    "raw_message": "Received: from localhost.localdomain (unknown [EC2 Elastic IP address])\n\t(Authenticated sender:\n\tby ip-10-187-29-39 (Postfix) with ESMTPSA id 2AC4DC0736\n\tfor <>; Mon, 11 May 2015 19:47:08 +0000 (UTC)\nDate: Mon, 11 May 2015 19:47:37 +0000\nFrom:\nReply-To:\nTo:\nMessage-ID: <>\nSubject: [Custom Discourse] Email Deliverability Test\nMime-Version: 1.0\nContent-Type: multipart/alternative;\n boundary=\"--==_mimepart_55510759a2805_6a3ff1b5cd7e7c285b2\";\n charset=UTF-8\nContent-Transfer-Encoding: 7bit\nAuto-Submitted: auto-generated\n\n\n----==_mimepart_55510759a2805_6a3ff1b5cd7e7c285b2\nContent-Type: text/plain;\n charset=UTF-8\nContent-Transfer-Encoding: 7bit\n\nThis is a test email from\n\n[****][0]\n\nEmail deliverability is complicated. Here are .."
    "ip_pool": null,
    "from_email": null,
    "return_path_domain": null,
    "to": [
    "key": "MI0xXUE4xIA5TTfSyziQcg",
    "async": false

Full Response

        "email": "",
        "status": "sent",
        "_id": "2312b8907c184e1985e046c1c2e57f0a",
        "reject_reason": null

So there’s obviously multiple problems going on here, which from what I understand is …

  • there’s something preventing me from delivering an email from to my own (or other) email addresses via SES
  • I’m completely unable to successfully deliver any emails (to or from Mandrill, even with a domain and DKIM verified and SPF record added (not verified due to not Top 10) for

The only thing I can think of is that in the “raw_message” there’s the following …

“Received: from localhost.localdomain (unknown [Discourse EC2 elastic IP address])\n…”

where the actual EC2 elastic IP address is used. Could this be the cause and any idea on how to resolve?

The other thought is that the spam or whitelist filter is blocking me from successfully delivering emails, BUT this doesn’t make sense because I’m using a verified email from the same exact domain.

Thoughts? Thanks so much!

(Dean Taylor) #2


My guess is SPF records for did not allow Amazon SES to send mail.


Well it’s not a valid SPF record then - you never want errors on SPF records - crazy unpredictability for mail delivery.

SPF specification has a limit on the number of DNS lookups (10) required to fully resolve an SPF record, this is overed in detail here:

You can check this with this tool:

Here you have contradicted yourself - now you are saying they are verified??

###General mail testing
The following tool has been mentioned a few times on this forum - it might help you:

In addition any test messages you send should look like real messages - never send a message with “Test” as the subject and “Test” as the body. It will likely never get delivered, full sentences, multiple lines - make it look real.

(Andrew Stroup) #3

Mean to include that the SPF still has an error because it’s not a top 10 record (modified original post)!

Working on the other things you mentioned …

  1. SPF Query Tool results

I totally get what you’re saying about the SPF record not being valid, BUT I just don’t think that’s the issue, specifically because I can send emails to whoever from my account in SES. If I needed a valid SPF record to do this …

  • other accounts within Mandrill that don’t have either a verified domain, DKIM or SPF record shouldn’t be able to send emails, BUT they can send emails out just fine
  • I shouldn’t be able to send out emails from my account within SES

Unless I’m missing something, appreciate all the help!

(Dean Taylor) #4

the domain has a softfail SPF record:

C:\Users\Dean>dig @ ANY

; <<>> DiG 9.9.2-P1 <<>> @ ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34817
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;                     IN      ANY

;; ANSWER SECTION:              299     IN      A              299     IN      AAAA    2a00:1450:4009:80a::2005              21599   IN      NS              3599    IN      MX      20              21599   IN      NS              21599   IN      NS              3599    IN      MX      30              3599    IN      MX      5              21599   IN      NS              3599    IN      MX      40              299     IN      TXT     "v=spf1"              21599   IN      SOA 2015031901 216
00 3600 1209600 300              3599    IN      MX      10

;; Query time: 27 msec
;; WHEN: Thu May 14 00:18:03 2015
;; MSG SIZE  rcvd: 367

C:\Users\Dean>dig @ ANY

; <<>> DiG 9.9.2-P1 <<>> @ ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61411
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;               IN      ANY

;; ANSWER SECTION:        299     IN      TXT     "v=spf1 include:_netbl ~all"

;; Query time: 30 msec
;; WHEN: Thu May 14 00:25:43 2015
;; MSG SIZE  rcvd: 160

Because it has a soft fail (~all) SPF record - it isn’t used to prevent the delivery of emails from * email addresses, treated as accept but mark.

Your domain does have an SPF record, worse than that it has an invalid SPF record - this is used to prevent the delivery of mail.

If you removed the SPF record for your domain - it might deliver - but you would have to wait for the DNS TTL time to expire before attempting another test delivery.

However I don’t believe this will help you - and SPF record will be required as AWS IP addresses are commonly blocked (read: negatively effected) because they are used by spammers; adding an (correct) SPF record works around this.

(Andrew Stroup) #5

Hm got it, thanks Dean, standby for more, working this out now …