" dkim Archives - LuxSci

Posts Tagged ‘dkim’

High Volume Bulk Email: Key Ingredients for Good Deliverability

Tuesday, August 3rd, 2021

How do you ensure your bulk emails have good deliverability?

Deliverability is key to anyone sending bulk emails like newsletters, announcements, or triggered notifications. As a provider of secure bulk email services, we constantly advise customers on how they can avoid having legitimate messages marked as spam and ensure that they are not blacklisted. In this article, we consolidate our advice for everyone’s benefit. Some tactics for good bulk email deliverability include: ensuring you have a good mailing list, maintaining your mailing list, email message content, and reputation management techniques like SPF, DKIM, and IP anonymization.

bulk email deliverability

Read the rest of this post »

Zero Trust Email

Tuesday, July 20th, 2021

Our third article on Zero Trust Architecture covers zero trust email and the systems it requires. In May, the Biden Administration announced a new approach to cybersecurity that included a push toward Zero Trust Architecture. We have already covered Zero Trust Architecture as a whole, and also talked about how dedicated servers are important parts of the zero trust model. Now, it’s time to talk about zero trust email.

zero trust email

Zero Trust Email and Encryption

As we discussed in our previous articles, Zero Trust Architecture begins with the presumption that an organization’s network may not be secure. Because attackers may already be inside the network, NIST stipulates that:

“…communication should be done in the most secure manner available… This entails actions such as authenticating all connections and encrypting all traffic.”

This means that emails always need encryption. While many organizations recognize external threats and encrypt their sensitive external communications, it’s still common for workplaces to use unencrypted communication methods within the company network. This is generally done under the outdated assumption that the internal network is secure.

Zero Trust Architecture understands that any attacker within the network could easily read these communications. This is why zero trust email needs to be encrypted, even when it’s within an organization’s private network. One step in this direction is to force TLS for email encryption for all entities.

The zero trust model also requires encryption at rest, so emails also need to be protected in storage, not just in transmission.

Authentication and Zero Trust Email

NIST’s publication on Zero Trust Architecture also stipulates that:

“Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task.”

When it comes to zero trust email, this means that sensitive messages require authentication and authorization to be read. TLS encryption alone is not sufficient, because it doesn’t have the full capability for this type of verification. While it does allow authentication and authorization on the recipient’s email account, it cannot do so on the raw message data.

LuxSci supports:

  • Sender Policy Framework (SPF) – This is a system for email authentication that can detect forged sender addresses. Due to its limitations, it is best to complement it with other email authentication measures.
  • DomainKeys Identified Mail (DKIM) – This authentication method can detect email spam and phishing by looking for forged sender addresses.
  • Domain-based Message Authentication Reporting and Conformance (DMARC) – This email authentication protocol complements SPF, allowing it to detect email spoofing. It helps to protect organizations from phishing, business email compromise attacks, and other threats that are initiated via email.

Each of these email authentication measures are useful for verifying sender identities. LuxSci also offers premium email filtering, and together these techniques limit the trust that is applied to inbound messages.

Together, these techniques identify legitimate email messages while filtering out those that are unwanted or malicious. While it isn’t directly stated in the NIST guidelines, SPF, DKIM and DMARC can all be integral parts of the zero trust framework.

Access Control and Zero Trust Email

In addition to measures for encrypting messages and verifying inbound emails, zero trust email requires granular access controls to keep out intruders. LuxSci’s Secure Email Services include a wide range of access controls that limit unauthorized access while still making the necessary resources available. These include:

  • Two-factor authentication
  • Application-specific passwords
  • Time-based logins
  • IP-based access controls
  • APIs that can be restricted to the minimum needed functionality

These configuration options help reduce the likelihood that a malicious actor can access your systems. They also limit the sensitive email data that an attacker may have access to if they do manage to compromise an organization’s network.

LuxSci’s Zero Trust Email

As a specialist provider in secure and compliant services, LuxSci’s offerings are well-positioned as zero trust email solutions. Our Secure Email aligns with Zero Trust Architecture for every industry vertical, not just HIPAA. Contact our team to find out how LuxSci can help secure your organization with a zero trust approach.

API Enhancements for DKIM Automation

Wednesday, December 2nd, 2020

DKIM, Domain Keys identified Mail, is a critical component to ensuring good INBOX delivery of email messages for day-to-day email, email marketing, and transactional email.  DKIM digitally signs outbound email so that the message recipients can verify that the messages originated from email servers authorized to send email from the sender.  I.e., it helps recipients identify and discard forged and fraudulent email messages while keeping legitimate ones.

API Enhancements for DKIM

In order to use DKIM with LuxSci, customers need to:

  1. Have LuxSci generate keys for each sending domain
  2. Update the DNS settings for each domain to publish the DKIM public key.

See LuxSci’s Help for our general DKIM setup instructions for more details.  These steps are pretty quick and easy, unless you have a large number of domains that you are sending email from.

To help such customers automate their workflow and manage their domains, LuxSci’s API has been augmented to enable management of DKIM keys for LuxSci customers.  The API now permits:

  1. Creation of new DKIM keys for new domains.
  2. Downloading the DKIM information needed for the DNS configuration.
  3. Deletion of DKIM keys for domains no longer in use.

Together with LuxSci’s other API endpoints, LuxSci customers can automate the addition and deletion of domains, email aliases, users, and now DKIM settings.  LuxSci is committed to continually expanding its API capabilities to enable and support automated workflows and processes.

Save Yourself From “Yourself”: Stop Spam From Your Own Address

Friday, September 22nd, 2017

I just got junk email … from me!

It is surprisingly common for users to receive Spam email messages that appear to come from their own address (i.e. “joe@domain.com” gets a Spam email addressed so it appears to be from “joe@domain.com”).  We discussed this issue tangentially in a previous posting: Bounce Back & BackScatter Spam – “Who Stole My Email Address”?  However, many users wonder how this is even possible, while others are concerned if their Spam filters are not catching these messages.

How can Spammers use your email address to send Spam?

The way that email works at a fundamental level, there is very little validation performed on the apparent identity of the “Sender” of an email.  Just as you could mail a letter at the post office and write any return address on it, a Spammer can compose and send an email address with any “From” email address and name.  This is in fact extremely easy to do, and Spammers use this facility with almost every message that they send.

Read the rest of this post »

ARC and SMTP MTA-STS: The State of Domain-based Email Authentication – Part 3

Tuesday, September 19th, 2017

We’ll close (for now) our three part series on the state of domain-based authentication for emails by completing the story on technologies being deployed or defined to improve the security of the email ecosystem. In Part 1, we wrote about using Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to authenticate the sending mail server. Part 2 described how Domain-based Message Authentication, Reporting and Conformance (DMARC) is used to provide clear guidelines for the treatment of mail that fail SPF and/or DKIM authentication.

In this post, we’ll touch on two topics that are mature works in progress in the IETF, the technical standardization organization that has brought us so much of the protocols that govern the internet. The first technology is Authenticated Received Chain (ARC), defined to handle the shortcomings of SPF and DKIM when used with mail forwarders or mailing lists. The second technology is about correcting the lack of security between Message Transfer Agents (MTA), and a solution to enforce strict transport layer security for SMTP message transfer between MTAs.

It’s worth reiterating again that all these technologies are building blocks, and only when used and deployed collectively by the entire ecosystem can we hope to create the barriers needed to thwart fake emails and mail surveillance by malicious actors.

Read the rest of this post »

LUXSCI