29 March 2017
Blogs by author: Peter Negus , Solutions Architect, BT.
Discover how Domain-based Message Authentication, Reporting and Conformance (DMARC) improves security and keeps spoofed email addresses out of your inbox.
Spoofing emails and cyber security.
It’s 6pm on Friday and you need to go home. An email from what appears to be firstname.lastname@example.org arrives in your inbox. It’s asking you to update your details, so you click on the link… and suddenly you’re infected with hideous malware, or worse — a new ransomware attack.
How can you stop these spoofed emails? Well, if you’re the owner of a regularly spoofed email domain, or you’re getting hit with lots of spoofed email, DMARC can help. It tells your email recipients how to make sure that an email is actually from you — and what to do when an email fails the validation test. If your email system understands the DMARC advertisements and applies them to the incoming mail feed, it can automatically reject the spoofer’s imitations.
Inside DMARC – SPF and DKIM.
DMARC combines two authentication methods — Security Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
SPF checks that the domain in the ‘SMTP: MAIL FROM’ field matches one of the published source IP addresses for that domain. So, for example, if I received a mail message from email@example.com, the SPF process looks up what IP addresses (220.127.116.11 or 18.104.22.168) are associated with that address from the Domain Name Service.
It then compares them with the actual source IP address that the email came from. If they don’t match, the message is rejected. If you want receivers to use SPF, you have to publish a DNS TXT (freeform) record to your DNS provider indicating how the address is authenticated and what to do with rejected email. Like most freeform text, it’s easy to mess up, so make sure that you test it properly before going live. There’s a more detailed description of the TXT record and common mistakes on the OpenSpf website.
DKIM signs outgoing email messages with a digital signature. The receiver verifies that the message is authentic and hasn’t been modified by using the sender’s public key. This public key is again published in DNS as a TXT record — requiring you to cut and paste a frighteningly long sequence of random digits.
Unlike traditional digital signatures, the DKIM is invisible to the user — it’s attached and removed by the email gateway or server itself. (There’s a great overview of the DMARC protocol at demarc.org if you want to know more.)
Implementing DMARC for outgoing mail.
This can be quite a complex business for a large organisation. You have to work out exactly where all your email servers are, their primary and backup IP addresses, and the mail domains in use. To make it easier, set DMARC up in ‘monitor only’ mode, where any invalid emails from your domain are reported back to you. Don’t forget to include any agencies that send emails on your behalf in your DMARC advertisements.
Analysing a heavily-spoofed domain like this can be very hard work, and you may want to use logging tools to help you. Bear in mind that DMARC notifications are in XML format rather than syslog, and will need a bit of pre-processing before you put them into any syslog processor.
You may also need to tidy up your existing email domains and readdress servers, again not a trivial process in a large organisation. On the positive side, you get to see all the phishing and spoofing emails targeted at your customers. There are quite a few specialist companies that work in this area who can also assist.
You also need to get the DNS TXT records published, and this may lead to further issues with your DNS system. You’ll find that our Diamond IP service is a great tool for rationalising your existing DNS and DHCP infrastructure.
Mail forwarders can be affected by DMARC friendly fire.
Despite all this, you may find that you still have a problem, even after implementing DMARC. It’s just one bit of a security jigsaw. Indeed, you may have a problem with friendly fire, where your DMARC tagged email is rejected for spurious reasons.
One known problem that you may come up against is where an email is forwarded via an alias service. For example, I might have a mailbox at firstname.lastname@example.org which forwards incoming emails to my real mailbox. On arrival, the DKIM is checked, and because alias.com is not in the DMARC records, it’s tagged as invalid.
Unfortunately, there’s little you can do with this sort of problem, other than encouraging the recipients to register their real email addresses or use a separate mailbox directly on the forwarding service.
But this shouldn’t put you off — because it’s still a valuable addition to your cyber security. If you’re interested in learning more, there’s plenty of information on the website I mentioned earlier. And to see how we can help, take a look at our security and risk management tools.