You’ve got mail – that’s good. But who was sending you? And is the person, you receive mail from is really the person he pretends to be? And if he was, has the content been changed during transmission? There’s so many Phishing warnings out there and we are not secure anymore, right?
Well, not necessarily. The world is not as bad as you might think about. The e-mail itself has no security implemented, that’s true. But what exactly does that mean? Let’s look at this nice graphic.
In fact it’s like this: When you send the e-mail, it is delivered through several server. And each of them can read the e-mail in plain text. Mail headers are read, time-stamp added and forwarded to the next server – that’s how e-mail worked from the beginning and is still working today. If we don’t implement any security, each of the forwarding servers can not only read the mail, they can also modify. And because it’s pure text, modification is possible on each part. Sender, subject, recipient, links, attachments. That’s where it get’s dangerous. So what can we do?
For adding security, there’s some main techniques, which are already covered in the post: “[Beginners guide to Deliverability] Lesson 4, Authentication and Prevention” and discussed on our YouTube channel Deliverability.TV (will be published 30th of March 2017).
In Summary, they are:
- SPF (Sender Policy Framework): Determines which IPs are allowed to send e-mail in behalf of the domain name
- DKIM (Domain keys identified mail): Uses public/private key signatures to make sure, that the e-mail was not modified. This includes the important information, that sender can’t be forged and links can’t be changed into phishing links.
- DMARC (Domain-based Message Authentication, Reporting and Conformance): Uses SPF and DKIM for authentication and adds
- the possibility to set a policy: “How should recipient mailservers react in case of invalid authentication test?“
- reporting feedback channel: “How many messages did I receive from the specific domain and how many of them failed the authentication check?“
You should do at least SPF and DKIM. DMARC doesn’t provide additional security and is more relevant for bigger companies working in security-critical industries like finance.
If you don’t want others to read your mail, you need to encrypt. In my last post, I covered this topic in detail: Security & Encryption for Mass Messaging.
Most important encryption possibilities are:
- end-to-end: You need to agree with the recipient himself about a key. Then you can encrypt the message before sending and only the recipient can read it. It’s the most secure possibility, but requires a lot of manual work to setup – and of course it requires your communication partner to implement on his side as well. Most important technologies here are PGP and S/MIME.
- TLS: Server-encryption between your outgoing mail server and the recipients mail server. Prevents access from all forwarding servers, but on sending and receiving server, mail is stored in plain text. For end-users, this method is more or less invisible and most mail hosters for private mail have implemented it by default.
It depends on the level of privacy which method you chose. Mass-mail advertisement is still being send without TLS in many cases to save encryption effort, but personal communication should encrypt in 2017 in my opinion without exception.
How can we detect Spam or phishing now?
An a brilliant preparation for this post, I recently registered a .com domain. What happens is, that you get tons of spam from day one – obviously the WHOIS-information with contact details is harvested (e-mail address collected) and unsolicited mails are being sent.
Fortunately, next to the automatic spam filtering, the ISP of your choice offers some hints whether the security methods, that I have just mentioned are being used and successfully tested:
GMail marks unencrypted (TLS) messages with a red lock for instance:
SPF, DKIM and DMARC can be checked in the mail header. In most ISPs there’s an option called “show mail header”, “show original mail” or similar. Use the search function to check for SPF and DKIM and check if there’s a “pass” for them.
Authentication-Results: mx.google.com; dkim=pass [email protected]; spf=pass (google.com: domain of [email protected] designates 22.214.171.124 as permitted sender) [email protected]; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=reply.cyberport.de
Received-SPF: fail (google.com: domain of [email protected] does not designate 126.96.36.199 as permitted sender) client-ip=188.8.131.52; Authentication-Results: mx.google.com; spf=fail (google.com: domain of [email protected] does not designate 184.108.40.206 as permitted sender) [email protected]
In obvious cases you can already detect Phishing before checking the headers. It’s a good indication, when the contact address differs from the sending address…
…or when the links lead to a different target domain than they pretend to. You can check the target by hovering the links with your mouse cursor:
Btw: While I would encourage everybody to click on unsubscribe links instead of reporting spam in most cases, I wouldn’t recommend that on obvious spam/phishing mails. You could infect yourself or at least indicate to the spammer, that there’s a valid recipient behind the address. This increases value of your address in the eye of the spammer and this leads to even more spam)
I don’t need to mention in detail, that spelling mistakes or e-mails in a different language are suspicious as well. Bottom line is: Mail headers tell the truth – analyze them! And: Whenever you’re not sure, be careful!
Hope this helps a bit. Contact me if you have additional questions or specific cases and I’m happy to check them for you! Stay tuned…
9 replies on “How to recognize Spam & Phishing?”
Amazing blog guys. Believe you me postmasters out here want to hear more from you.. Like your theme too.. Keep it going guys, I am following closely
“You should do at least SPF and DKIM. DMARC doesn’t provide additional security and is more relevant for bigger companies working in security-critical industries like finance.”
DMARC is the only thing providing any security/enforcement, without that SPF & DKIM is useless in fighting phishing
can you explain your standpoint, please? Why is SPF & DKIM without DMARC useless in your eyes?
Because they are in general not enforced by mailbox providers.
Very few would reject an email based on SPF alone
The DKIM policies are sort of broken by design (default=unknown)
DMARC patches this up and makes email authentication useful.
OK, got you. So you’re saying, that DMARC is the piece saying explicitly to ISPs, that they should reject/quarantine/ignore messages with failing DKIM/SPF. Good point and interesting to hear that from a postmasters perspective. My experience is, that postmasters are handling this quite different. There’s indeed a lot of them not rejecting alone because of failing SPF or missing DKIM, but there’s also others checking for SPF and DKIM (but not for DMARC) and react on the tests (or at least take it into consideration for the spam decision).
I agree, the cleanest way is to implement DMARC and be on the safe side. My point in the article was just, that DMARC is not bringing a new authentication technology with it. It’s using SPF & DKIM, adds policy and requests reports, that’s all. Just one line in DNS, no additional key or complicated implementation needed.
Thanks for your feedback, much appreciated!
True, there are some providers still not supporting inbound DMARC checks, Apples email being one of them, but with Google/Yahoo/Microsoft/AOL on board a LOT of mailboxes are covered by the protection DMARC gives.
Latest numbers I’ve heard is that around 80% of mailboxes used in the US are protected by inbound DMARC
Another good reason for everyone to deploy DMARC is that Google asks for it 🙂
Nice one Henrik. Yes I have seen quite some improvement with dmarc implementations.. on delivery.. For reports.. Although I still think ISPs arent as strict on it as of yet..
Yeah, some ISP’s are a bit slow at adopting, others have had inbound DMARC protection for years.
I just tried sending a spoofed @paypal.com email to my email account at the largest ISP in Denmark.
This is what showed up in my mailserver log:
Aug 28 02:22:41 ocean postfix/smtp: 2EB641202C5: to=, relay=fpo9.mail.dk[220.127.116.11]:25, delay=1.6, delays=0.04/0.02/0.97/0.54, dsn=5.7.1, status=bounced (host fpo9.mail.dk[18.104.22.168] said: 550 5.7.1 msg rejected per DMARC policy for paypal.com, http://tele.dk/34711 (in reply to end of DATA command))