My Email Has Been Abused for Spam

I’m using DMARC with policy p=reject for my private email domain swznet.de. SPF and DKIM are set up accordingly. My email address has been abused for a spam campaign. Here’s what I learned.

I noticed the spam campaign by an unusual amount of non-delivery reports (i.e., bounces) in my inbox. The original messages had varying recipients, but always used my private email address in the From: header. The contents were varying, poorly translated German texts suggesting erotic encounters. Some bounces had a nude image attached, which I saved for… forensic purposes.

Apart from typical tricks like invisible HTML text aimed at confusing Bayes filters, some of the spam mails even included a DKIM-Signature with my domain d=swznet.de. However, the selector was chosen arbitrarily and did not match the actual selector, thus the DKIM signature check was guaranteed to fail.

DMARC Setup

The SPF/DKIM/DMARC setup of my domain is as follows:

swznet.de.        IN TXT "v=spf1 mx -all"
_dmarc.swznet.de. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@swznet.de; ruf=mailto:dmarc@swznet.de; fo=1"
[selector]._domainkey.swznet.de. IN TXT "v=DKIM1;t=s;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMII[...]"

The rua and ruf address forwards DMARC reports to my inbox and to the folks at dmarcian.eu, who granted me a free personal account for analyzing DMARC reports.

Tracing the Spam

Figure 1: My server receives bounces and DMARC reports, but is not involved in the delivery of the spam mail.

Within four days, I’ve received 174 bounces and 12 aggregate DMARC reports covering 25 emails. Based on this information, we can reconstruct the communication as shown in Figure 1. As my server is not involved in the delivery of the spam mail, we can only learn about the communication indirectly from the bounces and DMARC reports reflected back to my server. Spam mails originate from various senders, which send them to relays, which distribute them to recipient servers. Some of the relays generate bounces upon delivery failures, which are sent back to my server. Some of the recipient servers generate DMARC reports, which are sent back to my server. In several cases, there is more than one relay in the communication path.

Apart from the DMARC aggregate reports (rua), I have also received 2 DMARC failure reports or forensic reports (ruf). Failure reports are similar to bounces in that they contain the headers of the rejected message. However, failure reports are generated by the server that rejected an incoming email, unlike bounces, which are generated by the server that failed to deliver an outgoing email.

Neither the bounces nor the DMARC reports pose a complete picture, but each one complements it. While there are more bounces than DMARC reports and each bounce carries more information like full message headers, they are harder to parse than DMARC aggregate reports, which use a standardized XML format. I found the best insights from looking at the easy-to-read DMARC analysis at dmarcian first, then delve into corresponding bounces in my inbox (if present).

Analysis of DMARC Reports

Figure 2: Dmarcian classifies emails as DMARC Capable, Forwarded or Threat/Unknown.

The reports originate from a total of 5 organizations (Google, Yahoo, wp.pl, infomaniak.com and hirslanden.ch). Let us look at the analysis by dmarcian. By looking at the overview by in Figure 2, how many emails do you think have passed the DMARC check? The correct answer is one.

Figure 3: Senders that dmarcian thinks are legitimate.

While I would intuitively expect that green means legitimate emails, it actually means emails from sources (senders) that dmarcian has deemed as legitimate. These sources are shown in Figure 3. SPF-Identified Servers refers to my mail server, which sent one legitimate email to the DMARC reporter wp.pl, indicated by a 100% rating on the DMARC check. SendGrid is a transactional email provider, which dmarcian thinks is trustworthy, but failed the DMARC check.

Use Case: Misaligned Transactional Email

Figure 4: Yahoo reports a rejected email from SendGrid.

The details of the failed DMARC report generated by Yahoo are shown in Figure 4. The email in question carries a valid DKIM signature from d=sendgrid.info. Furthermore, it uses transactional.go-parts.com as MAIL FROM domain, which has a valid SPF setup that includes the SendGrid sender address. So what’s wrong with the email? The From: header in the message contains my domain swznet.de, which differs from the DKIM and SPF domains. The From: address is essential here, because this is the sender address that mail user agents work with. The sender domain has failed the alignment check required by DMARC and was ultimately rejected by Yahoo.

My best guess is that go-parts.com is a customer of SendGrid, whose access has been somehow abused by the spammer. I did not receive a bounce and thus have no clues that support this assumption. I would not blame SendGrid for being abused, however, they’ve made a clear mistake here: why is SendGrid attempting to send misaligned emails? As a professional transactional email provider, they should know that the email in question fails DMARC alignment and warn their customer to begin with. This email never should have been relayed. Dmarcian’s green-colored classification as a DMARC Capable sender is misleading in this case, because this is not an authorized sender.

Use Case: Forwarder to Third-Party Mailboxes

Figure 5: Yahoo reports a rejected email from grenoble-inp.fr.

Let us dive into the reports of dmarcian’s Threat/Unknown category. As shown in Figure 5, Yahoo sent a DMARC report about a rejected email from *.grenoble-inp.fr, which furthermore has sent bounces because it could not relay emails to aol.de, arcor.de, telenet.be and versanet.de. Grenoble INP is an academic institution, which are in my experience infamous for relaying a portion of emails to third-party email providers. Students and academic staff often like to forward university emails to their personal mailboxes somewhere else. This behavior is less common with corporations or agencies, because they often disallow relaying emails outside of their organization.

This is a prime example why SPF alone is harmful with DMARC: if people forward emails from their organization to their personal mailbox, this will break SPF. If this was a legitimate email, DKIM would have been required to survive the relaying. However, in this specific case the email is garbage anyway, as the sender had been spoofed.

Use Case: Abused Sender

Figure 6: Google reports a rejected email from mm-koizumi.co.jp.

Another Threat/Unknown report has been sent for mm-koizumi.co.jp (Figure 6), which furthermore sent bounces due to delivery failures to gmx.de, hotmail.de, live.at, skynet.be, t-online.de, web.de and others. According to their website, mm-koizumi.co.jp is a local Japanese scooter shop. Why would they send emails to various European mailboxes? Obviously, their server has been abused to distribute spam. Thus, it is fair to classify the sender as a threat.

Use Case: Shady Forwarder

Figure 7: Yahoo reports a rejected email from carrierzone.com.

I have received a similar Threat/Unknown report for carrierzone.com (Figure 7), which also sent bounces due to delivery failures to freenet.de, skynet.be, web.de, yahoo.de and others. An X-Authenticated-User header from the bounces indicates that carrierzone.com is relaying emails for a customer. What I find odd is that the bounced messages contains a DKIM signature from d=carrierzone.com, while the DMARC report from Yahoo contains no DKIM information.

Figure 8: Google reports a rejected email from megamailservers.eu, which has been forwarded by carrierzone.com.

To complicate things further, there is another report (Figure 8), which indicates that carrierzone.com forwarded an email to megamailservers.eu, which forwarded it to Google. In this case, Google reports that the email had a DKIM signature from d=carrierzone.com, but the signature has failed. The DKIM signature would not help anyway, because it is not aligned with the From: domain swznet.de. Google detected a forwarding setup and decided to quarantine the email instead of rejecting it.

Is this the case of an abused sender? What I find suspicious is the self-description of carrierzone.com on their website as a service provider that “take over your abuse mail and remove the spammers and abusers”. They claim to remove spammers but fail to perform SPF/DKIM/DMARC checks when relaying spam emails? Either carrierzone.com is bad at their job of removing spam or acts as a facade for distributing spam.

Use Case: Neutral Forwarder

Figure 9: Yahoo and Google report multiple rejected emails from secureserver.net.

The majority of emails have been classified as Forwarded. Figure 9 shows a rather dull example of secureserver.net, an email service provided by the web hosting company GoDaddy. A bunch of different servers sent emails to Yahoo and Google, who rejected them. There is no DKIM or SPF information. There are no bounces from secureserver.net in my inbox.

Dmarcian obviously trusts secureserver.net not to be the origin of spam, because of their classification as Forwarder and not as Threat/Unknown. I cannot tell, because I have zero information about the actual source of spam.

What is the Point, Anyway?

Figure 10: Yahoo and Google reported rejected emails from kundenserver.de.

The same Forwarded use case is shown in Figure 10, but slightly more descriptive due to extra information. It seems that kundenserver.de is being used as an email relay for hosted domains like metalquote.de or bsk-kameraden.de. This can be deduced from the SPF domain field. Unlike secureserver.net, kundenserver.de uses the relay domain as MAIL FROM and not the spoofed sender domain. A couple of bounces reveal more information about the spam sender. These bounces have not been sent by kundenserver.de, but instead by senders in Japan and Russia trying to deliver spam to kundenserver.de without success.

One DMARC report contains DKIM domain d=quillayino.cl. Tracing this domain in my inbox reveals several bounces, which point to delivery attempts to gmx.ch, hotmail.de, outlook.be, web.de and others. Some of the bounces contain Received headers with various origin addresses. Dissecting those Received headers, I come to the following findings:

1. The HELO address has been spoofed.
2. It is getting exhausting to track spam origins and there is no point, really. The origin addresses point to China, Norway, Spain, the US and whatnot. Whether these are abused open relays, botnet zombies or machines leased by the spammer, is not making any difference to me.

Conclusions and Recommendations

(1) Set up both SPF and DKIM before publishing a DMARC policy with p=quarantine or p=reject. DKIM signing is the absolute minimum. SPF is not sufficient, as we have seen from the forwarding setups that would break SPF.

(2) Analyze DMARC reports. DMARC aggregate reports are useful to identify sources that you may have forgotten to include in your SPF/DKIM domain setup. If you do not catch up to authenticate your legitimate sending servers, your emails are at risk of being rejected. On the other hand, I find it exhausting and rather pointless to sleuth individual spam senders and would not recommend, unless you are looking for a new time-consuming hobby.

(3) Implement DMARC validation and honor the sender’s policy. In the above examples, we have seen relays that could have easily rejected spam senders based on the DMARC policy, but have not. If you run a mail server, implement DMARC validation to reduce spam. If you are a transactional email provider, warn your customers about DMARC violations before accepting their emails, because otherwise this degrades your quality of service.

(4) Send DMARC reports. Consider being a good Internet citizen and sending DMARC aggregate reports to third parties. These reports help senders to identify their SPF/DKIM/DMARC problems when trying to communicate with your server, which ultimately benefits you as well. Your users will thank you for being able not only to send but also to receive emails.

Acknowledgements

Thanks to dmarcian.eu for the free personal account, which allowed the analysis in this article.