Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Bug in SES custom MAIL FROM suggested DNS records

1

Hello, I believe I've found a bug in the user interface of the domain identity verification feature of the AWS SES email relay service.

I was able to verify my domain correctly, but I had trouble configuring the custom MAIL FROM feature the first time. When setting up this feature, the user interface gives you two DNS records to add; one MX record for the bounce mail server and one TXT record with SPF policy.

The bug is in the MX record (both the displayed value and the value in the downloadable CSV file).

In my case, the suggested value for this MX record is:

10 feedback-smtp.us-east-1.amazonses.com

Note that there is no final '.' after the '.com' portion of the domain name. Without a trailing dot, most (all?) DNS servers will append the domain of the zone containing the record to the result (eg, my local domain gets append to the amazonses.com domain).

The feature remained in the 'pending' state until I fixed this DNS record. Let me know if I can provide more info.

  • Stuart
    a year ago

    Still not fixed.

Topics
Front-End Web & MobileBusiness Applications
Tags
Amazon Simple Email Service
Language
English
asked 3 years ago183 views
1 Answer
-1

Most of the well known DNS server will add the "." at after the "com" automatically, which is why it is not mentioned in the doc to prevent having duplicated dots, which will eventually will lead to a failure in the record validation. This is not a bug, and it comes back to the DNS server, and if it adds the "." automatically or not. If not, then a "." is needed for the MX record as a standard DNS industry thing.

Thanks!

AWS
answered a year ago
  • kraig
    a year ago

    This is simply not true. Bind is the dominant DNS server on the internet. It, most others, and the example in question here use a zone file syntax defined in RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt). This portion of section 5.1 is relevant:

    <domain-name>s make up a large share of the data in the master file. The labels in the domain name are expressed as character strings and separated by dots. Quoting conventions allow arbitrary characters to be stored in domain names. Domain names that end in a dot are called absolute, and are taken as complete. Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the master file loading routine. A relative name is an error when no origin is available.

    The lack of a '.' at the end of the example in question means that the server must interpret that entry as a relative entry in the zone file. And given that this example is used to reference an external service, it only makes sense to use an absolute entry.

  • kraig
    a year ago

    I tried to submit document feedback but I did not have permission. I was redirected here.

  • Generally Adam MODERATOR
    a year ago

    Huh! Thank you for reaching out and keeping up with this by responding here. I'll get this in the right hands.

  • Generally Adam MODERATOR
    a year ago

    The provider listed in the SES MX record docs handle this for you, but you're right about Bind and the specs.

    See your provider's documentation [...] about adding an MX record to [...] your domain.

    I agree, this isn't clear and can be improved. Have you submitted feedback on the docs page, using the feedback button there? That will notify the team that owns the page's contents.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content