95
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.
The ...
48
The point would largely boil down to being a good citizen and reducing abuse, like making your domain less useful for spammers to impersonate and to make it immediately clear to others that mail is not deliverable there.
If the claim is accurate that the domain is not used for either sending or receiving email at all, you could add something like this:
...
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 ...
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.
22
MX records are used according to priority value in the records.
The record with the lowest priority is used first, then the higher ones until one responds. If there are multiple records with the same priority, one is randomly selected (this is how you generally do load balancing if you have multiple mail servers accepting incoming connections).
The MX ...
21
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 ...
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
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
the ...
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
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. ...
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
I took a look, unfortunately I couldn't find an MX record, the SOA record shows me that something was last changed to the dns records on March 23. When did you make your changes?
;kmtc.com.sa. IN MX
;; AUTHORITY SECTION:
kmtc.com.sa. 900 IN SOA ns01.trademarkarea.com. postmaster.kmtc.com.sa. 2021032365 3660 ...
11
DNS doesn't propagate; the responses from authoritative servers are cached by the recursive servers. Currently your authoritative servers are responding with an empty set of MX records, so they are not configured correctly.
$ dig kmtc.com.sa. MX @ns01.trademarkarea.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33020
;; flags: qr aa rd;...
10
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 name, ...
10
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/...
10
MX records cannot solve this, multiple records (with possibly different priorities) can be used for redundancy, but the service is expected to be the same (accept the same addresses).
What you can do is either have the address that your application processes at a different domain (eg foo@bar.example.com if the regular addresses are @example.com) or set up ...
10
An MX record consisting of only a single dot . is a Null MX as defined in RFC 7505. It means that the domain doesn't accept any email.
9
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=...
8
RFC2181 section 10.3 says you can't point your MX record to a CNAME:
The domain name used as the value ... of a MX resource record must not be an alias.
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
Yes, you understand it correctly.
Sending E-Mail servers use MX records in order of preference defined within the MX records. The record with smallest precedence is used first, then the second smallest etc.
If two servers have equal precedence, the sending server picks a random server from the equal precedence server.
You can make forwarding accounts on ...
7
RFC 5321 section 2.3.5 requires that domain names used in email be resolvable to addresses.
From the relevant parts:
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are ...
7
Your domain hasn't actually got an MX record.
$ host -t mx samholguin.co.uk
samholguin.co.uk has no MX record
Without an MX record, mailers will fall back to trying to deliver to an address for the naked domain. That address is:
$ host samholguin.co.uk
samholguin.co.uk has address 209.222.30.215
An MX record for a subdomain would only apply if you were ...
7
This took many, many, many hours of Google-Fu (about 18 hours, give or take).
You have to first log in to your Outlook.com account that you're missing your records on. This must be done on a browser that has never logged into Office365 (so either download a new browser and DO NOT import anything, or clear everything out of your main browser). I used MS Edge ...
7
Well, this is embarrassing. As I predicted my problem was caused by the most obvious and trivial reason: lack of read access to /etc/resolv.conf for the postfix user o_0
As you probably know the postfix subproceses (smtp, smtpd, qmgr, etc) runs with the postfix user. All the comments and suggestion I've received has been related with problems accessing to ...
7
These sites are misconfigured. Roughly 15 years ago such configuration would be a sure pointer to an IT department running on windows without a clue about the internet.
This hasn't changed much. Many companies try to cheap out on the expenses for proper IT support and have a random employee with some basic understanding of IT manage their stuff and those ...
7
it is IONOS who signs those emails, right?
It would be, if they signed them. But they don't. (But they should.)
Here are some excerpts of a conversation I had less than 10 minutes ago with their support team (emphasis added):
IONOS: Hello there. I understand that you want to add a DKIM. Unfortunately we don't have a DKIM record in IONOS. You can instead a ...
Only top voted, non community-wiki answers of a minimum length are eligible