During 2024, many of the large email service providers will be introducing new security standards to email to cut down on spam email, and eliminating attacks where someone purports to be someone else in order to scam money from them. This is going to hinge around some new technologies that many outside the industry may not yet have heard, but fear not, I plan to break this down into manageable understandable English for any non IT speaking business person to understand. Unfortunately this will make this a long article. Of course, we can offer all businesses the hand holding in order to help them become compliant.
Background and Reasoning
Here at Spam Safe Mail, we handle approximately one million emails per day, and we are only a small humble spam email service provider. In analysing these emails, we can see that 98% of these are unwanted, and take up considerable disc space, and costs of running these large servers both in disc maintenance and electricity, and it’s knock on carbon footprint effect. Now, multiply this up to the scale of the large players in the email service provider field, and you can see their financial saving by cutting out these irrelevant emails.
The long term goal is to move to a “hard bounce” in order to reject these emails outright and not have them sit on email providers servers in users junk folders consuming expensive resources.
Cleaning Up Internet Emails
Previously, there has been efforts to clean up emails on the Internet by publishing something called a SPF (Sender Policy Framework) record, but, this was frequently abused in that it was nearly impossible to prove the sending server was permitted, and because of this nearly impossible to enforce.
The move to publish a new record called DKIM (Domain Keys Identified Mail) explicitly approves each email server to send email. Because the sending server will add a signed certificate to the header of the email it means that it can categorically prove the email originated from only that email server allowed to send email for that domain name. Please note, web servers may need their own and additional DKIM record too.
However, it then becomes important that email mailboxes are not compromised, and with more secure passwords of a longer length will be necessary, else your DKIM enabled email server will still send spam and other email attacks.
Lastly, in order to prevent anyone from intercepting emails and passwords in transmission, known as a “man in the middle attack”, all transmissions from your own computer to the email server and then from the email server to other email servers need to be encrypted. A newer secure and stronger encryption algorithm will be adopted as part of this process.
Bulk Email
It will be noticed that anyone sending bulk emails may have their senders email address “tainted”. In order to prevent this, it is recommended that…
Sending Bulk Emails
That you employ the services of email mail out providers in order to send bulk emails. It will no longer be acceptable to have many recipients listed in your To or CC address bar when sending emails. Emails need to be sent one at a time from a database over a number of days, and this is what the bulk email providers do for you. You may think, I send BCC anyway, how will this affect me? Well, the destination domains may still map back to Spam Safe Mail, and we, like other filtering services, can detect your multiple BCC list using this method when we receive the same email. This will taint the senders email address.
Sending Bulk Invoice Batches
What if my accounting software needs to send many invoices as part of a batch run? Well, this is less of a problem as you may think due to the fact that there is only one To address for the invoice being emailed. However, we have already seen some email gateways “rate limit” the number that can be sent to throttle the sender. Over time, as the Internet gets cleaner, this will be less of a problem, there will be more deliveries of invoices (ie less NDR – None Delivery Reports, also erroneously called “bounce backs” which will be done away with in favour of DMARC reporting, see below).
Timeframe
All this will take time to get every business on the Internet ready, so it will be done in stages, roughly three months apart as follows…
Stage 1: Enforcing Password Length, Domain SPF records, and Server Encryption
The first stage will be some groundwork in late 2023 by all businesses to get their houses in order with regards to the existing SPF (Sender Policy Framework) system and to implement longer passwords and email server encryption by February 2024. The minimum standard requirements will be…
- Minimum password length, 8 characters, however, it is recommended to be longer.
- Correct published domain TXT sender policy framework records in your domain name.
- An encrytion standard between email servers called “TLS” version 1.2.
Note: The email server encryption called TLS, will initially use version 1.2, but, at some time in the future, will use the faster and more secure TLS version 1.3. Businesses starting from scratch should therefore implement TLS version 1.3 encryption standards straight away as this is compatible with version 1.2. Any earlier versions will be rejected as too insecure.
Stage 2: Implementing DKIM Records
The next stage of the great Internet clean up will be to implement DKIM (Domain Keys Identified Mail). This is where an email server (or web server) will sign an email to prove it has permission to send the email. The receiving server will use the key in the domain to identify the email or web server, hence the process being called Domain Keys Identified Mail. This needs to be implemented before April 2024. The minimum standard will now increase to be everything from stage 1, plus, in addition…
- A published domain TXT DKIM record in your domain name to grant sending permission for your email server.
- A published domain TXT DKIM record in your domain name to grant your web server to send emails.
- A published domain TXT DKIM record in your domain for each email newsletter service providers you use.
- An encryption standard between email servers called “TLS” version 1.2.
Initially, there will be a soft enforcing of these DKIM signed emails in order for both testing and for all businesses to get use to the new security.
Stage 3: Implementing DMARC and Enforcing DKIM Records
The last stage will be to enforce the DKIM records from June 2024, so that emails that do not have a signed DKIM record are simply not delivered. Please note, these will not appear in a junk folder, because as explained in the Background and Reasoning section above, it would still cause disc space and electricity to be consumed. Instead, what is known as a “hard bounce” will happen and the email will simply not be delivered. However, there will be some feedback via an optional DMARC (Domain Message Authentication Reporting Conformance) record, more of this in a moment. Everything from stages 1 and 2, plus, in addition will be required…
- Enforcing and rejection of none signed DKIM records, reporting via DMARC.
- Rejection of bogus or forged DKIM records.
- Recommended implementation of DMARC records.
The only way message delivery and rejection will be reported will be via the published DMARC (Domain Message Authentication Reporting Conformance) record. The rejecting email server will look at your domain name to look up what to do and how to report a rejection. The published DMARC record to your domain name will instruct the recipients email server what to do.
Future Email Recommendations
In the future, looking into 2025, we all be more proactive about emails we send, perhaps not to CC as many people because it exposes everyone’s email address. Instead, perhaps use BCC, or use a newsletter sending email service in order to send bulk email. Email mailboxes will also need to be further toughened, and password made even longer. So, for 2025, we recommend…
- Email servers to adopt the TLS version 1.3 email standard for performance and encryption security.
- Users start using password of at least 11 characters long.
- Users cut down the usage of CC in favour of BCC.
- Users to offload emails to many multiple recipients to email out providers.
Additionally, key members of businesses that may share sensitive information, company directors and accountants, may like to look at S/MIME certificates in order to prevent data being stolen from inside an organisation or between organisations should a third party accountant be used.
I apologise for what is a lengthy article, but, I hope all this covers everything and makes sense, and of course, we would be more than happy to help businesses with the publication of their SPF, DKIM and DMARC records, and any S/MIME implementation they require.
UPDATES
01/04/2024 – Google have already blocked inbound emails that are not using TLS1.2 and DKIM signed. See Google’s statement.
