Someone spoof my domain email

Dear Community,

I am hoping to get help here.

I am currently helping out an NGO to manage their domain name. The domain was re-registered in January 2022. Prior to that, the domain was inactive (expired for a few years).

It as come to our attention that someone used our email info @domain.com to send out email without our knowledge in April 2022.

  1. My assumption is that:

i. someone that managed the email and domain previously might have added and verified the info @domain.com to email marketing platform such as mailchimp or etc.
ii. similar to point 1 above but this time to gmail so that can use the “send as” feature.

  1. I was thinking, does the email sender record such as IP address, email client, etc. were recorded somewhere either by DNS provider (in this case is Cloudflare) or by registrar or by any other party?

We have contacted the recipient and they refused to provide us the email details.

  1. I have received and checked one of the abnormal record in the DMARC report sent by Google. Would appreciate your input. The report as below. I have rename the domain name and IP address for privacy purposes.

11.12.3.133.69 = not real IP address , it is also the IP address of the web hosting company that host otherdomain .com
mydomain .com = the domain I manage
otherdomain .com = not related to us
myemailserver .com = this domain related to the email marketing platform I am using and I have added in my domain spf setting.

<record>
    <row>
      <source_ip>**11.12.3.133.69**</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>**mydomain .com**</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>**otherdomain .com**</domain>
        <result>pass</result>
        <selector>default</selector>
      </dkim>
      <dkim>
        <domain>**mydomain .com**</domain>
        <result>fail</result>
        <selector>ml</selector>
      </dkim>
      <dkim>
        <domain>**myemailserver .com**</domain>
        <result>fail</result>
        <selector>ml</selector>
      </dkim>
      <spf>
        <domain>**otherdomain .com**</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  1. My understanding is that otherdomain .com sent an email claiming it from mydomain .com
    Since the IP address is the IP address of the otherdomain .com web hosting company, I assume that the sender sent email from their cpanel webmail, or could it be from their gmail but using cpanel smtp?

For this auth_results part, why is the result “pass” for dkim and spf ? The otherdomain .com is not in my domain dns setting at all.

<auth_results>
      <dkim>
        <domain>otherdomain .com</domain>
        <result>pass</result>
        <selector>default</selector>
      </dkim>
.
.
.
<spf>
        <domain>otherdomain .com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  1. Is there a way to record all recipient email address whenever myself or anyone send email using my domain?

Thank you very much for your help.

Welcome to the dmarcian forum, @bonushitz.

In any examples, if needed, I will use example.com as the “other domain” and example.org to represent your domain.

You are definitely in the right place to talk about email spoofing and the steps you can take to mitigate its impact on your domain.

I notice you have included edited XML DMARC reports in your post. I presume that you are having DMARC reports sent to a mailbox that is used by a human. Normally you want those reports to go to a service provider like dmarcian, so the reports can be digested by software and turned into a more useful format. Until you reach that point in your DMARC journey, dmarcian has a DMARC XML to Human Converter that can make the information in those XML files easier to use.

The first thing to understand about DMARC reporting is that there are 2 “From” values involved, and both are trivial to forge. The one in the SMTP transaction is commonly called the return-path. It is presented in the exchange between the mail relays. It is comprised of everything after the @ sign in the address that the sending server has used to identify the sender. The other “From” address is the one that appears in the recipients email client, and is actually part of the message content that appears following the DATA directive in the SMTP exchange.

Either “From” field in a spam email will contain whatever the spammer has instructed the spam email to use. The domain portion of the return-path is what is used by the recipient’s mail server to lookup an SPF record which is then compared with the IP address used by the sending relay. If the sending IP is included in the SPF record that results in a passing SPF check.

The domain in the body “From” is used for DKIM validation. A secret key that corresponds to a public key is used to sign parts of the message. That key has a name which is known as the selector, and has a corresponding public key that is published in that domain’s DNS. By using the selector to determine which public key to use that signature can then be verified. DKIM includes an additional component known as alignment which defines the required relationship between the domain in the return-path and the domain in the message body “From” field.

It is possible for an email to pass either a raw check for SPF or DKIM and still fail DMARC due to failing alignment. Take your example.com DKIM result that indicates it passed. This means the message was signed with the private key that corresponds with the public key published at default._domainkey.example.com. For the SPF check to pass, all that is required is for the return-path to use the domain name of example.com and have a published SPF record that includes the IP of the spam relay.

DMARC is all about proving that the message body “From” is authentic. If you have the correct elements in place and working properly, a spammer cannot use your domain in that field and pass DMARC validation, even if they can pass some of the raw tests.

You mentioned that you contacted the recipient of the forged email and indicated that party was unwilling to provide you with a copy of the message. I’m not sure how you became privy to the recipient’s address, as that is not something that is included in a DMARC RUA. It might included in a DMARC RUF, but those have generally fallen out of use due to disclosing too much personal information.

I wouldn’t spend too much time attempting to determine whether not not the spammer uses cPanel, as knowing that isn’t going to be useful to you. It is far more likely that the spammer uses custom spam software. There is a thriving criminal industry that has been serving that illicit market for nearly as long as email has existed.

You asked whether or not you can keep a record of all recipient addresses that you send email to. You certainly can, although it is outside of the scope of DMARC and the underlying components that power it. I expect that your marketing platform already has that information in your campaign history.

The most important thing to remember about email is that anyone can spoof your domain all they want and there is nothing you can do to prevent that from happening. What you can do, is publish the criteria by which email claiming to be from domain can authenticated. That is what DMARC does. Whether or not a receiving email server uses your published DMARC data to validate email claiming to be from your domain is also completely out of your control. You can think of it like this: You tell people that you will always be wearing an ID badge, but someone pretending be you interacts with someone else who doesn’t ask to see the ID badge. That is effectively what happens when you send DMARC compliant email to a recipient that doesn’t check DMARC.

While I don’t know if any of my response has been helpful, I hope that it has. My recommendation is not get too bogged down in the minutiae of one specific spoofing incident, as it it is not the sort of mystery that is likely to be solved, and it isn’t going to be the last time your domain is spoofed. My primary domain has the strongest level of DMARC protection possible for close to a year and was spoofed 421 times in the past week, and that is just the emails that were directed to providers that send DMARC reports. None of those forged emails made it to the spammer’s target inboxes because of my strong DMARC policy and the fact that target mailbox providers are active checking that DMARC policy.

When you take a step back from the incident that triggered your digging deeper into the topic of email authentication, ask yourself what your business objectives are in relation to defending your domain against email spoofing. Once you have that defined you can move further into your use of DMARC. I strongly encourage the use of a service like dmarcian to save you the headache of manually dealing with what will quickly become an overwhelming number of DMARC XL reports. Dmarcian has excellent guidance in their dashboard to assist you in navigating your way to a strong DMARC posture.

Hi ,

Thank you for the detail response and sharing. Thanks for sharing about Dmarcian too, will definitely check it out. I am not aware of it until was referred here by Cloudflare community.

  1. We have contacted the recipient requesting for the email body because the recipient is the one that get in touch in the first place to verify if the spam email is from us or not

  2. I am glad that you came to response and share about your domain DMARC. Do you have suggestion on how to configure a strong level of DMARC protection?
    Below is my current configuration, would appreciate your input.

v=DMARC1; p=reject; sp=none; adkim=s; rua=mailto:ed9f9b88e69b.a@dmarcinput.com,mailto:re+wqxm15cmlhk@dmarc.postmarkapp.com,mailto:c7yxibawjo@rua.powerdmarc.com; ruf=mailto:ed9f9b88e69b.f@dmarcinput.com,mailto:c7yxibawjo@ruf.powerdmarc.com; aspf=s; fo=1; pct=100

Besides, since the "p=reject , if the spammer email failed, will it forward to the domain owner? If yes, great, so we could get the email body and sender details.

If not, how can we configure that the failed email will be forwarded to domain owner?

  1. My current marketing platform do keep the subscribers details.
    Our members also send email to us at info@example.org and these email will be redirect to gmail account. The we reply to these email using the “send as” feature.
    As a NGO, we have some other board members that responses to the members emails. We would like to capture the recipient email addresses incase if the “sent” email got deleted and we have no way to trace the recipient. So if possible, to trace all recipient email addresses no matter where or how the email was send from using our domain.

  2. Actually the content of that message is insulting the NGO and the current President of the NGO. Thats why we think that it might be some insight job or someone that manage the domain and email previously. That is also why we are trying to get to the bottom of this.

Thank you for your understanding and kind assistance.

That was me. :smile:
I wanted to continue the conversation you started, but it was off-topic for Cloudflare and I wanted to respect that forum, which is why I suggested moving the conversation here, where it is on topic.

That clears that up, though it does make me wonder why they wouldn’t share the whole message if they were the ones bringing it to your attention. However, that’s probably not worth delling on.

That certainly makes for a different situation that garden variety spam that just happens to be forging your domain.

You can’t. You don’t have control over the mail sent by others.

In order to accomplish the goal in the second quote, your best option is to abandon the practice your cite in the first segment that I quoted in this reply.

Forwarding to Gmail and replying with “sends as” is something you will want to put an end to. If everyone in the NGO likes Gmail, the best option would be to move your domain email to Google Workspace. If archiving emails is a mission critical function, your NGO is going to need to invest in an immutable email archive system. You could use a system like Google Vault that is available in certain Google Workspace plans, or you could use use a third-party system that sits between your Gmail and the internet and captures all mail to archival storage.

The most important first step is going to be getting authorized access to domain email under control, and that is not going to happen with your current practice of forwarding it to Gmail accounts. If accountability and auditing is important, you also will need to make sure that there are no shared credentials in your organization. If you have an email address like info@ where more than one person may need to reply, you will want to create that as an alias or group so that the actual respondent’s identity is logged.

Please note that setting sp=none without also setting aspf=s means that the default DMARC policy for subdomains is none, and will be treated as such unless explicitly specified for a particular subdomain.

Then an adversary can forge mail from @example.org by setting the envelope.from/ return path to a subdomain, e.g. @totallylegitmailhost.example.org which may not even exist in DNS. The recipient’s mail exchange will deliver the mail to the inbox as the DMARC policy for subdomains is none, and the default for a non-existing or failing spf record is ?all.

With aspf=s, the from address must also be a subdomain of example. org for the mail to be delivered.