The whole idea behind the MX record is to specify a host or hosts which can accept mail for a domain. As specified in RFC 1035, the MX record contains a domain name. It must therefore point to a host which itself can be resolved in the DNS. An IP address could not be used as it would be interpreted as an unqualified domain name, which cannot be resolved.
They are mostly wrong.
It is not a bad practice to have more than one MX, and it's equally not a bad practice to have one or more of them with a hostname in another domain. In fact, it used to be quite common that people would set up their own mailserver in their own domain as their primary MX, and then have their ISP's mailserver as secondary MX.
The one ...
To make things nice and clear, as some of the GoDaddy help articles are dead wrong:
You just need to paste the two records from the server settings into your Route 53 control panel as a new record.
The possible deception here is the the GD email panel will tell you you're wrong, but not what is right so you can make it right. Further, their help article ...
Yes, it would be possible, but you will lose some important advantages if you choose to do so:
If you point all services to the same DNS name, you can't put them onto separate servers any more without reconfiguring any client that refers to them.
As an example: With different names, when the load on the server grows too much, you can simply offload the ...
Just use a telnet session to test email delivery. As an example,
# telnet host.domain 25
Connected to host.domain.
Escape character is '^]'.
Subject: a test message
DNS as a protocol has some different types of values, these are not interchangable.
It's important to note that DNS is a binary protocol with strict mappings between the type of record and the type of data that such a record holds.
An A record holds an IPv4 address (4 bytes of data, fixed length).
An AAAArecord holds an IPv6 address (16 bytes ...
It would definitely create a problem if you were to point your MX records at CNAME records since it is against the standards. The clearest explanation is provided by RFC2181 §10.3:
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
Hotmail fails to use proper DNS rules. Hotmail will always try to deliver to the domain's A-record first and will ignore MX-records. If the domain A-record accepts a connection (eg. it runs a mailserver) it will try to deliver the email, which in most cases will not be an issue if the webserver and mail server are the same box.
However, if an domain uses a ...
An MX RR pointing to itself is perfectly valid and will cause no problems. It may be considered redundant, though, because of the general rule that if a domain name has no MX RR but an A RR, the latter shall be used for mail delivery. In other words, an MX RR pointing to itself is implicitly assumed when no explicit MX RR is present.
Note that your example ...
Under normal circumstances the server will connect to the first one that is available, but there are many reasons the first one may be unavailable to one person but not the next. Some of these reasons include things you have no control over. However the general rule is try from lowest to highest until there is a response and then use that server.
You will need to correct the MX records in your DNS which is probably hosted on your server at Rackspace. You can locate the MX records you need in the Email Control Center. Here is a guide to do so:
The first MX means that the IP addresses in the MX record(s) for the domain you're actually attaching the SPF record to should be accepted as valid. The second one means that IP addresses in the MX record(s) for the domain mail.mydomain.com should be accepted as valid. If this SPF record is for the domain mail.mydomain.com, then the second one is redundant. ...
The RFC's that specify how a MTA should handle MX records are RFC974, RFC1123 section 5.3.4, RFC2821 section 5 and RFC5321 section 5.
RFC974 status is now HISTORIC. According to it, MTA's are expected to query the list of MX records associated to a domain and are "encouraged" to try all (or a fixed number of) SMTP servers, in ascending order of preference. ...
No spf records are NOT required if your domain doesn't send emails
however for benefit of reducing the risk of spam mail coming from that domain setting the spf record of
is good so that spf checking servers see this and automatically reject email from that domain
Definitely a NO, not with a 127.0.0.0 IP.The entire 127.0.0.0 range on IPv4 works as loopback addresses, thus when any machine connects to IPs in that range it will try to connect to itself.
Your MX record IP address should be accessible from the outside world and what that result is telling any server doing a MX query, to try to connect to itself.
If my ...
No, MX records are not used when sending outbound mail.
However, some mail servers may require that the domain of the from address have the necessary DNS records to support incoming mail, in which case you need either an MX or A record on that domain.
A word of warning:
An MX record provides information about where email should be delivered. It does not necessarily provide any information about where email originates. It is entirely possible -- even likely -- that mail will be coming from a system that is not listed as an MX for the given domain.
SPF records, on the other hand, allow you to verify ...
Make sure that mail server MX record is referring has A record, CNAME is not enough. This is important but I do no remember why. Here is an example:
@ IN SOA dns0.yourisp.com. zone.yourisp.com. 1308717736 21600 7200 1209600 10800
@ IN NS dns1.yourisp.com.
@ IN NS dns2.yourisp.com.
@ IN MX 10 mail.example....
Per AWS' examination, it was clear the MX record was pointing to mail.mydomain.com rather than simply the apex (mydomain.com). GoDaddy's e-mail set-up was likewise seeking mydomain.com...and not a non-existant subdomain. (I had mistakenly added the "mail." prefix in Route53.)
When adding an MX record via the Route53 "Edit Record Set" panel (on the right ...
You are correct that your TTL should cause all sites to upgrade within 2 hours. However, having worked at an ISP for years I can attest that many large and important sites ignore TTL, and cache for 24-48 hours regardless. So most sites will change within your TTL... but an annoying few will take days. I once saw a DNS that took 7 days before it read a new ...
You are not required to have MX records just to send email.
you must use a valid, existing and working email domain as sender address in all outgoing traffic (sending mail from firstname.lastname@example.org is not allowed)
any domain used in email traffic can work without MX records if it has a valid A record, but this kind of setup is not much ...
Short of a kind of crawler that keep historical snapshots like the Wayback Machine but for DNS, no, this is not possible.
If you suspect that the MX record update may have been the most recent change to the DNS zone, then you can always check the zone serial number in the SOA record. One very frequently used convention for the format of the serial number is ...
What is 1e100.net? It’s Google. A WHOIS lookup for that domain reveals it’s owned by them.
Why would Google use an "weird" domain name like 1e100.net? It’s symbolic of a googol (10×10^100) which is where Google gets its name from.
Yes, you can have an MX record for a 3rd level domain. You can have a MX record for anything (not that it makes sense in all cases).
Looks like it was a propagation delay because I see it:
$ host -t mx sfr.continuumconcepts.com
sfr.continuumconcepts.com mail is handled by 10 sfr.continuumconcepts.com.
+1 for actually showing your domain and making ...
You don't strictly need to publish any SPF records at all, it is a voluntary system.
That said, if you do publish an SPF record, you can:
Help the Internet at large a tiny, tiny bit because it gives spammers one less domain to spoof. (Marginal benefit, but...)
Help preserve your domains 'reputation' by making it less likely to be spoofed in spam.