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!
Related
I am trying to set up Google's server-side tracking to pass data from a website to Google Ads in a first party context. I understand how this works and I have done this before. The setup requires you to add 8 DNS records to your domain (4 A records and 4 AAAA records) all using the same hostname that you have set as the subdomain. I have never had an issue until I tried to set this up using a Shopify-hosted domain. Shopify does not let you add multiple A/AAAA records having the same name. I also tried using # as the name which did not work either as that is the same as the default domain that Shopify sets when you host your domain with them. Shopify have confirmed that this is not possible and no other domain hosts give me this issue.
Is there any workaround here? This essentially means that if one is using a Shopify hosted domain, they cannot make use of this server-side tracking by Google which will become vital with the removal of Chrome's 3rd-party cookies coming up!
I tried to add the records in and it did not let me and threw an error.
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 am trying to create a GitHub page for a repository. But when I gave the custom domain name, it shows the following message "Domain's DNS record could not be retrieved. For more information"
As I am new to GitHub I am not getting the information what is documented in GitHub pages. Could anyone help me to resolve this problem?
If you've recently changed or removed your custom domain and can't access the new URL in your browser, you may need to clear your browser's cache to reach the new custom domain. For more information on clearing your cache, see your browser's help site.
In order to serve the Page, your DNS records must point to GitHub's server. To confirm that your custom domain points to GitHub's servers, use the dig command with your custom domain. The dig command shows you where your custom domain points. For example:
$ dig example.com +nostats +nocomments +nocmd
example.com. 3600 IN A 185.199.108.153
In the example above, example.com points to the IP address 185.199.108.153.
If you configured A records through your DNS provider, your A records must point your custom domain to the following IP addresses:
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
You may see a different IP address, since we serve Pages with a global Content Delivery Network. Use dig username.github.io to see the full resolution path. Note that DNS caching may cause a delay.
If you're using an A record that points to 192.30.252.153 or 192.30.252.154, you'll need to update your DNS settings for your site to be available over HTTPS or served with a Content Delivery Network. For more information, see "HTTPS errors."
If you're using an A record that points to 207.97.227.245 or 204.232.175.78, you'll need to update your DNS settings, as we no longer serve Pages directly from those servers.
Source: https://help.github.com/en/articles/troubleshooting-custom-domains
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.