Phishing is a cybercrime in which a target or targets are contacted by email, telephone or text message by someone posing as a legitimate institution to lure individuals into providing sensitive and personal data such as banking, credit card details, and passwords, usually on fake websites.
The information is then used to access important accounts and can result in identity theft, fraud and financial loss.
The first phishing lawsuit was filed in 2004 against a Californian teenager who created the imitation of the website “America Online”. With this fake website, he was able to gain sensitive information from users and access their credit card details to withdraw money from their accounts. Other than email and website phishing, there’s also ‘vishing’ (voice phishing), ‘smishing’ (SMS Phishing) and several other phishing techniques cybercriminals are constantly coming up with.
Common Features of Phishing Emails
Too Good To Be True– Lucrative offers and eye-catching or attention-grabbing statements are designed to attract people’s attention immediately. For instance, many will claim that you have won an iPhone, a lottery, or some other lavish prize. Just don’t click on any suspicious emails. Remember that if it seems too good to be true, it usually is!
Sense of Urgency – A favorite tactic amongst cybercriminals is to ask you to act fast because the super deals are only for a limited time. Some of them will even tell you that you have only a few minutes to respond. When you come across these kinds of emails, it’s best to just ignore them. Sometimes, they will tell you that your account will be suspended unless you update your personal details immediately. Most reliable organizations give ample time before they terminate an account and they never ask patrons to update personal details over the Internet. When in doubt, visit the source directly rather than clicking a link in an email.
Hyperlinks – A link may not be all it appears to be. Hovering over a link shows you the actual URL where you will be directed upon clicking on it. It could be completely different or it could be a popular website with a misspelling, for instance, www.bankofarnerica.com – the ‘m’ is actually an ‘r’ and an ‘n’, so look carefully.
Attachments – If you see an attachment in an email you weren’t expecting or that doesn’t make sense, don’t open it! They often contain payloads like ransomware or other viruses. The only file type that is always safe to click on is a .txt file.
Unusual Sender– Whether it looks like it’s from someone you don’t know or someone you do know, if anything seems out of the ordinary, unexpected, out of character or just suspicious in general don’t click on it!
Here is a great KnowBe4 resource that outlines 22 social engineering red flags commonly seen in phishing emails. We recommend printing out this PDF to pass along to family, friends, and coworkers.
Prevent Phishing Attacks:
Though hackers are constantly coming up with new techniques, there are some things that you can do to protect yourself and your organization:
To protect against spam mails, spam filters can be used. Generally, the filters assess the origin of the message, the software used to send the message, and the appearance of the message to determine if it’s spam. Occasionally, spam filters may even block emails from legitimate sources, so it isn’t always 100% accurate.
The browser settings should be changed to prevent fraudulent websites from opening. Browsers keep a list of fake websites and when you try to access the website, the address is blocked or an alert message is shown. The settings of the browser should only allow reliable websites to open up.
Many websites require users to enter login information while the user image is displayed. This type of system may be open to security attacks. One way to ensure security is to change passwords on a regular basis, and never use the same password for multiple accounts. It’s also a good idea for websites to use a CAPTCHA system for added security.
Banks and financial organizations use monitoring systems to prevent phishing. Individuals can report phishing to industry groups where legal actions can be taken against these fraudulent websites. Organizations should provide security awareness training to employees to recognize the risks.
Changes in browsing habits are required to prevent phishing. If verification is required, always contact the company personally before entering any details online.
Generally, emails sent by cybercriminals are masked so they appear to be sent by a business whose services are used by the recipient. A bank will not ask for personal information via email or suspend your account if you do not update your personal details within a certain period of time. Most banks and financial institutions also usually provide an account number or other personal details within the email, which ensures it’s coming from a reliable source.
If you need help in protecting yourself from phishing ransomware or other cybercrime, get in touch.
DKIM stands for DomainKeys Identified Mail and is used for the authentication of an email that’s being sent. Like SPF, DKIM is an open standard for email authentication that is used for DMARC alignment. A DKIM record exists in the DNS, but it is a bit more complicated than SPF. DKIM’s advantage is that it can survive forwarding, which makes it superior to SPF and a foundation for securing your email.
Starting in 2004 from merging two similar efforts, “enhanced DomainKeys” from Yahoo and “Identified Internet Mail” from Cisco and has since been widely adopted for email authentication.
What is a DKIM Record?
A domain owner adds a DKIM record, which is a modified TXT record, to the DNS records on the sending domain. This TXT record will contain a public key that’s used by receiving mail servers to verify a message’s signature. The key is often provided to you by the organization that is sending your email, for example SendGrid, Postmark, or Google Apps.
What is a DKIM Signature?
DKIM gives emails a signature header that is added to the email and secured with encryption. Each DKIM signature contains all the information needed for an email server to verify that the signature is real, and it is encrypted by a pair of DKIM keys. The originating email server has what is called the “private DKIM key,” which can be verified by the receiving mail server or ISP with the other half of the keypair, called the “public DKIM key.”
These signatures travel with the emails and are verified along the way by the email servers that move the emails toward their final destination.
How does DKIM work?
When an inbound mail server receives a message, it will detect the DKIM signature and look up the sender’s public DKIM key in DNS. The variable or DKIM selector provided in the DKIM signature is used to determine where to look for this key. If the key is found, it can be used to decrypt the DKIM signature. This is then compared to the values retrieved from the received mail. If they match, the DKIM is valid.
Read about DKIM Selectors and how to discover which ones your domain may be currently using.
Why use DKIM for Email?
Implementing DKIM for email provides major benefits:
Protection of message integrity. The content of the email can be verified that it hasn’t been changed while being sent.
Increases domain reputation and email deliverability.
One of the foundational methods of email authentication for DMARC.
How do I know if DKIM is working?
Test your domain’s DKIM settings – Our DKIM Inspector is a free diagnostic tool that check if the public part of your DKIM signature—using the selector—has been implemented correctly in the DNS of your domain. Our free DKIM Validator can help you verify that your DKIM record is properly formatted.
What happens when DKIM fails?
When DKIM alignment fails—or when the d= value in the Header From does not match the d= value in the DKIM signature—it can negatively impact deliverability as mailbox providers may send the message to the spam folder or block it entirely.
It is important to examine all messages that have failed to identify the sources as valid or as malicious. If you recognize a source as legitimate, you can investigate and set up DKIM correctly. If a source is not recognized, make sure to research it because this could indicate an attempt to send malicious emails on behalf of your domain.
Why DKIM-Only Isn’t Safe Enough
DKIM on its own isn’t a reliable way of authenticating the identity of the email sender and does nothing to prevent the spoofing of the domain visible in the header of the email. DMARC solves the problem by guaranteeing that the domain the end user sees is the same as the domain that is validated by DKIM and SPF. Learn more about DMARC alignment.
Furthermore, the addition of DMARC provides email received instructions on what to do with emails which do not match these checks via DMARC policy enforcement.
Domain-based Message Authentication Reporting and Conformance (DMARC) is a free and open technical specification that is used to authenticate an email by aligning SPF and DKIM mechanisms. By having DMARC in place, business owners large and small can fight the massive cybersecurity problems caused by phishing and reputation damage caused by spoofing.
With DMARC you can tell the world how to handle the unauthorized use of your email domains by instituting a policy in your DMARC record. The three DMARC policies are:
Monitors your email traffic. No further actions are taken.
Sends unauthorized emails to the spam folder.
The final policy and the ultimate goal of implementing DMARC. This policy ensures that unauthorized email doesn’t get delivered at all.
How does DMARC work?
DMARC is based upon the results of SPF and/or DKIM, so at least one of those has to be in place for the email domain. To deploy DMARC, you need to publish a DMARC record in the DNS.
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy after checking SPF and DKIM status. DMARC authenticates if either SPF, DKIM, or both pass. This is referred to as DMARC alignment or identifier alignment. Based on identifier alignment, it is possible that SPF and DKIM pass, but DMARC fails.
A DMARC record also tells email servers to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
Because reports are written in XML, making sense of them can be tricky, and they can be numerous. dmarcian’s platform can receive these reports and provide visualization on how your email domains are being used, so you can take action and move your DMARC policy towards p=reject.
What is a DMARC Record?
As a mission-driven company, dmarcian is focused on spreading the adoption of DMARC. Because of this, we interface with a wide range of people with varying degrees of knowledge. We thought we’d take a step back and take a look at something fundamental: What is a DMARC record?
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy when it comes to checking to see if your SPF and/or DKIM has passed or failed.
A DMARC record also tells the servers that touch your email on its way to its final destination to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
More information on publishing DMARC records can be found here.
The DMARC Record; what does it look like?
“v=” indicates this is a DMARC record
“p=” indicates the DMARC policy
“rua=” indicates where data should be sent
RUA is reporting that provides an aggregate view of all of a domain’s traffic. The other option is RUF reports that are redacted forensic copies of the individual emails that are not 100% compliant with DMARC. While RUA reports show the traffic of the email, RUF reports contain snippets from the actual emails themselves. While RUA reporting is all that is needed for DMARC deployment, more advanced users may also add the RUF tag, which will send more sensitive information.
These reports are in Extensible Markup Language (XML), which isn’t easy to read:
There are tools that can translate these XML files into a human-friendly format. Services like Dmarcly, where the RUA reports can be pointed to, automatically process the reports and give you insight via a powerful dashboard to make identifying the valid uses of your email domain easier while disallowing abuse. A dmarcian account will store past reports so you can observe trends and be alerted when new threats arise.
Why Use DMARC for Email?
Email is involved in more than 90% of all network attacks and without DMARC, it can be hard to tell if an email is real or fake. DMARC allows domain owners to protect their domain(s) from unauthorized use by fighting phishing, spoofing, CEO fraud, and Business Email Compromise.
By always sending DMARC compliant email, the operator of an Internet domain can tell the world “everything I send is easy to identify using DMARC—feel free to drop fake email that pretends to be me.”
DMARC’s utility as an anti-spoofing technology stems from a significant innovation; instead of attempting to filter out malicious email, why not provide operators with a way to easily identify legitimate email? DMARC’s promise is to replace the fundamentally flawed “filter out bad” email security model with a “filter in good” model.
If you’re curious about the health of your domain or anyone’s, use this free Domain Checker for a quick check. It inspects DMARC, SPF and DKIM and tells you which actions you need to take to reach compliance.
Benefits of DMARC
If you use email, you’ll benefit by incorporating DMARC.
When strong security controls are deployed against fraudulent email, delivery is simplified, brand reliability increases and visibility is granted to domain owners on how their domains are being used around the Internet.
Security Disallow unauthorized use of your email domain to protect people from spam, fraud, and phishing.
Visibility Gain visibility into who and what across the Internet is sending email using your email domain.
Delivery Use the same modern plumbing that mega companies use to deliver email.
Identity Make your email easy to identify across the huge and growing footprint of DMARC-capable receivers.
If you are interested in a fully managed email security, domain alignment, Dmarc service
Sender Policy Framework (SPF) is used to authenticate the sender of an email. With an SPF record in place, Internet Service Providers can verify that a mail server is authorized to send email for a specific domain. An SPF record is a DNS TXT record containing a list of the IP addresses that are allowed to send email on behalf of your domain.
How does SPF work?
To take advantage of SPF, you publish an SPF record in the DNS. The record is a list of all the IP addresses that are allowed to send email on behalf of the domain.
The SPF mechanism uses the domain in the return-path address to identify the SPF record. When a sender tries to hand-off an email to an email “receiving” server for delivery, the server checks to see if the sender is on the domain’s list of allowed senders. If so, then a link has been established between the piece of email and the email domain. If not, then the server continues processing the email as usual without this link, as any number of things could be going on.
The email might be real, but the list of senders might not be accurate. Real email might have been forwarded which means the email could have come from anywhere and the list of allowed senders doesn’t help too much. Or, the email is fake and unwanted. Too many possible outcomes makes it difficult to attach meaning to the absence of the link that SPF can provide. DKIM fills the gap in the DMARC technical framework as an additional way to try and link a piece of email back to a domain.
Already have an SPF record? We have also developed a comprehensive guide to SPF record formatting to increase your understanding and help troubleshoot any SPF issues that our free SPF Surveyor may bring to your attention: SPF Record Syntax
SPF and DMARC for Email
By itself, SPF can associate a piece of email with a domain. With the DNS records in place, DMARC ties the results of SPF to the content of email, specifically to the domain found in the return path or From: header of an email. For SPF to work correctly in the context of DMARC, the return-path address has to be relevant to the domain of the From: header, which is the item that ties together DMARC alignment.
Why is SPF Important?
SPF has become exceedingly vital to help verify which sending infrastructure can relay email on behalf of your domain. Implementing SPF for email provides major benefits:
Increases domain reputation and email deliverability.
Fights domain impersonation and email spoofing to protect your brand reputation.
One of the foundational methods of email authentication for DMARC.
How do I check my SPF Record?
Check your domain’s SPF settings – dmarcian’s SPF Surveyor is an SPF diagnostic tool that presents a graphical view of SPF records. It allows you to quickly identify which servers are authorized to send on behalf of a domain.
Why SPF-Only Isn’t Safe Enough
Though SPF is a layer of proven email authentication that has been around since the late 1990s, it does have its challenges. Simply put, forwarding of email happens on the Internet and the SPF mechanism doesn’t survive the forwarding process. Forwarding typically happens when you send email to [email protected] and that person has set their email to be forwarded to another address, like [email protected]. In this example, your email appears to be coming out of infrastructure that appears to have nothing to do with you.
DKIM signing can survive forwarding. If your domain is covered with DKIM, dmarcian’s ability to detect forwarding increases. SPF does not work in the context of forwarding, as SPF is simply a list of servers that are authorized to send on behalf of your domain, and it isn’t possible for a domain owner to maintain a list of forwarders.
Companies often misunderstand how SPF works and instruct their customers to include the company’s own SPF record. However, this ends up doing nothing if the company uses its own domain in the bounce address. When an email receiver processes a piece of email, it will look at the company’s SPF record—not the SPF record of the customer.
Two unwanted things happen because of this misconception:
Unnecessary “includes” are added into their SPF records. This causes SPF records to bloat and introduces management challenges.
Confusion is introduced as people just want to get SPF into place to complete their DMARC deployment. The result is that SPF passes, but DMARC fails.
For SPF to work correctly in the context of DMARC, the bounce address has to be relevant to the domain of the From: header. Unfortunately, many companies that send email on behalf of others do not currently allow their customers to change the bounce address to the customer’s domain. This is slowly changing, but companies first have to understand the basics of how SPF works. We have resources available to help companies send DMARC compliant email on behalf of others.
Note: There is obsolete technology called SenderID that tried to perform SPF-like checks, except it used the From: header domain (among others) as the item to check. SenderID also attempted to reuse existing SPF records, causing even more confusion.
When it comes to website security, most people are quite oblivious to the vulnerabilities that exist and are exposed on their own site.
Securing your website is all about minimizing attack surface and adding more layers of security. One strong layer that you can (and should) add is proper HTTP security headers. When responding to requests, your web server should include a number of security headers that help stop unwanted activity like XSS, MITM, and click-jacking attacks. While sending security headers does not guarantee 100% defense against all such attacks, it does help modern browsers keep things secure. So in this tutorial, we walk through seven of the most important and effective HTTP security headers you should add to your website in order to your website to bolster the security.
Note that the solutions below only work on Apache and compatible servers that use .htaccess, such as Litespeed.
Here are 7 Important HTTP Security Headers for Your Website.
Note: You can verify your site’s security headers using a free online tool such as the one provided by SecurityHeaders.com.
The X-XSS-Protection security header enables the XSS filter provided by modern web browsers (IE8+, Chrome, Firefox, Safari, et al). Here is the recommended configuration for this header:
Header set X-XSS-Protection "1; mode=block"
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to block any requests containing malicious scripts. For more configuration options and further information about X-XSS-Protection, check out these resources:
The X-Frame-Options (XFO) security header helps modern web browsers protect your visitors against clickjacking and other threats. Here is the recommended configuration for this header:
Header set X-Frame-Options "SAMEORIGIN"
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to block any frames/content requested from external locations. So if your own site includes an iframe that loads a resources from the same domain, the content will load normally. But if any iframe is included that loads resources from any other domain, the content will be blocked. For more configuration options and further information about X-Frame-Options, check out these resources:
The X-Content-Type-Options security header enables supportive browsers to protect against MIME-type sniffing exploits. It does this by disabling the browser’s MIME sniffing feature, and forcing it to recognize the MIME type sent by the server. This header is very flexible and may be configured extensively, however the most common implementation looks like this:
Header set X-Content-Type-Options "nosniff"
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to use the MIME type declared by the origin server. There are a couple of precautions to keep in mind. First, as with any security header, it does not stop 100% of all attacks or threats; it does stop some of them, however, and thus provides another layer of protection for your site. Also note that this header currently is supported only in Chrome and later versions of Internet Explorer. Hopefully other browsers will add support in the future. For more configuration options and further information about X-Content-Type-Options, check out these resources:
The Strict-Transport-Security (HSTS) header instructs modern browsers to always connect via HTTPS (secure connection via SSL/TLS), and never connect via insecure HTTP (non-SSL) protocol. While there are variations to how this header is configured, the most common implementation looks like this:
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to always use HTTPS for connections. This helps stop man-in-the-middle (MITM) and other attacks targeting insecure HTTP connections. For more configuration options and further information about Strict-Transport-Security, check out these resources:
The Referrer-Policy security header instructs modern browsers how to handle or exclude the Referer header (yes the header normally is spelled incorrectly, missing an “r”). For those who may not be familiar, the Referer header contains information about where a request is coming from. So for example if you are at example.com and click a link from there to domain.tld, the Referer header would specify example.com as the “referring” URL.
With that in mind, the Referrer-Policy enables you to control whether or not the Referer header is included with the request. Here is an example showing how to add the Referrer-Policy header via Apache:
Header set Referrer-Policy "same-origin"
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to only set the referrer header for request from the current domain (same-origin). Keep in mind that this header is less about security and more about controlling referrer information, as is required by various rules and regulations (e.g., GDPR). For more configuration options and further information about Referrer-Policy, check out these resources:
The Feature-Policy header tells modern browsers which browser features are allowed. For example, if you want to ensure that only geolocation and vibrate features are allowed, you can configure the Feature-Policy header accordingly. It also enables you to control the origin for each specified feature. Here is an example showing how to add a Feature-Policy header via Apache:
Added to your site’s .htaccess file or server configuration file, this code instructs supportive browsers to enable only geo-location and vibrate features. Keep in mind that this header is less about security and more about ensuring a smooth experience for your users. For more configuration options and further information about Feature-Policy, check out these resources:
The Content-Security-Policy (CSP) header tells modern browsers which dynamic resources are allowed to load. This header is especially helpful at stopping XSS attacks and other malicious activity. This header provides extensive configuration options, which will need to be fine-tuned to match the specific resources required by your site. Otherwise if the header configuration does not match your site’s requirements, some resources may not load (or work) properly.
Because of this, there isn’t one most common example to look at. So instead here are a few different examples, each allowing different types of resources.
First example, here is a CSP directive that allows resources from a CDN, and disallows any framed content or media plugins. This example is from the Google docs page linked below.
# Content-Security-Policy - Example 1
Header set Content-Security-Policy "default-src https://cdn.example.com; child-src 'none'; object-src 'none'"
Second example, this CSP directive enables script resources loaded from a jQuery subdomain, and limits stylesheets and images to the current domain (self). This example is from the Mozilla docs page linked below.
# Content-Security-Policy - Example 2
Header set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com; style-src 'self'"
And for a third example, here is the directive I use on most of my WordPress-powered sites. Logically these sites tend to use the same types of resources, so I can keep things simple and use the following code on all sites:
Stare at that for a few moments and you should get the idea: the header is setting the allowed source(s) for fonts, images, scripts, and styles. For each of these, a secure HTTPS connection is required. The only exception is also to allow data URIs as a source for fonts and images.
So for any of these examples, when added to your site’s .htaccess file or server configuration file, the code tells supportive browsers which dynamic resources are allowed and/or not allowed. But seriously, if you’re thinking about adding the powerful Content-Security-Policy security header, take a few moments to read thru some of the documentation:
There are lots of useful tools out there to make CSP easier. Just enter your infos and copy/paste the results. If in doubt, use multiple tools and compare the results; the code should be the same. If not, don’t hesitate to reach out to the tool providers, who will be able to answer any questions, etc.
For the sake of easy copy/pasting, here is a code snippet that combines all of the above-described security headers.
Important: before adding this code to your site, make sure to read through each technique as explained in corresponding sections above. There may be important notes and information that you need to understand regarding each particular directive included in this code snippet.
# Security Headers
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
# Header set Content-Security-Policy ...
Header set Referrer-Policy "same-origin"
Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
As with each of the above techniques, this code may be added to your site via .htaccess or Apache config. Understand that this technique includes commonly used configurations for each of the included headers. You can (and should) go through each one to make sure that the configuration matches the requirements and goals of your site. Also remember to test thoroughly before going live.
Note: Notice the following line in the above “Security Headers” code snippet:
# Header set Content-Security-Policy ...
The pound sign or hash tag or whatever you want to call it means that the line is disabled and is ignored by the server. This means that the Content-Security-Policy directive is “commented out” and thus not active in this technique. Why? Because as explained previously, there is no recommended “one-size-fits-all” CSP example that works perfectly in all websites. Instead, you will need to replace the commented out line with your own properly configured CSP header, as explained above.
Once you are done, you can use these handy Geekflare Tools to test that your security headers are working properly.
Yes and No. Email is a highly valuable tool that has evolved to be more secure, but there are still ways to exploit email for nefarious purposes. Email users should be careful with how they use email and the emails they respond to. Let’s look at email security in more detail.
A Little History
Electronic mail originated on the early experimental Arpanet, the precursor to the Internet. At that point, all the interconnected servers were within high-security facilities. Since the security was on the outside, researchers did not consider protocol security; everything was sent in clear text – HTTP for browsing documents, FTP for sharing data files, and SMTP for electronic communications. When the Arpanet opened up to universities and then to businesses and private users, those same protocols were still transmitting data and passwords in clear text. Unfortunately, clear text communications are susceptible to man-in-the-middle attacks – corrupted computers or routers between the two computers in communication.
The early Internet was not secure, so new technologies were developed to improve security:
HTTPS to secure online transactions involving credit cards
SFTP to secure file transfers (now replace by HTTPS in many cases)
TLS to encrypt email communications between email servers
With the adoption of TLS, Transport Layer Security, email was secured from potential man-in-the-middle attacks. However, there are other ways to exploit email.
There were other technologies that attempted to “secure” email communications, all had various degrees of success, but none of them have really gone mainstream.
PGP, or Pretty Good Privacy, used a Public-Private encryption key system to encrypt and decrypt email. Email was completely secure in transit, and from administrators, but unfortunately, PGP was bulky to use. TLS solved the problem of securing communication between servers without the user needing to do anything.
“Secure” Email Servers are web servers where communication could be secured behind a password protected web login. It was not really email but a way to communicate in an email-like fashion. You often see these secure communications websites with Legal and Medical professions, but they suffer from bulky interfaces and the inconvenience of going somewhere other than your normal email applications to view the communication.
Sender Verification Services respond to an unsolicited email with an email demanding the sender verify their identity. The goal here is to reduce the potential for spam and phishing attempts by creating a hurdle for senders to jump. The inbox provider then only passes on “verified” email to the user. This technique essentially removes any automated email, including newsletters, as marketing teams are unable to monitor the verification email. The downside is that a legitimate sender may not register so you miss important email.
The Threat of Spam and Phishing
Email is the #1 preferred method for perpetrating online scams. The marginal cost of sending an email is negligible and the rewards for a successful scam can be thousands or millions of dollars. According to Cisco, approximately 84% of all email is spam, much of which is phishing scams and much also escaping spam filters. By that measure, email is not “secure”.
Improving email security is not a single technology or vendor but involves changing business processes, adopting new standards and continuously adapting to the ever-evolving landscape of email scams. Some recommendations:
Stop hosting your own email – Inbox providers like Google Workspace, Microsoft 365, Yahoo!, etc. have dedicated teams to managing and blocking spam and phishing. Most businesses would benefit by leveraging these external experts and outsourcing email inbox services.
Turn on 2-factor authentication – Securing email communication, both sending and receiving, means securing access to email accounts. 2-Factor Authentication helps make email more secure.
Invest in Spam and Phishing Awareness Training – Email scams exploit human weakness through social engineering to gain access to your email, bank accounts and secure data. Training your team to recognize these scams will improve your email security.
Leverage DMARC and supporting technologies – SPF, DKIM, DMARC and BIMI work hand-in-hand to 1) declare who can send email on behalf of a domain, 2) digitally sign email from that domain, 3) report compliance to the sending domain, and 4) apply a corporate logo to compliant email. When a domain leverages these technologies, it is secured against being used in spam and phishing attempts and gives the recipients peace-of-mind that the email is genuine.
To maintain the highest levels of email deliverability using DMARC, businesses like yours need a proven Email Delivery management system like MxToolbox Delivery Center. Delivery Center provides you with valuable insight into your email delivery posture and the ongoing maintenance necessary to maintain peak performance:
Manage SPF, DKIM, and DMARC (and BIMI) to improve compliance and reduce the threat of fraud and phishing using your domain.
Review daily volume and SPF, DKIM, and DMARC compliance rates to ensure the best email deliverability.
Implement Feedback Loops to gain unique information on how your recipients view your emails and when they mark you as spam.
Gradually move your DMARC policy to Reject to enable better inbox placement opportunities.
Manage the on-going requirements of maintaining high levels of email deliverability
On-Premise Email Security Best Practices
If your company strategy requires on-premise email management, then there are some best practices you can adopt:
Use Inbound Email filtering gateways – Out of the box inbound filtering either software or hardware will block most threats using threat detection algorithms. Basic gateways block blacklisted senders. More advanced options allow you to write your own acceptance policies.
Create Advanced Acceptance Policies – Your business is unique. Threats come in many forms. Maybe you want to filter all incoming image files or executables or maybe eliminate objectionable terms associated with risks. Sophisticated algorithms might help protect your business.
Accept only DMARC compliant email – One great idea that Google has pioneered is prioritizing DMARC compliant email. If you do the same, you dramatically reduce the potential for fraud and phishing emails making it to your users.
Setup Outbound Email filters – You do not want to become a source of spam, so setting up filters to control outbound email will reduce the risk of being blacklisted or of sending spam emails within your network.
Setup Advanced Outbound Policies – Advanced policies could include forcing the legal team to encrypt all outbound email or prevent emailing large files, executables, etc. Leveraging advanced policies will help make using email more secure.
Setup DMARC for all outbound email sources – Adopting DMARC for all your outbound email sources will help you protect your sending reputation and reduce the risk of your domain names being used in spam.
Invest in Spam and Phishing Awareness Training – As mentioned above, when employees are trained to recognize spam and phishing attempts, they are less likely to click on dubious links in spam and phishing attempts or click on and install malware.
While email was not initially designed with security in mind, new technologies are improving the security posture of email. Adopting these as they arise makes your business more secure and protects your users, clients and partners.