Home / server / Questions / 1145110
Accepted
x-yuri
Asked: 2023-10-04 20:50:58 +0800 CST

Should HELO, MAILFROM and From use the same domain?

  • 772

I configured a mail server a couple of times before and I believe back then I thought that the answer is "yes."

But I'm about to configure another one, and it seems that I was wrong. Let's say the apex domain (example.com) and the (only) MX record point to the same server (mail.example.com). Then I can make:

  • example.com point to the server IP (aa.aaa.aa.aaa) and point it back (PTR) to example.com
  • a mail server (postfix, exim, ...) respond with example.com (HELO, MAILFROM)

Then the SPF, DKIM and DMARC record names are: @, mail._domainkey (if selector is mail) and _dmarc. Or to put it briefly:

@  A  aa.aaa.aa.aaa
@  MX  10  mail
mail  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  @

@  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

But what if I have 2 MX records (mail1 and mail2)? Then I can't make example.com point to 2 different IPs and point them back to example.com, can I? But even if I can, I can see that Gmail doesn't use gmail.com for HELO, MAILFROM. And it seems more sensible for each server to respond with its own name, doesn't it? But then what, I should have 2 SPF records? After all:

the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address

http://www.open-spf.org/Introduction/

@  A  (whatever)

@  MX  10  mail1
mail1  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  mail1

@  MX  20  mail2
mail2  A  bb.bbb.bb.bbb
bb.bbb.bb.bbb  PTR  mail2

mail1  TXT  (SPF)
mail2  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

To be frank I'm confused after reading different articles and answers on configuring a mail server. What is the correct or a better setup?

email

1 Answers

  1. Best Answer

    The HELO hostname can be different from the sender

    The HELO hostname should have a matching A & PTR, but they do not have to match the domain used in neither RFC 5321 MAIL FROM nor RFC 5322 originator fields From header – nor even share an organizational domain.

    E.g., mail1.example.com & mail2.example.com could well send mail for example.com, example.net & example.org. Otherwise, every domain would need an own IP address with a matching PTR record. Think of the amount off domains large email service providers are handling, and they certainly use a common infrastructure for them all.

    MX records are for incoming mail

    The MX records do not relate to sending mail but to receiving it. In the scope of your question there is not any kind of relation between them. The inbound mail could be handled by a different set of servers altogether. E.g., newsletters from a domain could be sent using SendGrid or MailChimp while the incoming mail is handled by M365 or Gmail.

    Origin of HELO/DNS mismatches

    Using HELO / A / PTR mismatches as an indication of spam is common, as described by, e.g., MXToolBox:

    • SMTP Banner Check:

      Some receiving mail servers may use a mismatched or masked banner as an indication of a possible spam source in a scoring system, but most will not reject incoming mail solely on this basis.

    • SMTP Reverse DNS Mismatch:

      Some receiving mail servers may use this as an indication of a possible spam source in a scoring system. Most will not reject incoming mail solely on this basis. We recommend that you contact your ISP and ask them to setup a reverse record (PTR) that matches the hostname of your mail server.

    This practice probably comes from an interpretation of RFC 5321, 2.3.5:

    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.

    However, it is not a hard requirement, as the 4.1.4 further defines, that:

    The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name.

    An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis.

    Here, the SMTP protocol seems to follow the robustness principle i.e. "be conservative in what you do, be liberal in what you accept from others".

    SPF

    It is mandatory for the Sender Policy Framework (SPF) implementations to protect the MAIL FROM identity (RFC 7208, 2.4) and it can optionally protect the HELO identity (RFC 7208, 2.3), too:

    It is RECOMMENDED that SPF verifiers not only check the MAIL FROM identity but also separately check the HELO identity by applying the check_host() function (Section 4) to the HELO identity as the <sender>. Checking HELO promotes consistency of results and can reduce DNS resource usage. If a conclusive determination about the message can be made based on a check of HELO, then the use of DNS resources to process the typically more complex MAIL FROM can be avoided.

    As this is done independently, SPF does not require them to match, either.

    SPF protects the hostname from being used as the envelope sender without permission, and it is not inherited by the subdomains. Therefore, you should protect every A record you have with a corresponding TXT SPF record – not just the ones you are using for sending email.

    DMARC

    The Domain-based Message Authentication, Reporting, and Conformance (DMARC) requires a match between RFC5322.From and the Identifier Alignment as defined in RFC 7439, 3.1. Those identifiers can either be DKIM-Authenticated (3.1.1) or SPF-Authenticated (3.1.2) and depending on the mode it could require an exact match or a shared organizational domain (3.2). Unlike SPF, DMARC is inherited; a DMARC policy at the domain apex protects all the subdomains from being used in the From header, too.

    The SPF alignment requires a matching MAIL FROM, but the DKIM alignment does not; it is sufficient to have a valid and authorized DKIM signature with a matching signing Domain identifier (SDID) (d= field). As a bottom line, neither of these requires a matching HELO/EHLO hostname.

    • 2