Management of DMARC control for email impersonation of domains in the .co TLD - part 1

Published: 2023-04-23
Last Updated: 2023-04-23 21:21:48 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
6 comment(s)

There is a cybersecurity risk inherent to the human being that we will not be able to eliminate completely and it is the implicit need to "click" on links that come to us, especially through email, which may be the prelude to the materialization of a cyber attack through an APT.

One of the favorite ways for attackers to trigger social engineering attacks is to impersonate domains that are considered trusted by companies. This allows potential victims to trust incoming emails by the email address that sends them and from there trigger the delivery of the threat.

There is a simple control to implement and it is DMARC, which is a control whose purpose is to avoid the impersonation of domains through emails. It requires as a prerequisite the implementation together of two others (SPF and DKIM). In this diary we will review the DKIM configuration status for all the CO tld with the active domain zone as of April 2023 from the website. Here are some relevant numbers from the sample:

CO tld April 2023
Total domains in zone from 388802
Total of reachable domains 371374 domains 32498 (8.75%) domains 1393 (0.37%) domains 3468 (0.93%) domains 67 (0.01%)

What are the results with the DMARC policy? 

This means 96.94% of the domains do not have any DMARC protection, 1.7% has a quarantine policy and 1.36% a reject policy, which is quite bad as the attackers has an open field to invade with attacks like spearphishing. Syntax errors are 0.26%

Let's see how this goes with domains:

This means 89.03% of the domains do not have any DMARC protection, 5.09% has a quarantine policy and 4.56% a reject policy, which is also quite bad as the attackers has an open field to invade with attacks like spearphishing. Syntax errors increased this time to 1.33%.

Email domain impersonation risk in the .co TLD is quite high. Domain admins should implement DMARC as it's quite easy:

  • If you have office365, you can follow this tutorial.
  • If you have google, you can follow this tutorial.
  • If you have linux DNS and email, you can follow this tutorial.

--------------------------------------- BEGIN OF SPANISH SECTION ----------------------------------------------------------------

Existe un riesgo de ciberseguridad inherente al ser humano que no vamos a poder eliminar por completo y es la necesidad implícita de “clickear” en los enlaces que nos llegan, especialmente a través del correo electrónico, que puede ser la antesala de la materialización de un ciberataque a través de una APT.

Una de las formas favoritas de los atacantes para desencadenar ataques de ingeniería social es hacerse pasar por dominios que las empresas consideran de confianza. Esto permite que las víctimas potenciales confíen en los correos electrónicos entrantes por la dirección de correo electrónico que los envía y desde allí desencadenar la entrega de la amenaza.

Hay un control sencillo de implementar y es DMARC, que es un control cuyo fin es evitar la suplantación de dominios a través de correos electrónicos. Requiere como requisito previo la implementación en conjunto de otros dos (SPF y DKIM). En este diario revisaremos el estado de configuración de DKIM para todos los CO tld con la zona de dominio activa a partir de abril de 2023 desde el sitio web Aquí hay algunos números relevantes de la muestra:

CO tld Abril 2023
Total de dominios en la zona obtenidos de 388802
Dominios alcanzables 371374
Dominios 32498 (8.75%)
Dominios 1393 (0.37%)
Dominios 3468 (0.93%)
Dominios 67 (0.01%)

¿Cuáles son los resultados con la política DMARC?

Esto significa que el 96,94 % de los dominios no tienen ninguna protección DMARC, el 1,7 % tiene una política de cuarentena y el 1,36 % una política de rechazo, lo cual es bastante malo ya que los atacantes tienen un campo abierto para invadir con ataques como el spearphishing. Los errores de sintaxis son 0.26%

Veamos los resultados asociados a los dominios

Esto significa que el 89,03 % de los dominios no tienen ninguna protección DMARC, el 5,09 % tiene una política de cuarentena y el 4,56 % una política de rechazo, lo que también es bastante malo ya que los atacantes tienen un campo abierto para invadir con ataques como el spearphishing. Los errores de sintaxis aumentaron esta vez al 1,33%.

El riesgo de suplantación de dominio de correo electrónico en el TLD .co es bastante alto. Los administradores de dominio deben implementar DMARC ya que es bastante fácil:

  • Si tiene Office365, puede seguir este tutorial.
  • Si tienes google, puedes seguir este tutorial.
  • Si tiene DNS y correo electrónico de Linux, puede seguir este  tutorial.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander

6 comment(s)


It'd be awesome to see a writeup of a BIMI implementation. I feel BIMI knowledge will be the main driver of DMARC adoption for most orgs.
I still don't take non-standard top level domains seriously. Watching TLD abuse statistics over at Spamhaus it looks like it's still a real mess and registrars or someone needs to hold website operators to a higher standard. Not to mention that small businesses just don't know what to do. The local hair place doesn't know that 28% of the .hair TLD websites today are considered to be "bad" (malware and botnets and such) and that will likely impact their ability to do business if they have a domain there.

The small businesses also don't care about things like DMARC and aren't going to read the reports or do anything with it because it's too hard for them. Let's not forget that DMARC is just a policy so a sending domain can tell a receiving email server what to do if SPF and/or DKIM fail. Without DMARC that decision is left up to the receiving email server which for all but those in need of the highest security is usually fine. But I do like the DMARC reports if you can digest them into one big report and see attackers trying to spoof your domain over time, and with a DMARC policy in place you will know those emails didn't make it. I mostly see DMARC putting marketing emails sent from third party marketing companies in quarantine because of SPF/DMARC configuration errors and I really don't feel terrible about that, haha.

In a perfect world I think these tools should be used such that all of your emails are signed (DKIM) but only "your" email servers are listed on your SPF policy (sort of like"hey, these are my servers, nothing to see here") and the DMARC policy tells the receiving email server to reject what fails (with aspf in relaxed mode, and dont forget that subdomain policy). Then if SPF AND DKIM fail it will be rejected but if just one of them fails it can be quarantined or whatever the receiving email server wants and business can continue as usual.

It's not perfect but there are so few standards as to how to use these tools that someone needs to do something or it isn't going to work. Microsoft will go along treating SPF as if it's written in stone while Google cares mostly about DKIM and everyone will be confused about why email lands in quarantine (this is just a random example and not actually how Microsoft and Google work). Meanwhile BIMI is just a distraction and no one really cares because your official logo appearing or not never stopped someone from clicking a link (and who is stopping to inspect that it's the official logo and not some ripoff one anyway).

Thanks for reading my email rant and keep up the good work over there!
One follow-up to my previous comment about why it would be nice if SPF could be just "your" email servers and not 3rd parties that send email on your behalf or some company that you maybe might use someday. You are limited to 10 DNS lookups in the SPF record and some website hosts try and include everything under the sun then have the websites they host all use that one record (which I feel makes SPF less useful). See for an example.
The blog posting <a href="">The Sender Policy Framework (SPF)</a> does explain well how to create a valid SPF policy. The author also provides a <a href="">CLI tool</a> for testing the currently published SPF entry for any domain and in case of it does complain with:
SPF record for domain '': invalid
Error: Too many DNS lookups (12 > 10).
Sam / fab23 That is how it is at my day job, we'd need an SPF lookup count of around 24 with everything having gone through an SPF compactor that takes all the office365, sendgrid, mailgun, etc. and pushes them into SPF as IP ranges. It does not help that there are two different divisions each with separate accounting, billing, CRM, merchant account, etc. sharing the same email domain. We get emails about twice a week from "freelance security researchers" wanting a bug bounty for pointing out that our policy is set to none due to the SPF limitations. Thankfully we are working to break some stuff into separate subdomains but even then I doubt we'll squeeze under the 10 lookup limit even with the SPF compacting.

The compacted SPF also has the issue of legit things getting bounced because one of the providers made changes which happen without notice.
It really seems like SPF should not be using DNS for hosting the authorization list, or at least provide a way to host the list off a web server or other method without the current DNS lookup limits.
What's missing here is the larger picture of risk exposure.
Let's take Bluehost and a conduct a little bit of OSINT
Bluehost are owned by NewFold and they also have many other providers in their portfolio

All are vulnerable to direct domain impersonation and it's trivial to do.

python3 -d "" --dmarc

Querying 7 domains...
DMARC record: v=DMARC1; p=none;;; rf=afrf; pct=10;
DMARC record: v=DMARC1; p=none;
DMARC record: v=DMARC1; p=none
DMARC record: v=DMARC1; p=none;;; rf=afrf; pct=10;
DMARC record: v=DMARC1; p=none;;; fo=1
DMARC record: v=DMARC1; p=none;;; fo=1
DMARC record: v=DMARC1; p=none;;; fo=1

7 of 7 domains returned

Another thing, many just focus on the primary domain, what about all the others?
NewFold likely own these, they redirect to their website (there are more).

python3 -d "" --spf --dmarc --mx

Querying 2 domains...
SPF record: v=spf1 -all
DMARC record: A DMARC record does not exist for this domain or its base domain
MX Records: 0
SPF record: v=spf1 -all
DMARC record: A DMARC record does not exist for this domain or its base domain
MX Records: 0

2 of 2 domains returned

v=DMARC1; p=none; is pointless without the RUA tag. You have no visibility while in monitor mode and you'd be guessing when trying to configure your authorised sending services for DMARC alignment.

Don't bother with SPF hard-fail, just use soft-fail, why?
A) False sense of security because hard-fail is easily bypassed. RFC5321_Mail.From will be the attacker domain and RCF5322_From will be the impersonation.
B) Hurts DMARC reporting. MTAs may honour that hard-fail and reject the message, so you'll never receive the DMARC aggregate report. The mail will be rejected as instructed, before the 'data' command and "354 Start mail data, end with CRLF.CRLF" response.

Misconception I sometimes hear, SPF soft-fail overrides DMARC enforcement (quarantine / reject). The reality is, with DMARC enforcement, SPF authentication failure is a hard-fail.

Finally, too many just focus on sending domains. Non-sending domains, should be locked down with SPF, DKIM and DMARC to instruct recipients to reject all messages.

Diary Archives