3

We have a mail server (Mailenable) which we are using to sell email accounts to our clients. We have one client that could not send email to a specific domain and they receieve this error from the domain's email server:

Reason: The message could not be delivered because the domain name ourclientcompanyname.com does not have any DNS records.

The company that uses us for email does not have any DNS records for their domain ourclientcompanyname.com

MX records are fine but the domain has no other DNS records. Is that a possible error? What DNS records should the client should add?

3
  • 1
    Please tell us the domain in question.
    – EEAA
    Feb 27, 2015 at 18:47
  • 1
    I suspect they require an A or CNAME record. You appear to have MX records, but some ISPs may require an A/CNAME.
    – ceejayoz
    Feb 27, 2015 at 18:53
  • After adding an "A record" under domain the error has been solved!
    – user776720
    Apr 6, 2015 at 6:57

3 Answers 3

5

MX records are fin but the domain has no dns record at all. Is that a possible error? What dns record the client should add?

Yes, some mail servers, upon receipt of an email, check to see that the domain for the sending user, not just the sending server, has DNS records. I think it's a bit silly, and not a great check for spam, but it is what it is. Your client most likely needs to simply put an A record in for their ourclientcompanyname.com apex domain. Get them a $5 hosting account and a single page informational website for good measure, just to be nice.

EDIT:

Buried within ye olden RFC 5321, it says in section 2.3.5:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.

Noice! I still think it's a silly to think of it as a spam deterrent and is a correlation/causation conflation, but hey at least it's a documented standard and following it has some positive side effects on the spam folder! Who has two thumbs and just got RFC schooled?

enter image description here

4
  • Actualy it's not silly at all, and it blocks well over half the spam I would otherwise receive. Feb 27, 2015 at 19:05
  • Is there an RFC or otherwise a standard that makes this a requirement? I'm curious about my assumptions. I mean, I'm sure it does block a lot of spam, but it's still illogical and silly. Blocking one service based on another virtually unrelated service's or host's unavailability, regardless of outcome, is broken. There's no actual need to have an A record at the apex of a sending domain for mail to be receieved. There are better standards-based ways of blocking spam. It's just a silly hack that certainly works, but is still a hack... unless I'm standards deficient, which is very likely. =)
    – Wesley
    Feb 27, 2015 at 19:40
  • 4
    It's not the zone apex, per se. It's the name of the mail server, whatever it is. In this case, it just happens that they named the mail server the same as the naked domain name. If someone tells me EHLO spambox.spammer.com and spambox.spammer.com doesn't resolve, then I'm going to tell them to get lost. And yes, RFC 5321 requires this (sect. 2.3.5) Feb 27, 2015 at 19:48
  • Kittehs don't got thumbs! Mar 2, 2015 at 4:30
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 CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:

  • The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.

This is not a new requirement; RFC 2821 section 2.3.5 (2001) had similar language.

The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.

If your mail server says EHLO company.example and company.example can't be resolved to an address, then it's perfectly valid to reject that connection. The same is true of the domain names used in the sender and recipient addresses (with the exception of postmaster, which doesn't require a domain name at all).

(Prior to RFC 2821, the governing standards were RFC 821 and RFC 974, which date to the 1980s and had to accommodate many non-Internet networks which no longer exist, thus the standards were much less restrictive.)

1

In order for mail to function properly there are three DNS records that are required.

  1. A Record - Host name to IP address mapping

  2. MX Record - The MX record is bound to the A Record for the mail server

  3. Reverse Lookup - The IP address needs to be bound to the A record for reverse lookup (SPAM Prevention)

As well, the PAT address at the firewall needs to be set for the mail server so the public IP (source IP) of the mail server matches the reverse lookup.

You will typically need to get with your ISP and have them create the reverse lookup if they own the IP addresses you are using on the public side.

Note: There is no RFC regarding Forward-Confirmed Reverse DNS. It is simply a best practice.

3
  • Can you explain the "required" part with regard to point #1? Is that requirement just observational and experiential, which is still valid to bring up, or are they actually RFC and standards based requirements? Not to split hairs, but #3 isn't specifically "required" but just very good practice to make sure your mail isn't rejected. AFAIK #2 is the only thing that could be said to be absolutely required.
    – Wesley
    Feb 27, 2015 at 19:36
  • True, #3 isn't required but if you are sending email to any enterprise mail server they will do a reverse lookup as well as db lookup for the domain on a black list. So, true, there is no RFC for Forward-confirmed reverse DNS but the fast majority of mail providers (yahoo, google, etc) and enterprise environments would require it to receive from you
    – Citizen
    Feb 27, 2015 at 19:45
  • Here is a link explaining what an A Record is. support.dnsimple.com/articles/a-record
    – Citizen
    Feb 27, 2015 at 19:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .