Join Log in
Score:-2
avatar Server

Separate eMail relay: DNS requirements beyond PTR record?

eg flag
Al Klimov

Some cloud business offers "always-free" VM instances. Not quite big, but enough for me, so I’m going to migrate my infrastructure there, including mail.example.com. That machine handles incoming mail for @example.com (example.com MX 10 mail.example.com). However to also send email from @example.com the machine needs a PTR record (192.0.2.1 PTR mail.example.com). The cloud provider, however, doesn't allow to add PTR records. So, maybe I just use a relay for outgoing email, hosted at some another cloud provider who allows setting PTR records?

That relay VM would just need a PTR record called... mail.example.com? Or would smtp.example.org also do? And – if it would also do – would the eMail recipient’s server – pechora1.icann.org – just check that smtp.example.org is smtp.example.org and accept my eMail from... @example.com? W/o additional DNS requirements? (And – if yes – why?)

26
0 + 0
Score:2
Nikita Kipriyanov avatar Server
za flag
Nikita Kipriyanov

Notice you absolutely need not to always use mail, smtp, mx or other "well known" host names for the email server. Any valid DNS host name will do. More, these "well known" names are never checked, so even if you use such a name, nothing will work until you set up everything coherently. I used generic server-nameX to illustrate this. The "incoming" and "outgoing" servers may be completely different machines. It is not important for outgoing server to be able to receive any email. However, the incoming server sometimes needs to originate a delivery status notification.

MX records control the mail reception. This is needed if you want this host to receive mail for the domain. Of course, the mail server need not to be in the same domain. If you want the mail for example.net to be served by the server-name1.example.com, you add the following MX record into the example.net:

example.net. MX 10 server-name1.example.com.

The mail origination is trickier.

Email servers usually behave better if the PTR record points to the corresponding A or AAAA record. For example, if you have

server-name2.example.com. A 192.0.2.1

you'd better have also

1.2.0.192.in-addr.arpa. PTR server-name2.example.com.

(of course, this only helps if your server really connects from the 192.0.2.1).

You'll need this IP address or name to be listed in the SPF record of the served domain (where the "sender" email address belongs). E.g. if you want this server to serve example.net, the latter must have the following somewhere in the SPF TXT record: ... a:server-name2.example.com ... or ... ip4:192.0.2.1 ....

Let this server to have its own DKIM private key and let it use that key to sign mail using the selector server-name2. In this case, you must also publish the corresponding public key under this selector in the served domain:

server-name2._domainkey.example.org. TXT "v=DKIM1; p=..."

Also it's best if the server advertises this server-name2.example.com in various places, especially in the HELO/EHLO. Some servers check this to correspond to the IP address from which the connection was received, in addition to the PTR check.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.