" email security Archives - LuxSci

Posts Tagged ‘email security’

The Case For Email Security

Friday, March 21st, 2025

We all know that regular email is insecure; however, it may surprise you to learn just how insecure it really is. For example, did you know that messages you deleted years ago may be on servers halfway around the world? Or that your messages can sometimes be read and modified in transit, even before they reach their destination? Did you know that forging email is very, very easy? Can you trust what you read in an email? Email was not designed with security in mind, and as a result, many different solutions have evolved to plug the multitude of resulting issues.

This article will explain how email works, what the real email security issues are, what mitigations to these are generally in use, and what else you can do to protect your email. This is especially important in healthcare marketing where you need to have HIPAA compliant email.

Case for Email Security

Information security and integrity are essential as we use email to send confidential and sensitive information over this medium every day. While reading this article, imagine how these security problems could affect your business, your personal life, and your identity if they have not already.

Read the rest of this post »

What exactly does HIPAA say about Email Security?

Wednesday, February 26th, 2025

Performing daily business transactions and communications through electronic technologies is accepted, reliable, and necessary across the nation’s healthcare providers, payers and suppliers. As a result, email has become a standard in the healthcare industry as a way to conduct business activities that commonly include:

  • Interacting with patients
  • Real time authorizations for medical services
  • Transcribing, accessing and storing health records
  • Appointment scheduling
  • Referring patients
  • Explanation of benefits
  • Marketing offers
  • Submitting claims to health plan payers for payment of the services provided

Collaborative efforts amongst healthcare providers have improved the delivery of quality care to patients in addition to the recognized increase in administrative efficiency through effective use of email and other types of digital communication. Patients are becoming more and more comfortable with emailing their physician’s office to schedule an appointment, discuss laboratory results, or request refills on medication. Medicare and some other insurance payers also recognize and pay for virtual care where the health provider and patient interact over video (telemedicine).

Using digital communications, undoubtedly, poses concerns about the privacy and security of an individual’s information. In healthcare, the confidentiality of a patient’s information has been sacred since the days of the Hippocratic Oath (Hippocrates – the Father of Medicine, 400 B.C.). Today, merely taking an oath to respect one’s privacy has been overshadowed by regulations that govern how certain healthcare establishments must handle an individual’s health information. So, if a healthcare organization employs email as a means of communicating medical and/or mental health data to appropriate parties, including patients and customers, they must also ensure that information is well safeguarded.

This article addresses the specific issues that healthcare provider, payers and suppliers must address in order to be in compliance with HIPAA and HITECH certified. It will also lay out how LuxSci enables healthcare organizations to meet these requirements though HIPAA compliant email outsourcing.

Overview of HIPAA

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) implemented new rules for the healthcare world. Mandating compliance with its Privacy and Security Rules, the federal government is committed to enforcing patients’ rights. Industry professionals – financial, administrative and clinical – are no strangers to the regulatory compliance culture. HIPAA laws apply to a covered entity; i.e. healthcare providers, suppliers, clearinghouses and health plan payers that meet certain conditions. In essence, most providers are covered entities if they employ digital communications, meaning they function by storing and exchanging data via computers through intranets, Internet, dial up modems, DSL lines, T-1, etc. Additionally, HITECH extends the requirements of HIPAA to any business associate of a covered entity and to all business associates of  business associates (all the way down the line) who may come into contact with Protected Health Information originating from a covered entity.

HIPAA email security applies specifically to protected health information, not just personal information. Protected Health Information (PHI), as defined in HIPAA language, is health information of an identifiable individual that is transmitted by electronic media; maintained in any electronic medium; or transmitted or maintained in any other form or medium. For example, all administrative, financial, and clinical information on a patient is considered PHI and must abide by the following standards:

  • Privacy Standards: The HIPAA Privacy Rule sets standards for protecting the rights of individuals (patients). Covered entities must follow the laws that grant every individual the right to the privacy and confidentiality of their health information. Protected Health Information is subject to an individual’s rights on how such information is used or disclosed.
    Privacy Standard Key Point: Controlling the use and disclosure of oral, written and electronic protected health information (any form).
  • Security Standards: Taking the Privacy Rule a step further, HIPAA implemented the Security Rule to cover electronic PHI (ePHI). To this end, more secure and reliable information systems help protect health data from being “lost” or accessed by unauthorized users.
    Security Standard Key Point: Controlling the access to electronic forms of protected health information (not specific to oral or written).

The Privacy and Security Rules focus on information safeguards and require covered entities and their business associates to implement the necessary and appropriate means to secure and protect health data. Specifically, the regulations call for organizational and administrative requirements along with technical and physical safeguards.

Starting on February, 2010, the HIPAA rules were enhanced by the American Recovery and Reinvestment Act.  The HITECH section of this act implements significant penalties for breaches of HIPAA and requires that the business partners of organizations covered by HIPAA must themselves obey the HIPAA Privacy and Security Rules, and face liability if there are any unauthorized disclosures.  For more information on what HITECH has done to HIPAA, see: HIPAA 2010: HITECH Impact on Email and Web Outsourcing.  Starting in September 2013, the Omnibus rule goes into effect, further expanding the scope of coverage and drastically strengthening the penalties and enforcement of HIPAA.   For more information on Omnibus, see: How the HIPAA Omnibus Rule Affects Email, Web, FAX, and Skype.

Provisions of the HIPAA Email Security Rule

The HIPAA language uses the terms required and addressable. Required means that complying with the given standard is mandatory and, therefore, must be complied with.  Addressable means that the given standards must be implemented by the organization unless assessments and in depth risk analysis conclude that implementation is not reasonable and appropriate specific to a given business setting.  Important Note: Addressable does not mean optional.

With regard to addressable, an organization should read and decipher each Security standard separately and deal with each piece independently in order to determine an approach that meets the needs of the organization.

The General Rules of the Security Standards reflect a “technology-neutral” approach. This means that there are no specific technological systems that must be employed and no specific recommendations, just so long as the requirements for protecting the data are met.

Organizational requirements refer to specific functions a covered entity must perform, including the use of business associate contracts and the development, documentation and implementation of policies and procedures.

Administrative requirements guide personnel training and staff management in regard to PHI and require the organization to reasonably safeguard (administrative, technical and physical) information and electronic systems.

Physical safeguards are implemented to protect computer servers, systems and connections, including the individual workstations. This section covers security concerns related to physical access to buildings, access to workstations, data back up, storage and obsolete data destruction.

Technical safeguards affect PHI that is maintained or transmitted by any electronic media. This section addresses issues involving authentication of users, audit logs, checking data integrity, and ensuring data transmission security.

Risk Analysis

Risks are inherent to any business and, therefore, with regard to HIPAA, each organization must take into consideration the potential for violating an individual’s right to privacy of their health information. HIPAA allows for scalability and flexibility so that decisions can be made according to the organization’s approach in protecting data. Covered entities and their Business Associates must adopt certain measures to safeguard PHI from any “reasonably anticipated” hazards or threats. After a thorough yearly risk analysis, a yearly assessment of the organization’s current security measures should be performed. Additionally, a cost analysis will add another important component to the entire compliance picture. A plan to implement secure electronic communications starts with reviewing the Security Rule and relating its requirements to the available solution and your business needs.

HIPAA Administrative and Physical Safeguards

Below are the administrative and physical safeguards as outlined in the Federal Register. These requirements are items that must generally be addressed internally, even if you are outsourcing your email or other services.  We will discuss these safeguards in more detail below.

Standard: ADMINISTRATIVE SAFEGUARDS Sections Implementation Specification Required or Addressable
Security Management Process 164.308(a)(1) Risk Analysis R
Risk Management R
Sanction Policy R
Information System Activity Review R
Assigned Security Responsibility 164.308(a)(2) R
Workforce Security 164.308(a)(3) Authorization and/or Supervision A
Workforce Clearance Procedures R
Termination Procedures A
Information Access Management 164.308(a)(4) Isolating Health Care Clearinghouse Function R
Access Authorization A
Access Establishment and Modification A
Security Awareness and Training 164.310(a)(5) Security Reminders A
Protection from Malicious Software A
Log-in Monitoring A
Password Management A
Security Incident Procedures 164.308(a)(6) Response and Reporting R
Contingency Plan 164.308(a)(7) Data Backup Plan R
Disaster Recovery Plan R
Emergency Mode Operation Plan R
Testing and Revision Procedure A
Applications and Data Criticality Analysis A
Evaluation 164.308(a)(8) R
Business Associates Contracts and Other Arrangement. 164.308(b)(1) Written Contract or Other Arrangement R
Standard: PHYSICAL SAFEGUARDS Sections Implementation Specification Required or Addressable
Facility Access Controls 164.310(a)(1) Contingency Operations A
Facility Security Plan A
Access Control and Validation Procedures A
Maintenance Records A
Audit Controls 164.312(b) R
Integrity 164.312(c)(1) Mechanism to Authenticate EPHI A
Workstation Use 164.310(b) R
Workstation Security 164.310(c) R
Device and Media Controls 164.310(d) Disposal R
Media Re-use R
Accountability A
Data Backup and Storage A

Importance of Encryption for Email Communication

The security risks for email commonly include unauthorized interception of messages en route to recipient, messages being delivered to unauthorized recipients, and messages being accessed inappropriately when in storage. These risks in using the Internet are addressed in the Security Rule’s technical safeguards section, particularly:

  1. Person or Entity Authenticationrequired procedures must be implemented for identification verification of every person or system requesting access to PHI. This means the identity of the person seeking information must be confirmed within the information system being utilized.  It also means that shared logins are not permitted.
  2. Transmission Securityaddressable data integrity controls and encryption reasonable and appropriate safeguards.
  3. Business Associates – if you outsource your email services to another company and your email may contain ePHI in any form, then that company must be HIPAA compliant, sign a Business Associate Agreement with you, and actively safeguard your ePHI.  The restrictions on Business Associates are quite strict and have changed as of Feb, 2010 and again, becoming even more strict as of September, 2013.

Each healthcare organization using email services must determine, based on technologies used for electronic transmission of protected health information, how the Security standards are met.

Addressable specifications include automatic log off, encryption, and decryption. Covered entities must also assess organizational risks to determine if the implementation of transmission security which includes integrity controls to ensure electronically-transmitted PHI is not improperly modified without detection is applicable. E.g. it is applicable for any ePHI going over the public Internet; it may not be necessary for information flowing between servers in your own isolated office infrastructure.  Encryption of ePHI at rest (as it is stored on disk) is also addressable and not a requirement under HIPAA regulations; however, a heightened emphasis has been placed on encryption due to the risks and vulnerabilities of the Internet.

Ultimately, according to the Department of Health and Human Services, covered entities and their business associates can exercise one of the following options in regard to addressable specifications:

  • Implement the specified standard;
  • Develop and implement an effective security measure to accomplish the purpose of the stated standard; or
  • If the specification is deemed not reasonable and appropriate for the organization but the standard can still be met, then do not implement anything.

Reasonable and appropriate relate to each organization’s technical environment and the security measures already in place.

Questions to Consider When Choosing an Email Service Provider

When your organization is responsible for critical data such as protected health information, choosing an email provider is more than a matter of trust. Does the email service provider build on the administrative, physical and technical safeguards while delivering to its customers:

  • Signed Business Associate Agreement
  • Awareness of their responsibilities under HITECH and Omnibus
  • Solutions that meet or exceed HIPAA’s Security Standards
  • Willingness to work with you and advise you on your security and privacy choices
  • Protect data integrity
  • Flexible, scalable services – no account is too small
  • Administrative access to assign or change a user’s password
  • Controls to validate a user’s access
  • Audit controls to track user access and file access
  • Allow access to users based on role or function
  • Automatic log off after specified time of inactivity
  • Data transmission security
  • Unlimited document or email transfer
  • Ability for encryption
  • Emergency access for data recovery
  • Minimal server downtime
  • Secure data back up and storage
  • Secure data disposal
  • User friendly, web-based access without the necessity of third party software
  • Privacy in not selling or sharing its client contact information

A Scalable, Flexible and HIPAA-Compliant Solution in Electronic Communications

Lux Scientiae (LuxSci for short) offers secure, premium email services including extensive security features, Spam and virus filtering, robustness, and superior customer service. The offerings are scalable to any size healthcare organization.

In addition to LuxSci itself protecting your ePHI by following the HIPAA Security and Privacy Rules as required by the HITECH amendment to HIPAA, LuxSci also provides a clean set of guidelines for using its services that enable your ePHI to be safeguarded; these guidelines are automatically enforced by the use of any “HIPAA Compliant” account.  If you follow these guidelines and sign LuxSci’s Business Associate Agreements, LuxSci will certify your account as HIPAA compliant and give you a HIPAA Compliance Seal.

Take a look at the table below to see examples of how LuxSci enables you to meet HIPAA’s requirements for protecting electronic communications in your organization.

Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Access Control 164.312(a)(1) Unique User Identification R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Assign a unique name and/or number for identifying and tracking user identity.”
Solution: Use of unique usernames and passwords for all distinct user accounts.  No shared logins; but sharing of things like email folders between users is permitted.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Emergency Access Procedure R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency”
Solution: PHI in email communications can be accessed from any location via the Internet. There are also mechanisms for authorized administrative access to account data.  Optional Email Archival and Disaster Recovery services provide enhanced access to email in case of emergency.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Automatic Logoff A
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.”
Solution: An organization can set screen savers on their desktops to log users out. Additionally, WebMail and other email access services (e.g. POP, IMAP, and Mobile) automatically log off all users after a predetermined amount of time; the WebMail session time is user- and account-configurable.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Encryption and Decryption A
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: Implement a mechanism to encrypt and decrypt electronic protected health information.
Solution: All usernames, passwords, and all other authentication data are be encrypted during transmission to and from LuxSci’s servers and our clients using SSL/TLS. Additionally, SecureLine permits end-to-end encrypted email communications with anyone on the Internet, SecureForm enables end-to-end encryption of submitted web site form data, and WebAides permit encryption of sensitive documents, passwords databases, and internal blogs.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Audit Controls 164.312(b) R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”
Solution: Detailed audit trails of logins to all POP, IMAP, SMTP, LDAP, SecureLine,and WebMail services are available to users and administrators. These include the dates, times, and the IP addresses from which the logins were made. Auditing of all sent and received email messages is also available. SecureLine also permits auditing of when messages have been read.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Integrity 164.312(c)(1) Mechanism to Authenticate ePHI A
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.”
“Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.”
Solution: To prevent unauthorized alteration or destruction of PHI, the use of SSL, TLS, PGP, and SecureLine will verify message and data integrity.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Person or Entity Authentication 164.312(d) R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.”
Solution: Username and Password are used for access control (Two-factor verification is also available); strict control is given over who can access user’s accounts. LuxSci’s privacy policy strictly forbids any access of email data without explicit permission of the user (unless there are extenuating circumstances). Also, use of SecureLine end-to-end encryption in email and document storage ensures that only the intended recipient(s) of messages or stored documents can ever access them.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Transmission Security 164.312(e)(1) Integrity Controls A
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”
“Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.”
Solution: SSL-based encryption during the transmission of data to/from our clients for WebMail, POP, IMAP, SMTP, and document storage services is provided. SMTP TLS-based encryption of inbound email at LuxSci ensures that all email sent internally at LuxSci meets “Transmission Security” guidelines and allows you to securely receive email from other companies whose servers also support TLS. LuxSci also provides SecureLine for true end-to-end encryption of messages to/from non-clients.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Encryption A
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.”
Solution: SSL encryption for WebMail, POP, IMAP and SMTP services is provided. Additionally, encrypted document and data storage is available and use of SecureLine for end-to-end security is enforced.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Device and Media Controls 164.310(d) Data Backup and Storage R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.”Solution: Daily on-site and weekly off-site backups ensure exact copies of all ePHI are included. Live data is stored on redundant RAID disk arrays for added protection. Furthermore, Premium Email Archival provides permanent, immutable storage on servers in multiple geographic locations.
Standard: TECHNICAL SAFEGUARDS Sections Implementation Specification R/A?
Data Disposal R
HIPAA COMPLIANT SOLUTION from LuxSci
The Rule States: “Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored.”Solution: Clients can delete their data whenever desired. Additional security comes in automatic expiration of data backups (cease to exist after 1 month). Alternate expiration plans are available for large clients.

Healthcare staff using LuxSci can send and receive email from anywhere in the world using existing or new email clients or web browsers.  A comprehensive solution for a complex law – managed by your account administrators in-house or remotely by our company. Risk assessments for potential HIPAA violations can be performed by administrators through the use of audit trails. Reliability and cost effective solutions are the backbone of LuxSci – even for extremely large client organizations. And, count on the physical security of our servers.

Chart of LuxSci Services and the HIPAA Rules they Satisfy

If you are interested in specific services at LuxSci and would like to know exactly which of the HIPAA rules each service meets, the following charts will assist you. Please contact LuxSci for more information.

HIPAA Rule 1. View Email: Secure WebMail, POP, IMAP, or Mobile Sync 2. Send Email: Secure WebMail, SMTP, or Mobile Sync 3. Encryption with SecureLine combined with 1 and 2 4. Secure Collaboration (WebAides)
Access Control – Unique User Identification
Access Control – Emergency Access (a) (a)
Access Control – Automatic Logoff
Audit Controls
Integrity (b) (b)
Person or Entity Authentication (b) (b)
Transmission Security > Integrity Controls (c) (c)
Transmission Security > Encryption (c) (c)
Device and Media Controls > Data Backups
Device and Media Controls > Data Disposal

(a) Our secure document storage service and use of SecureLine for communications may assume that the recipients have special passwords for their “Secure data access certificates” (PGP or S/MIME). These passwords are may be stored in a “Password Escrow” (a special secure password database) if the users so choose. In these cases, passwords to security keys can be retrieved in case of emergency or in case of loss.

(b) Our secure document storage service and use of SecureLine for communications encrypts data so that only the intended recipient(s) can ever view the data. The encryption process also allows the recipient(s) to verify that the data was not altered since it was sent or stored using digital signatures.

(c) SSL/TLS solutions encrypt the message during transport to and from LuxSci’s servers and your personal computer. Email sent from LuxSci to external addresses is secured with the use of SecureLine (Solution #3).

Solutions #3 provides complete transport layer and end-to-end email security compatible with any email user anywhere, no matter what software s/he may have.

References

Health Insurance Reform: Security Standards – Federal Register, Vol. 68, No. 34, 45 CFR Parts 160, 162, 164.

Centers for Medicare and Medicaid HIPAA Security Series

How Can I Prove an Email was Sent to Me?

Tuesday, January 16th, 2024

Almost everyone has been in this situation: someone claims to have sent you an email message, but you look in your inbox and don’t see it. As far as you know, you never got it. How can you prove an email was sent?

searching for an email

How to Prove That an Email was Sent

So, where do you start? As the purported recipient of an email message, the easiest way to prove that a message was sent to you is to have a copy of that message. It could be:

  1. In your inbox or another email folder
  2. A copy in your permanent email archives

 Sometimes, missing emails are caused by simple user errors. The obvious place to start the search is in your inbox and email folders. It’s also a good idea to check your email filtering and archival services. It’s possible that your email filtering system accidentally flagged the message as spam or sent it to quarantine. If it’s not there, check your email archival system. That should capture a copy of all sent and received messages. 

Hopefully, that will solve the issue. If it doesn’t, it’s worth stepping back to understand where the email could have gone and where you should turn next to solve the problem.

What happened to the email?

In reality, there are only a few things that could have happened:

  1. The recipient never sent the message.
  2. The recipient did send the message, but it did not reach you.
  3. The message did make it to you, but it was accidentally or inadvertently deleted (or overlooked).

Let’s begin with what you can check and investigate. Start your search soon. The more time that elapses, the less evidence you may have, as logs and backups get deleted over time.

Did the recipient actually send the message?

First, you should know that the sender could have put tracking on the message so that they were informed if you opened or read it (even if you are unaware of the tracking). In such cases, the sender can disprove false claims of “I didn’t get it!” If you are concerned about an email being ignored, use read recipients or tracking pixels to confirm email delivery.  

If you never saw the message, do what we discussed above and start searching your email folders for it. It could have been accidentally moved to the wrong folder or sent to the Trash folder. If you have a folder that keeps copies of all inbound emails (like LuxSci’s “BACKUP” folder), check there too. Check your spam folder and spam-filtering system. Your spam-filtering system may also have logs that you can search for evidence of this message passing through it. Finally, check any custom email filters you may have set up with your email service provider or in your email programs. If you have filters that auto-delete or auto-reject some messages, see if that may have happened to the message in question.

The searches above are straightforward; you can do many of them yourself. Often, they will yield evidence of the missing message or explain why you might not have received it.

Maybe the email was sent but didn’t make it to you?

Email messages leave a trail as they travel from the sender to the recipient. This trail is visible in the “Received” email headers of the message (if you have it) and in the server logs at the sender’s email provider and your email provider. If you know some aspects of the message in question (i.e., the subject, sender, recipient, and date/time sent), you can ask your email service provider to search their logs to see if there is any evidence of such a message arriving in their systems. This will tell you if such a message reached your email provider. However, email providers can typically only search the most recent one to two weeks of logs. So, if the message in question was from a while ago, your email service provider may be unable to help you (or may charge you a lot of money to manually extract and search archived log files if they have them). 

If your email provider has no record of the message or cannot search their logs, you (or the sender) can ask the same question of the sender’s email provider. If they can provide records of such an email being sent through their system, that will prove the email was sent.

The log file analysis provided by the email providers could also explain why you didn’t get the message. Your email address might have been spelled wrong, there could have been a server glitch or issue, etc. However, if the message was sent long ago, the chance of learning anything useful from the email provider is small. Also, if you use a commodity email provider such as AOL, Yahoo, Outlook, Gmail, etc., you may find it impossible to contact a technical support person and have them perform an accurate and helpful log search. Premium providers, like LuxSci, are more likely to support your requests. 

The last thing you can do is have the sender review their sent email folders for a copy of that message. If they have it, that can indicate that they sent it and can reveal why you didn’t get it (i.e., wrong email address, content that would have triggered your filters, etc.). However, be wary. It is easy to forge a message in a sent email folder, so it should not be considered definitive proof that the message was sent. And, even so, just because the message was sent, it does not prove it ever made it to your email provider or inbox.

The recipient never actually sent the email message

If the sending event was recent, then the data from your email service provider can prove that the message did not reach you, but that doesn’t prove that it was not sent. The sender may claim that they do not have a record of sent messages and that their email provider will not do log searching, and that may also be true. At this point, you are stuck without a resolution. 

While email is a reliable delivery system, there are many ways for messages not to make it to the intended recipient. Whether it was not sent or was sent and never arrived, the result is the same- no message for you. As a result, it’s best not to send legal notices or other important documents only by email. Using read receipts and other technologies when sending important messages can help increase confidence that an email was sent and received. Still, there is no foolproof way to guarantee email delivery.

How Do I Prove the Email Sender’s Identity?

A separate but related question is, how can I be sure the sender is who they say they are? Social engineering is rising, and cybercriminals can use technology to impersonate individuals and companies. If you are questioning whether the sender actually sent the message to your inbox (or if it is from a spammer or cybercriminal), it is necessary to perform a forensic analysis of the email headers (particularly the Received lines, DKIM signatures, etc.) and possibly get the sender’s email provider involved to corroborate the evidence. To learn more about how to conduct this analysis, please read: How Spammers and Hackers Can Send Forged Email.

Is the Email Encrypted? How to Tell if an Email is Transmitted Using TLS

Tuesday, January 9th, 2024

SMTP TLS encryption is popular because it provides adequate data protection without creating a complicated user experience for email recipients. Sometimes, though, the experience is too seamless, and recipients may wonder if the message was protected at all.

Luckily, there is a way to tell if an email was encrypted using TLS. To see if a message was sent securely, we can look at the raw headers of the email. However, it requires some knowledge and experience to understand the text. It is actually easier to tell if a recipient’s server supports TLS than to tell if a particular message was securely transmitted.

To analyze a message for transmission security, we will look at an example email message sent from Hotmail to LuxSci. We will explain what to look for when decoding the message headers and how to tell if the email was transmitted using TLS encryption.

encrypted email transmission

Read the rest of this post »

Preventing Email Forgery Part Three: DMARC

Tuesday, December 19th, 2023

In our previous two posts in this series, we examined how SPF and DKIM can help limit forged email messages by looking at the IP address and validating if the message was sent from an approved source based on digitally signed messages. We found that while SPF and DKIM can effectively prevent email fraud and forgery, weak implementations can make them vulnerable to attackers.

That’s where DMARC comes in. When properly implemented, DMARC provides instructions for what email filters should do with messages that fail SPF or DMARC. 

implementing DMARC in DNS

DMARC: A Simple Explanation

When using SPF and DKIM, email filters check if messages pass or fail SPF and DKIM. They use the DNS-published strictness settings to help them determine what to do next. How a particular filter is implemented determines what happens, leading to varied and inconsistent results.

So, what does DMARC do?

A DMARC policy allows a sender to indicate that both SPF and DKIM protect their emails and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages. DMARC also provides a way for the email receiver to report to the sender about messages that pass or fail DMARC evaluation.

In practical terms, with a DMARC policy published in DNS:

  1. The message must pass either SPF or DKIM but does not need to pass both.
  2. This resolves the deficiencies of SPF (forwarding) and DKIM (inadvertent message modification) by allowing compensation via the other mechanism.
  3. Sender policies can specify what to do with messages not passing SPF and DKIM. There are three options: do nothing, quarantine them, or reject them. There is no longer any implementation-specific ambiguity on what filters should do and when.

Setting up DMARC

The domain owner must properly set up the DNS records to use DMARC (as with all anti-fraud solutions for email). If you cannot access the domain settings, you will be unable to update your DNS settings and will not be able to use DMARC.

DMARC is set up by adding special entries to the published DNS settings for the domain. You can use a tool, such as this DMARC Record Assistant, to create the DMARC DNS record for your domain.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the utility of DMARC and its limitations.

The Benefits of DMARC

Once DMARC is set up, it helps reduce fraudulent emails from a domain. Simple forged spam and basic phishing attacks are curtailed more effectively with DMARC than with SPF and DKIM alone. Using DMARC combines them into a more comprehensive check with a consistent, well-defined failure state (e.g., reject or quarantine).

DMARC shines when implemented by domain owners using weak SPF and DKIM records. It allows email servers to accept that one of these validation schemes may fail while still requiring that the other one passes for the message to be considered legitimate. This is excellent progress.

DMARC is recommended for every domain owner and email filtering system. However, you must have control over all of the sources of messages from your domain name.

An interesting side effect is that, in some aspects, DMARC can make a domain more susceptible to determined forged emails!

The Limitations of DMARC

This is counterintuitive. Combining DKIM and SPF into a unified, complementary policy set that allows each to compensate for the other’s weakness is a fantastic idea and does a great job. However, a side effect of this technique in determining fraud is that it requires only one DKIM or SPF record to pass, NOT BOTH. In fact, there is no way to use DMARC to require that both must pass.

How Can Attackers Bypass DMARC?

An attacker only needs to find a way to pass one validation check to bypass DMARC. Note that this is only worse than separate use of SPF and DKIM if your SPF and DKIM rules are both strict (if it doesn’t pass — “drop it”). In most other cases, it’s the same or better than using both technologies separately.

Looking at our previous analyses of SPF and DKIM, an attacker could generate a forged email that passes DMARC if:

  1. They can send from an IP address allowed under the forged sender domain’s SPF policy. This can be done using the same email provider as the sender.
  2. They can send you a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from those same servers as the legitimate account and have their messages adequately signed.
  3. The attacker can compromise any sender’s workstations, email servers, or vendor’s email servers.

So, it requires a determined attacker with some knowledge of the sender’s infrastructure and some ingenuity to get past DMARC.

In addition, there is another way they can easily get past DMARC:

  1. If the sender’s domain has DMARC, SPF, and DKIM DNS records, if the recipient’s spam filters do not pay attention to DMARC (or the others), then these settings will be all for naught, and the forged message will still appear legitimate.

A determined attacker will gain knowledge both of the anti-fraud settings of the sender’s domain and of the capabilities of the recipient’s systems. The weaker the filters, the easier the attacker’s job can be.

What Else Can We Do to Prevent Email Forgery and Fraud?

Technologies are getting better and better at preventing email fraud, but none of them are foolproof. SPF and DKIM are implemented inconsistently, and DMARC is not well-supported across email filters. DMARC records are also not published for a majority of domains. Many that publish them have “no nothing” records designed to test the waters and gain telemetry on what messages they sent would fail DMARC.

Beyond using these technologies and being vigilant, some additional techniques can be used to lock down the identities of message senders. In the last article in this series, we shall see what some of these are.

Read next: Stopping Forged Email 4: Your Last Resorts