92
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.
...
44
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 ...
37
http://whoisrequest.org/history/
This one is really cool . No registration needed .
24
No, this is BS. Having this option is one of the main reasons why you can specify multiple MXs with different priorities in the first place.
There must be another problem.
21
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 ...
20
Just use a telnet session to test email delivery. As an example,
# telnet host.domain 25
Trying host.domain...
Connected to host.domain.
Escape character is '^]'.
220 ESMTP
HELO example.com
250
MAIL FROM:<user@example.com>
250 ok
RCPT TO:<user2@example.com>
250 ok
DATA
To: user2@example.com
From: user@example.com
Subject: a test message
Test ...
19
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.
For example:
An A record holds an IPv4 address (4 bytes of data, fixed length).
An AAAArecord holds an IPv6 address (16 bytes ...
19
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
...
16
http://dnshistory.org/
Seems to have a patchy history, all for free.
16
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 ...
14
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.
Where ...
13
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. ...
13
You should click the Edit button in the MX record that Google considers valid, click '+' and add the second MX record
12
Yes, an MX record is there only for incoming mail.
12
Your domain does not have an MX record. But an MTA is listening on the A record's IP, and that is the fallback of SMTP in case there is no MX record.
11
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. ...
10
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 ...
10
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.
10
While technically you can point an MX record to an IP many places won't let you so just create an A record called mail and point it to your IP for the domain and then point the MX record to that.
9
You are not required to have MX records just to send email.
However:
you must use a valid, existing and working email domain as sender address in all outgoing traffic (sending mail from something@nonexistentdomain.com 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 ...
9
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 ...
9
No, or not necessarily.
.dev like all new Google TLDs (including .new in one month) has been added to the HSTS Preloading list. It means that all names under this TLD will force browsers (because they incorporate the HSTS preloading list) to do only HTTPS calls, and never HTTP one. You can find Google explanations at https://security.googleblog.com/2017/09/...
8
RFC1912 explicitly acknowledges the existence of wildcard MX records, but warns
A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all.
RFC4592 is a standard-track RFC that clarifies the existence of MX wildcards (see the example in section 2.2.1). I'm pretty sure your DNS provider is, thus, full of it.
I can imagine ...
8
Due to the fallback of directly contacting a host via its address records, a single "null MX" record of "MX 0 ." is the apparent preferred way to indicate that the host does not accept e-mail. This is similar to a "null SRV" record ("SRV 0 0 0 .") which specifically marks a service as not available (per the SRV-RR RFC 2782).
This has been standardized by ...
8
MX records are not used for outbound mail, only for inbound. if your current mail. domain.com server is outbound only then delete your current MX record.
8
You cannot have a CNAME for the domain.
CNAMEs can only exist as single records and not combined with any other resource records. Since a domain always has a SOA and NS record, you cannot use a CNAME for the domain. This is specified in RFC 1034, section 3.6.2.
The reason that email specifically breaks is found in RFC 5321, section 5.1:
That domain ...
8
You can't use a CNAME record at the zone apex. This is because a CNAME record defines one name to be an alias of another regardless the requested record type.
This, in turn, also means that a CNAME record cannot coexist with other records as that would be a conflict/inconsistency.
The zone apex always has at least SOA and NS records, which means there can ...
7
Yeah, this behavior is wrong.. but enforcing RFC standards in SMTP is hopeless. To quote RFC 5321:
The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name.
But, the sendmail MTA rewrites the recipient address by default, in violation of the RFC. ...
7
If you don't intend to send mail from this domain, why let anyone else to use it as they wish? But things have changed since this question was asked eight years ago. SPF can only protect your domain from being used as the envelope sender, but SPF can't protect the From: header.
I'd go even further by adding a DMARC alignment.
@ IN TXT "v=...
7
No.
You can't be reasonably sure your outgoing email will be delivered, as many destinations simply blacklist, firewall, or even null route all major cloud providers' IP blocks due to the heavy abuse seen from those ranges - not just from email but via other services as well.
And even if your mail is delivered today, that's no guarantee it will continue to ...
Only top voted, non community-wiki answers of a minimum length are eligible
