Weird DMARC record in report

[infantex]

Hi, all.

After the cPanel "incident" with Tommy, I got a VPS to (temporally?) host my website. I still haven't everything ironed out. One thing I never did when hosted on Tommy was setup e-mail verification (DKIM, SPF, DMARC). I think some of that stuff was handled by cPanel.

Well. My e-mail is served by Google (I have a legacy free Google Apps account) not by the VPS (and not by Tommy before). And I'm following Google's tutorial for DMARC implementation (https://support.google.com/a/answer/10032473?ref_topic=2759254).

Right now I have the following SPF record:

v=spf1 include:_spf.google.com ~all

And the following DMARC record:

v=DMARC1; p=reject; pct=15; rua=mailto:dmarc@infantex.com.mx

We are really small (one location, three people managing less than ten e-mail accounts: each person's plus some generic ones like sales, invoicing, contact, etc.), so I'm confident none of our (legit) e-mail is originating from outside the country. 🙂

However, according to a DMARC report I just received from Google, an e-mail originating from the host garena.com was able to pass both SPF and DKIM checks! I don't know that host and have no relationship with them whatsoever.

Do you know how could they pass SPF and DKIM?

I'm attaching the report, and here's the relevant part:

<record>
   <row>
      <source_ip>166.78.71.215</source_ip>
      <count>1</count>
      <policy_evaluated>
         <disposition>quarantine</disposition>
         <dkim>fail</dkim>
         <spf>fail</spf>
         <reason>
            <type>sampled_out</type>
            <comment/>
         </reason>
      </policy_evaluated>
   </row>
   <identifiers>
      <header_from>infantex.com.mx</header_from>
   </identifiers>
   <auth_results>
      <dkim>
         <domain>garena.com</domain>
         <result>pass</result>
         <selector>mailo</selector>
      </dkim>
      <spf>
         <domain>garena.com</domain>
         <result>pass</result>
      </spf>
   </auth_results>
</record>

I'm also a little confused, the auth_results section reports a pass for DKIM and SPF but the policy_evaluated section reports them as fail.

Any comments or ideas?

Regards,

google.com!infantex.com.mx!1631664000!1631750399.xml

[balloons]

Include it in the TXT record of the name server for your domain.
You should be able to get enough information on this by searching SPF or DMARC on Google.

Free Google Apps account is currently Google Workspace, but it works as long as there is no domain change.
Therefore, the Google Workspace documentation can also be a solution tip.

[infantex]

20 hours ago, balloons said:

Include it in the TXT record of the name server for your domain

What should I include?

According to what I read, I already have all the necessary TXT records set up (SPF, DKIM and DMARC).

Do you mean I would get the answer to my question by including something in some unspecified TXT record? (My question was how an e-mail originating from garena.com was able to pass my DKIM and SPF rules?)

Regards,

[balloons]

I checked your server with dig.

$ dig infantex.com.mx txt

;; ANSWER SECTION:
infantex.com.mx.        300     IN      TXT     "v=spf1 include:_spf.google.com ~all"

TXT records only return SPF. There is no DMARC. Something is wrong with the record settings.

Please note that the SMTP server also processes the received mail.
Putting incoming mail into a mailbox is the work of SMTP, and receiving from the mailbox is the work of POP or IMAP.

[balloons]

Since you have set "~all", In this case, some mail servers such as Google Workspace will be passed.
This is a consideration if you forget to add a server to your SPF configuration.

https://support.google.com/a/answer/10683907

If you obviously refuse to send mail from other servers, you can use "-all" instead.

[infantex]

Just for your reference, I know I have DMARC and DKIM records set. I set them up in Cloudflare and checked them in dmarcanalyzer.com (about a month ago).

 

For some reason (probably by design?), dig doesn't return DKIM and DMARC records, even though they're TXT records.

I searched, and found that you have to use the following syntax to query for DKIM and DMARC records using dig:

dig selector._domainkey.domain txt
dig _dmarc.domain txt

Tried it with my site and obtained the corresponding records.

I still don't know how garena.com-originated emails are able to pass DKIM and SPF checks... Or I may be reading the DMARC report wrong.

The auth_results section lists both DKIM and SPF tests as pass, but the policy_evaluated section (for the same record, if I'm reading correctly) lists them both as fail. I'm baffled!

As for the ~all qualifier, since I don't know any better and it's the configuration recommended by Google (at least for beginners), I used it.

[infantex]

I think I (partially) know what's happening.

What lit the fuse was the selector field of the DKIM field. I had forgotten it even existed (quite easily since I only used it once about two months ago when setting up my VPS, and then I just copied it from Google's recommendation).

Today I received another DMARC report and there were two valid e-mails originating from a Google-owned IP and passing all tests -- and the selector for DKIM was google. This selector thing was fresh in my mind for having answered @balloons about my (supposedly) nonexistent DKIM and DMARC records (you had to specify the selector when querying with curl).

At first I thought someone had somehow added a DKIM selector (mailo from the DMARC report) to my domain. So I queried for it, but no, there was none.

But, sure enough, garena,com had one. 

So, what I think is happening is that someone with a garena.com account is sending mail with altered headers, as to appear e-mail is from us (infantex.com.mx). Such e-mails are passing garena.com's SPF and DKIM tests because they're in fact originating from garena.com, thus the pass results in the auth_results section of the DMARC report. But they are failing DMARC, so they're being rejected or quarantined as per the policy_evaluated section. I think the combination of SPF, DKIM and DMARC is what's filtering those e-mails, how exactly, I don't know. But it seems DMARC is not accepting the passing SPF and DKIM results from garena.com. Good!

One thing I noticed is that garena.com's SPF record includes _spf.google.com, as does mine. I don't know if that's legit (meaning legitimate e-mail from them occasionally uses Google's servers) or an attempt to hijack a lot of Google-hosted e-mails. 

I'm more at ease now! 🙂 

[wolstech]

1 hour ago, infantex said:

One thing I noticed is that garena.com's SPF record includes _spf.google.com, as does mine. I don't know if that's legit (meaning legitimate e-mail from them occasionally uses Google's servers) or an attempt to hijack a lot of Google-hosted e-mails. 

 

Every organization using Google Workspace will have include:_spf.google.com in their SPF. That's the standard SPF record recommended by Google for Google Workspace setup.

GArena is a legitimate gaming platform. They own that domain, and they probably use Google Workspace internally. GArena doesn't offer public email service, so the odds they're actually sending these emails is low. What doesn't make sense is why the DKIM passed...

One of the downsides to using Google (or any major cloud email provider) for email on your own domain is what you're seeing here. A spammer can use Google to send spam with a fake From header for any other domain using Google email, and the spam will pass an SPF check. SPF lost a lot of its effectiveness when massive cloud email services became common...it's more effective when domains have their own mail server.