Spam emails from cloudflare ip

I’m receiving some spam emails from cloudflare ip addresses, they(hackers) want to ruin the reputation of my domain - nvoids.com

Should I remove spf.mx.cloudflare.net from nvoids spf records? (include:_spf.mx.cloudflare.net )

Attached the screenshot.

The original message link

Authentication-Results: spf=pass (sender IP is 104.30.8.210)
 smtp.mailfrom=nvoids.com; dkim=pass (signature was verified)
 header.d=cloudflare-email.net;dmarc=pass action=none
 header.from=nvoids.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of nvoids.com designates
 104.30.8.210 as permitted sender) receiver=protection.outlook.com;
 client-ip=104.30.8.210; helo=i-cba.cloudflare-email.net; pr=C
Received: from i-cba.cloudflare-email.net (104.30.8.210) by
 SA2PEPF000015CB.mail.protection.outlook.com (10.167.241.201) with Microsoft
 SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.7452.22
 via Frontend Transport; Sun, 14 Apr 2024 05:32:41 +0000
X-IncomingTopHeaderMarker:

Regards,
Pradyut

You would have to dig deeper into the headers to find the actual problem, such as e.g. here:

ARC-Authentication-Results: i=1; mx.cloudflare.net;
	dmarc=none header.from=nvoids.com policy.dmarc=none;
	spf=none (mx.cloudflare.net: no SPF records found for [email protected]) smtp.helo=amcs.com;
	spf=none (mx.cloudflare.net: no SPF records found for [email protected]) [email protected];
	arc=none smtp.remote-ip=27.196.75.182
Received-SPF: none (mx.cloudflare.net: no SPF records found for [email protected])
	receiver=mx.cloudflare.net; client-ip=27.196.75.182; envelope-from="[email protected]"; helo=amcs.com;
Authentication-Results-Original: mx.cloudflare.net;	dmarc=none
 header.from=nvoids.com policy.dmarc=none;	spf=none (mx.cloudflare.net: no SPF
 records found for [email protected]) smtp.helo=amcs.com;	spf=none
 (mx.cloudflare.net: no SPF records found for [email protected])
 [email protected];	arc=none smtp.remote-ip=27.196.75.182

All of this points towards that the IP address 27.196.75.182, from China Unicom delivered the message to Cloudflare Email Routing.

27.196.75.182, from China Unicom did attempt to spoof the message, claiming to be originating from your own domain name, by making the RFC5322.From / Header From: appear to be on your own domain name.

  1. Your domain name does not have a restrictive DMARC policy.

  2. Your domain name does have a SPF record, that ends in ~all, which isn’t sufficiently strict.

  3. Your SPF record has more than 10 mechanisms in it’s chain, that require further DNS lookups, meaning that theSPF will break before reaching that ~all.

Because of these things, the third part was able to spoof your domain name in this case.

So the solution would be something like:

  1. Clean up your SPF record.
    Remove e.g. include:_spf.aol.com that points to a record that doesn’t exist, and otherwise other include:'s that you do not actually use.
    include:_spf.google.com is also irrelevant, unless you have a PAID Google Workspace set up.

  2. Switch the ending of your SPF to “-all”.

  3. The quote here, if possible.

3 Likes

Unpaid gmail, outlook, yandex etc. allows to send emails from other domains once verified so that’s why google and outlook spf records are there.

I tried p=reject; but then i’m unable to send emails from nvoids.com via outlook or gmail, it’s only going through the ip addresses mentioned in spf records.

Any method to authenticate the domains in spf include if p=reject in dmarc?

If we’re talking about the “Send from other address” trick, where you incorrectly enter smtp.gmail.com as the external SMTP server, then you should remove " include:_spf.google.com".

It is only if you can have the specific RFC5321.MailFrom / SMTP MAIL FROM / Envelope From set to your own domain name, that you require their stuff in your SPF record, for SPF to succeed.

If you use the Gmail trick to send through their servers, but via your own domain name, then Gmail will still say “Hello, I’m [email protected]” to other mail servers, which means the SPF authentication will happen at the gmail.com domain, and NOT on your own domain name, rendering the include:_spf.google.com" completely useless.

See this post for more detailed information:

:point_up_2:

That sounds to be due to the missing alignment, which would be causing DMARC to fail.

DMARC requires:

SPF will either fail upon forwarding, or, if the RFC5321.MailFrom / SMTP MAIL FROM / Envelope From is rewritten during the forwarding, SPF can technically pass on the third party domain, but will fail DMARC due to the missing alignment to the original sender domain.

Your SPF authentication will therefore not be able to survive any kind of email forwarding, and will always fail after forwarding, if we’re talking about DMARC.

I would say NO, you CANNOT rely on SPF alone, if you want a strict DMARC policy.

1 Like

Difficult for me to do p=reject

I’m sending out emails via outlook groups or google groups, on receiving, gmail/yandex says spf pass as sent by outlook but checks dmarc of nvoids and says dmarc failed.

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of nvoidsusstaffing854191+srs=e6vwh=lu=nvoids.com=admin@groups.outlook.com designates 2a01:111:f400:feae::205 as permitted sender) smtp.mailfrom="nvoidsusstaffing854191+SRS=e6Vwh=LU=nvoids.com=admin@groups.outlook.com";
       dmarc=fail (p=REJECT sp=NONE dis=QUARANTINE) header.from=nvoids.com

It depends on your set up, and whether you’re willing to do changes to it.

If you choose to rely on free mail providers, as it sounds, you’re limited in the fact that the majority of them won’t do DKIM for your custom domains on the “free” side of their service.

That can indeed make it extremely difficult for your email sending.

The thing you are missing here is, as said above, that SPF can technically pass on the third party domain.

If the RFC5321.MailFrom / SMTP MAIL FROM / Envelope From isn’t on the same organisational domain name as the RFC5322.From / Header From:, you’re missing the alignment to your own domain name.

       spf=pass (google.com: domain of nvoidsusstaffing854191+srs=e6vwh=lu=nvoids.com=admin@groups.outlook.com designates 2a01:111:f400:feae::205 as permitted sender) smtp.mailfrom="nvoidsusstaffing854191+SRS=e6Vwh=LU=nvoids.com=admin@groups.outlook.com";

You see here that it says that the SPF was passing with the @groups.outlook.com email address, as that domain designated 2a01:111:f400:feae::205 as a permitted sender.

The RFC5321.MailFrom / SMTP MAIL FROM / Envelope From was therefore set to that @groups.outlook.com address, when Outlook delivered it to Gmail.

This means that the SPF check is done using the record you can retrieve from a query on the groups.outlook.com (sub-)domain.

# dig +noall +answer TXT groups.outlook.com
groups.outlook.com.     300     IN      TXT     "v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:157.55.9.128/25 include:spf.protection.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all"

:point_up_2:

This SPF is the one that matters, and NOT the one on your own domain name.

       dmarc=fail (p=REJECT sp=NONE dis=QUARANTINE) header.from=nvoids.com

Here you can see by the end here, the RFC5322.From / Header From: domain is nvoids.com.

As the RFC5321.MailFrom / SMTP MAIL FROM / Envelope From is @groups.outlook.com, we are obviously dealing with two completely different domains.

Since nvoids.com != @groups.outlook.com, the SPF section will always fail for DMARC, because of the missing alignment to the original domain, even when the SPF actually appear to be passing.

If you’re sending from Example Corporation’s email service, to the Outlook Groups, then you should look at adding Example Corporation’s email service to your SPF, because they are the provider you’re sending through.

You should NOT attempt to add Outlook Groups or other random third parties, as that would be a complete misunderstanding of how SPF works, and in the end, pose as a security issue for your domain.

If you’re having include:spf.protection.outlook.com in your SPF because of these Outlook Groups, - kill it, as it is completely useless.

1 Like