Does MX Record Require an Unproxied A Record - In Order for Email to Work?

Website, Application, Performance DNS & Network
1

I read from many posts here that the following setup was required in order for your email hosting to function:

A site.com => 1.2.3.4
A mail.site.com => 1.2.3.4
MX site.com => mail.site.com

Here is my setup:

A site.com => 1.2.3.4
MX site.com => site.com

Is it still required to have the A mail.site.com => 1.2.3.4 for the email to work?

I’m asking because I see a warning on my MX saying it will expose the IP from the A record it is pointed to, which I know is OK for email to work. I’m just asking has Cloudflare changed this so it’s no longer required to create an additional un-proxied A record for a subdomain, like in the initial setup?

I that is so, will A site.com => 1.2.3.4 remain proxied except for handling mail?

4

TL;DR: Yes.

The A record for mail must be Unproxied (:grey:) / DNS-only in this example

The A record for the domain must be Unproxied (:grey:) / DNS-only in this example

It is not required to have that A, but you must keep all AAAA / A records set to Unproxied (:grey:) / DNS-only, when one or more (sub-)domain(s) point their MX record(s) towards that name.

I would therefore do the first set up you mention, with the MX pointing to mail, and then keep mail as Unproxied (:grey:) / DNS-only. That way, you can keep your main domain set to Proxied (:orange:).

3 Likes
5

Thank you, that was the case until recently. I was curious if anything has changed since then.

Concretely, I tested email with proxied A records and it works fine.

The only thing my server complains about regarding email is the Reverse DNS (PTR):

The system sends the domain example.com in the SMTP handshake for this domain’s email. example.com resolves to Cloudflare’s IPs, not your server’s IP. To fix this problem, create a DNS A record for example.com with your IP as value.

6

Hi @epic.network,

I referenced you because I saw from the forums that you responded to a similar topic. Could you please take a look at my question?

Thank you.

7

I am unclear on whether you are currently proxying the hostname in your MX record, but I strongly advise against it. Even if it seems to work, it is likely to encounter problems. This is due to Cloudflare creating a synthetic hostname to use in the MX record when it contains a proxied hostname. The synthetic hostname begins with an underscore, which is fine in TXT record labels, but is an illegal character in actual hostnames.

If you currently have mail.example.com configured :grey: DNS Only using the IP of your mailserver, you will want to update your mailserver’s HELO hostname. How you accomplish that will be dependent on the MTA you are using.

:search: for: change helo hostname ${your_MTA_here}

1 Like
8

Thank you for your response!

Yes, it is mail.example.com. I just tested it proxied and it worked. I will disable the proxy and change the mail server’s HELO hostname to mail.example.com. I’m on cPanel and found this cPanel guide on how to set custom mail HELO. I will change that now. How can I actually test if it works?

9

You could check the source of the message you referenced earlier to see if it has changed. You could also send a message through a tool like this:

1 Like
10

For two days I’ve been trying to figure out the connection between the MX, HELO, PTR, and proxying. It seems to me that the more I study it the less I understand it. Here it is once more:

If you want to exploit the benefits of Cloudflare, A records need to be proxied. But in order to use the same server for sending mail you need to have one A record for a subdomain that is not proxied:

A site.com => 1.2.3.4 :orange:
A mail.site.com => 1.2.3.4 :grey:
MX site.com => mail.site.com

PTR:

main.com 1.2.3.4 (One PTR is allowed per IP but many domains can be hosted under one IP.)

HELO:

site.com => main.com (My cPanel server by default is using PTR’s hostname for HELO for all domains. cPanel even notifies me of this:)

The system uses an alternate HELO of main.com when sending mail from the site.com domain.

Is this the problem you were referring to? So an alternate HELO is the problem, should I change it to mail.site.com? As far as I’ve read it is not forbidden but recommended for HELO hostname and domain sending the mail (MX) to match.

ADDITIONAL QUESTION:
I also host main.com on Cloudflare. The following things are located on this domain:

main.com :orange: (used in PTR record)
server.main.com :grey: (server hostname)
ns1.main.com :grey: (nameserver)
ns2.main.com :grey: (nameserver)

As far as I understand, you can’t have server hostname and nameservers proxied and that is OK since those are subdomains. Since PTR is main.com my server complained that PTR couldn’t resolve so I changed it to :grey: and now it works. But now, my main.com is not proxied and it can’t use Cloudflare services. Should I create another subdomain, for example:ptr.main.com and set it like this:

main.com :orange:
ptr.main.com :grey: (used in PTR record)

This way I keep using Cloudflare services and still have a PTR which is unproxied, right?

11

Please do not use real domains that are not yours. There are resrved domains for use as examples. See RFC 2606 for more details.

You have the proxy status backwards in your final example.

Your PTR should be :grey: DNS Only so the apex name can remain :orange: proxied.

example.com :orange:
ptr.example.com :grey:

1 Like
12

OK, I understand, I’ll fix it. Can you please help me out with that question about HELO?

13

The HELO and the PTR should be the server hostname, not an apex name. It doesn’t matter if it is mrbigglesworth.example.com, or drevil.example.com. Just be consistent and use the same name in the PTR and the HELO. Make sure the IP used PTR also resolves from an :grey: DNS Only A record.

1 Like
14

But what about dedicated IPs, they can have their own PTR, which may or may not be the server’s hostname.

What about matching the HELO hostname and domain sending the mail?

15

Every IP can have a PTR. Often large blocks of IPs have automatically generated generic hostnames in their PTR records. Ideally they can be updated when they are assigned to a user. If you are using multiple IPs on the same host and want matching forward and reverse DNS, you will need to create more names. You might need to use drevil and mrbigglesworth!

There is no requirement for the HELO domain be the domain of the email sender. Many mailservers relay for dozens, hundreds, or even thousands of different domains.

1 Like
16

Those two names now can’t leave my mind so I might as well use them. :smiley:

One last question that will help me sort this out. As I mentioned, these are the PTRs:
cPanel’s main domain is example.com (dedicated IP)
The server hostname is server.example.com (server dedicated IP)

PTR records can be subdomains or domains, it doesn’t matter as long as they resolve through their A records? I’m not required to use the cPanel main domain’s apex as PTR’s hostname?

17

I probably wouldn’t use an apex name in a PTR, but there is no reason not to avoid it, if it makes sense to you. They are all just hostnames. They don’t even have to match forward and reverse, but it is helpful, especially when email is involved.

2 Likes
18

They don’t even have to match forward and reverse.

Do you mean hostnames in A and PTR records? How come? I thought it was required.

There is no requirement for the HELO domain be the domain of the email sender. Many mailservers relay for dozens, hundreds, or even thousands of different domains.

But is there a benefit for them to match?

19

No. There is not, and it adds unnecessary complication without benefit.

You may want to go dig into the RFCs and the timeless classic DNS & BIND.

2 Likes
20

Thank you again, I will. It’s been a pleasure learning from you.

1 Like
21

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.