Fake email to domain mail with configured SPF, DKIM and DMARC - how is it?

Question

SPF

Just yesterday, we transferred domain mail to a new VPS
. And a message arrived like this:

naturally, there are fake (phishing) links

; email headers:

Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Mon, 10 Jan 2022 15:04:45 +0300
Received: from [212.192.246.201] (helo=silver.earacheevince.com)
    by server.com with esmtp (Exim 4.94)
    (envelope-from <[email protected]>)
    id 1n6tPo-00063H-RY
    for [email protected]; Mon, 10 Jan 2022 15:04:44 +0300
From: domen.ru <[email protected]>
To: [email protected]
Subject: ACTION REQUIRED
Date: 10 Jan 2022 13:04:44 +0100
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

By the time this letter was received, the SPF record, DKIM signature, and DMARC policy were already configured:

v=spf1 ip4:наш_почтовый_сервер include:mxsspf.sendpulse.com include:mxsmtp.sendpulse.com +a +mx ~all
v=DMARC1; p=quarantine; aspf=r; sp=none; rua=mailto:[email protected]

p=quarantine - means to send messages to SPAM that didn't pass DMARC check - is that right?

why did a message that is not signed by DKIM and for which:
212.192.246.201 (helo=silver.earacheevince.com)
not allowed in SPF arrived in the Inbox, and not in the SPAM folder?

VPS tech support writes some nonsense:

You have turned off the Greylisting check method.
Turned it on, this should help to reject spam that will come to your service.

shta? what about Greylisting? Is this some kind of incompetence on the part of hosting technical support?

it turns out that the letter came from our address: [email protected] to our address: [email protected] and quietly got into the inbox without checking SPF, DKIM and despite the DMARK policy? how is this possible? Or did the letter fall into the period of incomplete updating of DNS records?

Answer 1

The fact that you have configured dkim, spf, dmarc and ptr is fine (by the way, this is far from all - mta-sts is also highly desirable and it would be nice if tlsa dane took care of it) - but what does this have to do with the fact that with all this verification the mail HOST SERVICE ?
If your client, for whom you are worried, has a mail service set to "accept everything", then he will receive all phishing letters supposedly from you. Well, it means he is SSZB. You did what you could.
In your situation, it was so - your mail service was not strictly configured to receive mail (and this, by the way, is correct - because it is generally unacceptable not to receive important and necessary mail - you need to slowly tighten the protective nuts).
PS
What you wrote in dmarc "quarantine" is a recommendation to the service of the receiving party - he can fulfill it, or maybe wipe himself, because he is not obliged to take into account your Wishlist!
Here is my example for you (in general, p=reject is written in my dmarc). Once, when updating the server, dkim completely crashed, and the pre-scheduled mailing list went away. So what ? In gmail, letters successfully got into the "Inbox" for all clients, although the dmarc report that gmail sent indicated that dkim was missing. It's just that gmail decides what to do with the letter based on its own rules and my p=reject doesn't give a damn about it :)

Answer 2

why incompetence? the default behavior is to take everything
further, the admin configures the rigidity up to spamassasin with a captcha confirmation
, apparently, the admin is the hoster, so I learned from you for the rigidity - configured

Answer 3

It is not enough to configure the records, the mailer must also check them.
None of the headers shown are related to spf and dkim. Maybe they don't check?
From a gmail message:

ARC-Seal
ARC-Message-Signature
ARC-Authentication-Results
Received-SPF
Authentication-Results
DKIM-Signature

Ps. About the greylisting. It is possible that your hosting provider passes all these checks after being greylisted. No greylisting, no checks. Anything can happen