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.
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:email@example.com; ruf=mailto:firstname.lastname@example.org; fo=1" [selector]._domainkey.swznet.de. IN TXT "v=DKIM1;t=s;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMII[...]"
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
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
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.
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
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
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
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
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
Another Threat/Unknown report has been sent for
mm-koizumi.co.jp (Figure 6), which furthermore sent bounces due to delivery failures to
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
I have received a similar Threat/Unknown report for
carrierzone.com (Figure 7), which also sent bounces due to delivery failures to
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.
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
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
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?
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
bsk-kameraden.de. This can be deduced from the SPF domain field. Unlike
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
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:
HELOaddress has been spoofed.
- 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=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.
Thanks to dmarcian.eu for the free personal account, which allowed the analysis in this article.