On 2018-02-19 12:57, Markus Wild wrote:
Hi there,
I've just come across a weird mail reception problem of some mails from Microsoft. Our servers insist that a specified MAIL FROM address can be resolved correctly, and this usually boils down to the following checks on the domain-part of the email-address specified:
- is there an MX? Does the target resolve using an A record (not a CNAME), and does it resolve to a publically reachable address (not RFC1918 or localhost etc)
- if there is no MX, is there an A record that fulfils the same criteria as the MX target above?
If you are anti-spam, don't bother checking this (dom.com A); anybody who wants to receive mail will have an MX, if not, let them join the 2000s...
Also, instead of bothering with the MX Lookup, verify and enforce SPF, DKIM and DMARC instead, they are meant for checking against the envelope From, MXs are not. Non-existence of a MX on a domain does not mean it does not get used for sending mail; thus you might have a small false positive rate there... (which you might chose to accept, you are the receiving end, hope you have an informative rejecting message ;) )
Spammers will make sure that MX, SPF, DKIM and DMARC are all configured btw; they only really 'resolve' spoofing issues.
[..]
- if none of these are true, the address is considered to be invalid and mail is rejected
I assume you also allow '<>' for DSNs?
If you do the above, you might want to check for "MX .", this indicates a domain that will never send mail as per RFC7505:
https://tools.ietf.org/html/rfc7505
I set that for every domain that I don't actually use for mail and quite a few marketing hosters are pretty good at it too.
But again: MX is for _receiving_, not _sending_ (From) thus checking it is a bit wrong, but at your prerogative.
Last note: do _not_ use 'host' for debugging DNS related issues, always use the very useful 'dig' tool, or if you want use 'drill' instead. ('host' hides various error situations and does not properly show what you are actually querying...)
Greets, Jeroen