I am setting up the custom MAIL FROM domain based on this link: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/mail-from.html
I have primary domain verified and I have added the MX record to the DNS settings, which I can see on the mxtoolbox.com. However, the Custom MAIL FROM domain is still in the status of "pending verification".
Does amazon check it in batch(maybe once per hour) or those changes should be visible immediately? Or is there any place where there could be misconfiguration from my side, when I see the MX record visible? What can I do to successfully configure the Custom MAIL FROM domain?
Dig command has been verified with the MX record to the amazonses.
Spf record allow specifically designed ip's, without the -all option. Could that be the reason?
If anyone is struggling with the same problem, this few things help:
1) Remove Your custom MAIL FROM domain from SES
2) Add it one more time
That was the steps, that support gave us which also worked.
Simple "Turn off - Turn on" and everything works :)
i´ve got an error on sending email to our Mailgun-service on some Email-providers.
we have an subdomain with an mx record that routes to mailgun, to receive emails as http-post.
if i send a message to our mail address ...#msg.artwizz.com with icloud or gmx everything works fine.
but some email provider will get an error called "X-Postfix; Host or domain name not found. Name service error for name=msg.artwizz.com type=A: Host not found" and i cant find an error.
i checked all DNS settings, they are all correct:
May somebody has the same problem and has an solution :D
thx a lot.
1) Create new MX records for your TLD (artwizz.com) that contain the same values as msg.artwizz.com.
2) Create an A record for artwizz.com and msg.artwizz.com and point it to some valid web server. It is considered strange for a domain name to not have an A record for the apex. This may be triggering SPAM rules.
3) Since you already have SPF and DKIM enabled, setup DMARC. This will sign your emails and most well designed email servers will respect your emails as not being SPAM.
I want to be able to send from foo#*.mydomain.com AND receive responses without needing to manually setup MX records for each subdomain I'm interested in (bar.mydomain.com, baz.mydomain.com, etc.mydomain.com , ...)
Mailgun docs show a setting on a domain called wildcard labeled "Mailgun allows you to receive email at multiple subdomains of a single domain without actually adding them. You still need to add the appropriate MX records for your subdomain(s) at your DNS provider" in the web ui.
A comment on this ServerFault answer seems to hint that a new MX record would have to be made for each subdomain. I'd prefer not to have to do that and just keep it dynamic with something like this:
# IN MX 10 mxa.mailgun.org.
# IN MX 10 mxb.mailgun.org.
*.mydomain.com. IN MX 10 mxa.mailgun.org.
*.mydomain.com. IN MX 10 mxb.mailgun.org.
Does Mailgun support sending AND receiving from wildcard subdomains? and if so, what DNS records should be added (MX & SPF/DKIM)?
(This somewhat related question doesn't list out the specifics.)
Just got a response from MG support
We do not support sending from wildcard domain. We require each domain
you wish to send with be added and verified to our system with the
explicitly SMTP credentials or API endpoint used for sending.
Setup
Our company hosts their emails with GoDaddy along with the domain entry.
We host EC2 instances in AWS that send emails on behalf of that domain
DNS Configuration is handled via AWS Route 53
Info
We are working towards getting our production server fully up and running and as such we were implementing SPF and DKIM email signing. We didn't have an issue setting these up until it came to the application sending emails as no-reply#test-domain.com. Our emails were being signed with DKIM and we couldn't put our finger on why SPF verification was failing.
Example TXT record for SPF verification
"MS=ms12312312 v=spf1.1.1.1 ip4:2.2.2.2 include:spf.protection.outlook.com ~all"
As you can see we have a valid SPF record allowing 2 ip-addresses explicitly and one domain. We are using a soft-fail as per the schema. The "include" and "MS" portions are from GoDaddy with regards to pointing your domain to AWS and not GoDaddy.
Question
What the heck is the MS portion for? We have identified that this is the root cause of our messages not being SPF verified. As soon as we removed this portion, our site was accessible, we could manually send and receive emails, the app could send emails and the server itself could send emails, all passing SPF.
I am not comfortable just removing something without knowing its purpose so I am hoping someone here is aware of it.
Thanks,
The MS=ms123456 TXT record is something used by Office 365 to validate your ownership of the domain (O365 gives you the record to create so you can prove you are the rightful owner of the domain).
The MS and SPF records can certainly coexist in the DNS, but they need to be put in separate TXT records. You can have multiple TXT records and whatever system that are looking for a certain TXT record must examine each one until it finds the one in the correct format, i.e. starts with MS=, v=spf1 or whatever.
Just make two separate TXT records:
TXT "MS=ms123456"
TXT "v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 include:spf.protection.outlook.com ~all"
and everything should work fine!
I own foo.com and bar.com. I am managing both in Route53. foo.com hosts my site, and I'd like to direct traffic from bar.com to foo.com. I tried to set up a CNAME record for bar.com pointing to foo.com, but I got the error message:
RRSet of type CNAME with DNS name foo.com. is not permitted at apex in zone bar.com.
Why doesn't this work, and what can I do instead?
As per RFC1912 section 2.4:
A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:
podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A
The RFC makes perfect sense as the nameserver wouldn't know whether it needs to follow the CNAME or answer with the actual record the CNAME overlaps with. bar.com is a zone therefore it implicitly has an SOA record for the bar.com name. You can't have both a SOA record and a CNAME with the same name.
However, given that SOA records are generally used only for zone maintenance, these situations where you want to provide a CNAME at the zone's apex are quite common. Even though the RFC prohibits it, many engineers would like a behaviour such as: "follow the CNAME unless the query explicitly asks for the SOA record". That's why Route 53 provides alias records. These are a Route 53 specific feature which offer the exact functionality you require. Have a look at http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingAliasRRSets.html
Create an S3 Bucket called bar.com. (The name must be the same as the domain you want to redirect from in order for this to work!)
In the bar.com S3 Bucket go to Properties > Static Website Hosting, select Redirect all requests to another host name and enter foo.com in the text box.
Back in Route 53, in your Hosted Zone for bar.com, click Create Record Set. Select A - IPv4 address for type. Click Yes for Alias. Click the text box for Alias Target. bar.com should be listed under -- S3 Website Endpoints --. Save the record. Wait a few minutes and you should have a redirect setup to redirect requests from bar.com to foo.com.
You can use this same method to redirect a naked domain to a subdomain (like www). I use this in cases where www.foo.com has to be a CNAME so I redirect from foo.com to www.foo.com with this same method. If foo.com is an A record, you can use this technique to redirect from www.foo.com to foo.com.
NOTE: this method will forward with the full path. i.e. http://bar.com/test will forward to http://foo.com/test.
On Route53, You need to create an A record NOT a CNAME record, and create an alias under that.
From #ewalshe's comment on Alexandru Cucu's answer,
if you came here trying to setup API Gateway with a custom domain name and have a Cloudfront distribution url.
Jonathan answer is correct. If you still confuse with his answer please take a look of this example.
tldr; You have to pass in an FQDN as the ResourceRecordSet name.
I had this same problem using this statement c# snip:
private static void RegisterHostWithDns(IAmazonRoute53 ec2,SynoviaImage image)
{
var changeBatch = new ChangeBatch();
var rRs = new ResourceRecordSet(image.Name, RRType.CNAME) {TTL=60,ResourceRecords = new List<ResourceRecord>() { new ResourceRecord(image.PublicDns)} };
var change = new Change(ChangeAction.UPSERT, rRs);
changeBatch.Changes.Add(change);
var request = new ChangeResourceRecordSetsRequest(ConfigurationManager.AppSettings["DnsZoneId"], changeBatch);
var response = ec2.ChangeResourceRecordSets(request);
Console.WriteLine("Updated CNAME For {0} setting {1}",image.Name,image.PublicDns);
}
In this case image.Name == "Listener"
Once I changed it to:
private static void RegisterHostWithDns(IAmazonRoute53 ec2,SynoviaImage image)
{
var changeBatch = new ChangeBatch();
var rRs = new ResourceRecordSet(string.Format("{0}.{1}",image.Name, "testing.foo.bar.com"), RRType.CNAME) {TTL=60,ResourceRecords = new List<ResourceRecord>() { new ResourceRecord(image.PublicDns)} };
var change = new Change(ChangeAction.UPSERT, rRs);
changeBatch.Changes.Add(change);
var request = new ChangeResourceRecordSetsRequest(ConfigurationManager.AppSettings["DnsZoneId"], changeBatch);
var response = ec2.ChangeResourceRecordSets(request);
Console.WriteLine("Updated CNAME For {0} setting {1}",image.Name,image.PublicDns);
}
now the value being passed in is: "Listener.fully.qualified.com"
It works now.
Please note that this error can happen if you forgot to enter something in the 'Record Name' field.
That is, it may expect www, and if you forgot that, you'll see the error, even if everything else is correct.
It's a small chance, but if you forgot to enter www in the 'Record Name' field, go and do that, and everything should work.
You should use the DNAME instead of a CNAME.
A CNAME record is only able to redirect the label to another label.
When you talk about redirecting domain names instead of labels, you should use DNAME
$ORIGIN bar.com
IN DNAME foo.com
This also means that every A, NS and any more records should be deleted. This have to be configured in the foo.com domain.