I'm using Amazon SES and Route53 and confused how I specify the TXT value to include the proper SPF config. Amazon gave me a SES TXT name/value pair which looks something like this:
Name: "_amazonses.xxx.com"
Value: "bInxJfnRbxxxxx9uFXgmxxxxxQHd08UxxxxxxsG+k="
I plugged this into my Route53 Record Set (same as "Zone file" on Godaddy). Sure enough after adding my SMTP credentials to my app and having Amazon verify my account ("grant production access"), it works and I can send email from my site to a variety of accounts (Gmail, Yahoo, Hotmail, my .edu university account).
I know nothing about SPF but hear it is good include in one's email server configuration. By googling about Amazon SES, I keep seeing to include the flowing snippets:
"v=spf1 include:amazonses.com ~all"
"spf2.0/pra include:amazonses.com ~all"
Currently, these 2 snippets are included in the same TXT value field as that big, ugly value above("bInxJfnRb...") and my emails still get sent ok.
Two related questions:
Tim,
I have always used TXT records for keeping SPF and SenderID information, like follows (the lines below are the result of a dig
):
mydomain.com. 86400 IN TXT "v=spf1 include:amazonses.com ?all"
mydomain.com. 86400 IN TXT "spf2.0/pra include:amazonses.com ?all"
This is also how Amazon recommends you to do it.
Both SPF and SenderID are mechanisms ISPs use to verify the server which sent the email as being from your domain is really authorized by your domain to do so. Whenever an ISP is about to forward your email message, they will perform this kind of checks in order to guarantee it is not a SPAM. The explanation on Amazon SES page is one of the most concise I could find:
ISPs that forward email traffic on the Internet are well aware of spammers and their activities. Most ISPs have taken measures to evaluate whether email is legitimate. One such action that ISPs consider is email authentication, in which senders provide evidence that they are the owner of the account that they are sending from. In some cases, ISPs will refuse to forward email that is not authenticated.
If providers like Gmail, Yahoo!, etc, delivered your email to its final destination, your DNS entries are probably already correct. If you try to remove them and wait some time for the DNS settings to propagate, it is very likely your email will start being classified as spam. There are some web tools, like this one, which can help you validate your SPF records.
Hope it helps.