Email Protection and Deliverability with Johan Hammerstrom

What do the acronyms SFP, DKIM, and DMARC mean, and why do you need to prove your email is legit?

If you have been hearing these terms lately about your email or your cybersecurity liability insurance checklist, and don’t know your DKIM from your DMARC, you aren’t alone! Carolyn sat down with CEO Johan Hammerstrom to demystify the lingo and learn about the latest requirements for ensuring emails from your domain look legit to other inboxes, and how that helps protect your nonprofit now and in the future. 

Deliverability requirements are changing, so if you are in nonprofit leadership or nonprofit IT you will need to ensure your organization is in compliance. Listen to this podcast to learn the latest about this lingo, and then ask your IT provider or IT department about email protection and deliverability at your next check in.

Johan Hammerstrom, CEO of Community IT, breaks down why you should care about these acronyms and what they can do for your nonprofit security. Do you want to make sure your major donor can receive that email thank you? Then get on the email protection and deliverability train and listen to learn all about new requirements and best practices.

_______________________________
Start a conversation :)

• Register to attend a webinar in real time, and find all past transcripts at https://communityit.com/webinars/
• email Carolyn at cwoodard@communityit.com
• on LinkedIn

Thanks for listening.

Transcript

Carolyn Woodard: Welcome to the Community IT Innovators Podcast. My name is Carolyn Woodard. I am the Outreach Director for Community IT, and I'm so excited to be here today with our CEO, Johan Hammerstrom, who is going to tell us some more about protecting your email in your inbox. Johan, do you want to explain what the current best practices are?

Johan Hammerstrom: I think to understand the issues and challenges that we all have with email, it helps to understand the history of email a little bit. I want to talk a little bit about where modern email came from. that'll help to shed some light on why email is so problematic, particularly from a security standpoint.

Email is an early internet protocol. You've probably heard of SMTP. SMTP is the protocol is a definition of how the technology functions. SMTP stands for Simple Mail Transport Protocol. That tells you everything you need to know about why email is the way it is. It's simple. That protocol was written in the 1980s. The email protocol that we use goes back over 40 years. when it was first developed the Internet, as we know it, didn't even exist.

The internet was developed for things like ARPANET, which was the National Defense Internet that connected computers between different military installations and universities. It was a closed system, and these different computer scientists that were working on building out what eventually became the modern Internet wanted to communicate with each other. The original email protocol was FTP, File Transfer Protocol, which many people are familiar with as the protocol you should never use because it's insecure and doesn't work particularly well and it's error prone.

But that was in the 70s, that's what computer scientists that were working on the Internet used to communicate with each other, and that had some shortcomings. It was replaced in the early 80s with SMTP. some additions were made to that protocol over the years, but fundamentally the system that we use for sending email dates back to this SMTP protocol in the early 80s, which at the time was only being used for sending simple messages between computer scientists and other early researchers. There was no way that they could have predicted that SMTP was going to one day be used for signing legal documents, for requesting transfer of financial assets from one bank to another, for all the myriad diversity of things that we use email for today. The fact that email is and is still based on this very primitive internet protocol means that it's not secured.

There's no method for verifying the sender of a message. All the things that you would want to have built in to email, knowing what it's used for today, don't really exist in SMTP.

Carolyn Woodard: I kind of feel like you're letting them off the hook a little bit though, because there must have been some jokers in that initial group of academics and researchers. But you're right that they didn't, they couldn't, have foreseen the extent to which this would become a universal communication method. If they had, they would have been more intentional about setting it up so that it could be more secure.

Johan Hammerstrom: I think so, yes. HTTP is another protocol, the hypertext protocol, that was built with more security in mind, because that was built a decade later in the early 90s. There was starting to become more of a vision for what the Internet could be. 

One of the great advantages, though, of email and of SMTP in particular, is that it's an open system. that's part of the reason why it persists, because you could certainly envision and develop much more secure and robust communication protocols. They exist, but most of those are closed systems.

WhatsApp is an internationally used and recognized communication protocol that's very secure, has a lot of functionality. There are a lot of things about WhatsApp that work extremely well. That's a closed system. It's owned by Meta. They own every aspect of the system. You can't use another client to communicate with someone on WhatsApp. You have to use Meta's platform. 

One of the great advantages of email is that it's a universal system. In theory, anyone, and back in the day, anyone could and did set up an email server to send messages.

Carolyn Woodard: I'm hearing a couple of phrases recently that I actually don't know what they are. One is DMARC and one is DKIM. I know we talk a lot about your IT provider shouldn't just speak in lingo, and you should be able to understand everything your IT provider is talking to you about.

Could you help us demystify that a little bit?

Johan Hammerstrom: Sure. There are a lot of things missing from the SMTP protocol, such as encryption. One of the great glaring weaknesses of SMTP is that emails are sent basically in plain text, and you can intercept an email through the SMTP protocol and read its contents.

Now the transition of the information is being encrypted using other protocols and methods, but the SMTP itself is not encrypting the email. You have to use some sort of third-party solution to encrypt the email. For example, if you're on Microsoft 365, there's a little button that says encrypt, you can press that button and encrypt your email, but the recipient is going through Microsoft servers to read the contents of that email.Basically, that's the encryption of the email. It is not happening at the level of the email; it's happening at the level of Microsoft. 

Another shortcoming of SMTP is that there's no verification system by default in the protocol. I remember in the early days of email, in the early 2000s, one of the ways that you could test whether or not an email server was working is you could just open up a command prompt via telnet into it and start sending SMTP commands and sending email out and  harassing all of your fellow coworkers by pretending to be them or sending email, because there was no verification system whatsoever. I could set up my own email server and start to send email out, pretending to be somebody else, pretending to be somebody else's domain, because SMTP by default didn't have email verification. 

It is bad, and it's kind of remarkable that here we are in 2024, and it's kind of taken that long for the industry to develop email verification mechanisms. To be fair, a lot of email verification mechanisms have been around for 10 plus years, but they're sort of bolt-ons, they’re bolted on to the basic SMTP platform.

That's essentially what DMARC and DKIM are. They're a method that’s been added in to the system for verifying the sender of an email. It's clunky, and it's like, really, this is how it works? The answer is yes, that's really how it works. The reason that it works in this way dates back to the original primitive SMTP protocol.

Carolyn Woodard: Is this something that a regular person of a nonprofit needs to fully know and understand? Is it something that your IT director needs to know, or your executive team? If you're worried about cybersecurity, can you personally go out and say, I have to have DMARC on my email? How does it work? 

Johan Hammerstrom: There are three acronyms that you should be familiar with. they all refer back to email verification. Those acronyms are SPF, DKIM and DMARC. They’re somewhat related approaches to verifying email. The goal of all three is to ensure that the email that we're sending is coming from our organization. 

SPF was the first, SPF has been around for a while now, I think 10 or 15 years. Basically, these are all DNS records that you set up. DNS is basically your, when you own a domain, your organization owns a domain, and you have various DNS records that tell the rest of the Internet, if someone's trying to go to this domain in a web browser, here is where we host our website. It's at this address location. Domain Naming System.

If someone's trying to send an email to that domain, your DNS records tell the email server, “here's where we receive our email. Please route email going to this domain to this server over here,” which nowadays is mostly Microsoft's 365 exchange servers or Google's Gmail servers.

The majority of the email traffic is going to those two locations, with some occasional email going to, I guess at the consumer level, email is going to Yahoo and Hotmail and AOL, and I'm dating myself here, but Outlook.

Carolyn Woodard: No, I still see AOL addresses sometimes, and I'm always just amazed it still exists. in the past, this was an address of an actual server, like a node, and these days, it's usually a virtual server, virtual address, but it's still your website and your email is associated with that domain. That tells the rest of the internet kind of existentially where you are.

Johan Hammerstrom: Exactly, exactly.  you write up an email, you hit send. 

If you're on Microsoft or Google, it goes to their mail servers. The Microsoft or Google mail server looks at who you're sending the email to, pulls up the DNS record for that domain, identifies where it should go, and then routes the email to that mail server. that's basically how the SMTP mail protocol works. The mail server that's sending the email, it knows who it is, and it knows where the email is going. The receiving mail server gets the email. At the most basic level, if that server is in fact hosting email for that domain, it accepts the email and delivers it into the mailbox of the recipient that it's addressed to. If there's a mistake, if the DNS records are configured incorrectly and they're pointing to a server that isn't set up and correctly configured to host that domain, it will reject the email. That's when you get those bounce back messages, non-deliverable. You tried to send the email to a server that doesn't actually host that domain. What the recipient server is not doing is verifying that it's receiving email from a valid source, not originally. The first step to try to correct that was SPF.  

SPF is a record that you add into your DNS that basically says, email coming from our domain is going to come from one of these delivery mechanisms. you'd put in the IP address of whoever's hosting your email.You'd put in that IP address. Now, this is all up to the recipient. The recipient doesn't have to check SPF.

They can just accept email. But if they're checking SPF, then they're going to receive the email. They know the IP address, the location of the server that that email is coming from. If they so choose, they can then go look at the SPF record and say, does the server we're receiving this message from match up with the valid list of servers they've got on their DNS records?

Carolyn Woodard: It sounds a little almost like registered mail, but in reverse. Registered mail is going to tell you if it arrived at the destination and when. But this is kind of checking that it came from a specific destination and that that destination is legit.

Johan Hammerstrom: That's a great analogy, Carolyn.

It's kind of hard to make the real-world analogy because in some ways it works so differently. But the real-world analogy would be if you say, I only send mail from this post office. If you get a letter from me, it has to come from the post office in my hometown.

Then you would get the letter in the mail and you would check the postmark, where it got stamped, and then you'd have a list, and say, I'm getting a message from Carolyn. Her letters only come from this post office. If I see that it's coming from a different post office, then I throw the message out because I know it's not from you legitimately.

That's basically how SPF works.

Carolyn Woodard: Then you mentioned two other acronyms, DKIM and DMARC.

Johan Hammerstrom: They are more recent. DKIM is intended to address a number of shortcomings of the SPF approach.  again, you can almost trace the history of the internet and how it functioned at a particular period of time based on how the protocol was set up.

SPF was set up 10 or 15 years ago when most people had one or two mail servers that they were sending email from. Those didn't change very often. Fast forward to the cloud era, and you could imagine that maybe you're sending email from a lot of different email servers.

If you're using Microsoft, it could be coming from their Northern Virginia servers, it could be coming from their Oregon servers. You don't know where it's coming from. To make matters worse, your organization is probably sending email not only from your main mail server, but you're probably sending email from MailChimp, you're probably sending email from your fundraising platform, you could have eight or nine different locations that you're sending email from. So now you have to, on an ongoing basis, keep up with all of the different IP addresses that correspond to the legitimate sources of email from all of those different vendors. 

Then, to add insult to injury, SPF has a 10 IP address limit. If you're sending email from more than 10 IP addresses, you've got to pick your top 10. The rest of them, you better hope that they're not actually checking for SPF. Anyway, SPF still gets used a lot, and we would recommend using that.

Unless you're running your own email server, you're not really controlling whether or not SPF is being checked for your email. If you're on Gmail, that's up to Google whether or not they're checking SPF when they receive email. I'll get back to that later, because that's actually a really important point. But it's a best practice, you know. 

DKIM

SPF has all these limitations, that’s where DKIM comes in. DKIM is meant to address the limitations of SPF for providing email verification. DKIM basically uses public key encryption technology. Essentially, you go into any of the systems that you're using that are sending email on your behalf. If you're using Microsoft, you'd go into your admin console of Microsoft 365. If you're using MailChimp, you go into the admin console of MailChimp, you're using HubSpot, you'd go into the admin console, and you'd say, I want to set up a DKIM record.

It generates a very long, complex code, which is basically half of an encryption handshake. That's the public key. You take that code, it'll generate the whole record for you, and you put that in your DNS record.

Then there's a private key that the server maintains. Now, if the recipient has DKIM set up, if it's checking for DKIM, then it'll get the email, it'll go out to the DNS record, it'll pull that code, and it'll send it back to the sender. There’s an algorithmic process that it goes through to confirm that it's valid.

If email is being sent by someone who's not legitimate, they're not going to have a valid other half of the code to match up. It’s like a secret decoder ring. You know, I'm really dating myself here. You have two halves of something, and they have to match up perfectly. The only way they're going to match up is if you have both sides of it. That's basically how DKIM works.

It's all very technical. You don't really need to know the technical details of how it works. What you need to know is that you should have DKIM records set up for every valid sender of your organization's email.

Every system that you use that sends email from your organization's domain or domains -  that's where it starts to get really complicated if you have multiple domains that you're using. You need to go into ALL your email sending systems and generate those DKIM records and update your DKIM ... and by you, I mean whoever owns IT for your organization.

Just know that when you do this, now your email will be verified. The email coming from your platforms, from your domain, will be verified by any mail server recipient that uses DKIM, the DKIM method, to verify the email sender.

Carolyn Woodard: Basically, if you are the administrator, you probably are already swimming in a world where you have done DKIM probably, but if you haven't, you need to. 

Then if you are a non-technical person who is managing IT or you're the point of contact for your outsourced IT or your IT department to your leadership, you need to know enough about DKIM to ask them about it. They should be able to verify you that they're doing it, or not doing it, and give you the reasons that they're not doing it. Like you said, Johan, maybe you have multiple domains and it's more complicated, but  you, as a non-technical person, you wouldn't be implementing DKIM, you need to ask your administrators if they have done this.

Johan Hammerstrom: Yes. Is DKIM set up for our domain for all of the systems that we use to send email? 

Carolyn Woodard: That may be something that you need to get the other stakeholders in place for. Mailchimp is probably used by your marketing department.  It may have been overlooked in terms of your IT department, knowing that it needs to also have the email verification on your end.

Johan Hammerstrom: That's a great point, Carolyn. Yeah. One of your program teams may have worked with a third party to build a custom application that sends email. 

Now, hopefully that's all known by your IT department, but that doesn't always happen. That third party could be using, that small custom shop could be using a third party like SendGrid. Now you've got to go tell them they need to go to SendGrid to get the DKIM records.

It does require buy-in and communication and identifying all of those stakeholders in the organization that may have responsibility for sending email from the organization's domain.

Carolyn Woodard: Hopefully that's something that if you are being serious about cybersecurity, you're having your monthly or quarterly meetings to get those stakeholders together and update them on best practices, any new trainings, any new trends that are coming in, things that you need to be thinking about.  that would be a great place to bring up DKIM if you're not sure what it is or if all of them are participating.

Johan Hammerstrom: Let me say one more thing about DKIM and why it's the acronym of, I don't know if it's the acronym of the year, AI is for sure the acronym of the year of the decade. 

But there are two reasons why you've been hearing a lot more about DKIM lately. 

Cyber Insurance Requiring DKIM

The first is a lot of insurance companies are now requiring you to set up DKIM as part of your cyber liability insurance application. The reason is, it's not so much that DKIM doesn't really protect you. It protects people who might be receiving email from you, from malicious actors pretending to be you. It's kind of a good internet citizen move to set up your DKIM records.

The reason that insurance companies are requiring it is that if everybody gets DKIM set up, then it's really going to cut down on malicious spoofed emails. Because the threat actors aren't going to be able to pretend to be valid domains anymore. Because the more people have DKIM set up, the more email verification is out there in all of the different email systems. That's the first reason you're seeing a lot more about DKIM. Organizations are going to be required to have their DKIM records set up as part of their cyber liability application process. 

Email Vendors Requiring DKIM

Then the second reason you've been hearing about it is because the major email vendors, Gmail, Yahoo, Microsoft, they are all going to start requiring DKIM. They’re not going to allow you to go without. They're not going to receive email. 

Right now, DKIM is typically set up in such a way that there's different levels of testing that you can do on email that an email server is receiving. There are different levels of testing that an email server can run on received email. 

The first level of testing is I'm looking for valid DKIM, and if I don't see it, I'm going to just flag it. I'm going to report that I got an email from this domain that doesn't have valid DKIM. 

The second level is I'm going to receive the email, and I'm going to issue a warning. I'm going to say, we got an email from this domain, and there's no valid DKIM associated with the server that sent the email. Or there is a DKIM, but it didn't match the server that was sending the email.  

Then the third level is we're going to quarantine the email.

I think you're going to start seeing a lot more mail servers quarantining email that doesn't have valid DKIM. 

Then the fourth and highest level is we're going to reject the email. It's not going to get delivered.

I think what we're seeing right now is that all of the major email providers are starting to move their way up the DKIM ladder, and we're going to get to a point where if you don't have DKIM configured for your domain, you're not going to be able to send the email. we're starting to see that now. Like Yahoo, heading into 2024, Yahoo announced that they were going to require DKIM this year.

Carolyn Woodard: Now, does that impact you if you're just a personal user of Yahoo!? Do they do it for you or...?

Johan Hammerstrom: Yes, this is all happening at the server level. If Yahoo decides to reject all emails that don't pass DKIM verification, then you're not going to receive email from someone who doesn't have DKIM set up.

Again, that's happening at the domain level.  If you're a donor, you know, or you receive a newsletter from a nonprofit organization whose mission you believe in and that you want to support, and you have a Yahoo email account, if that organization hasn't set up DKIM for their domain, then at some point you're going to stop receiving their emails. Yahoo is just going to reject them.

Google Workspace and DKIM Administration

Carolyn Woodard: This makes me think about particularly smaller organizations. I feel if you're in the Microsoft world, you probably have an administrator, but if you're a small organization that set up Google Workspace and just purchased your domain for your website, is that something that Google is going to tell you that you need to have done? Because for a lot of smaller organizations using Google Workspace, they don't really even have an administrator. They just set it up and kind of forgot about it. 

Johan Hammerstrom: This is one of the reasons that DKIM isn't universally mandatory yet, because DKIM adoption is not as simple. The technical mechanism is not simple and straightforward. Here we are 30 minutes into this podcast, and we're doing the deep dive on DKIM, but it's not easy to set up.

Part of the reason that this hasn't been mandatory sooner, is that adoption of DKIM is taking a really long time. I do think that if you're a small organization, you're on Google, and your DNS records are hosted by Google, then they'll make it easy for you to kind of go through and set up the DNS records for Google.

If you're using MailChimp, the challenge in all of this is that it's up to the person who owns the DNS records to identify all of the systems that they're using to send the email and then set up the corresponding records for those systems. And that's just... You know, it's a level of technical complexity that it just can't be automated. 

Even if Google is hosting your domain and your DNS records, they aren't going to know what you're using for sending emails. Even if they did, they don't have the access to go into those systems to obtain the corresponding keys that need to be added into the DKIM... it's tough. It's tough for smaller organizations to get this implemented.

Carolyn Woodard: I imagine that because Google Workspace is so consumer-oriented in making it easy for people to set it up with little technical experience that they will be doing a lot of outreach around this and figuring out some way to assist those smaller organizations or small businesses too, that have done that. I will put in a plug for us that if you're a larger and using Google Workspace, we are one of the few MSPs that outsource IT that can support Google Workspace.  that is something that we would be doing for our clients.

Advocating for DKIM

Johan Hammerstrom: Yeah, and if you need to sell this to the rest of your organization, I would say “We need to set up email verification.” I wouldn't even use the term DKIM unless people know what that means. I would just say we need to set up email verification. We need to set it up for our cyberliability insurance, and we need to set it up to ensure that our emails get delivered and don't get blocked. 

Carolyn Woodard: I love your example of the donor, that is a really good way to talk to your executive team. “We want our emails to get in people's inboxes.”

DMARC Reporting 

Johan Hammerstrom: Yeah. All right, so now we've arrived at DMARC. What is DMARC?

DMARC is basically the reporting tool for all of this. I mentioned earlier that DKIM has these different levels of response. It can pass through, it can report, it can quarantine, it can reject.

All of that gets logged in these DMARC records. DMARC is basically the reporting for your domain. A mail server will receive an email message and it will check the DKIM. If the DKIM fails, then it will go to the domain and look for where the DMARC reporting goes, and then it will send that report. “Hey, look, we got an email from this IP address saying it was you, there was no DKIM, we rejected it,” and that just gets logged at wherever the DMARC server is.

Generally, we're leaning towards third-party DMARC solutions just because they have a better management interface. You don't have to set up DMARC, but DMARC is good for you to manage, not only manage your own DKIM to make sure that valid emails are going through, because you'll see in the DMARC reporting, if your valid emails are getting rejected, that will show up there, but it'll also show you who else is pretending to be you. People pretending to use your domain to send emails as you, if their attempts to deliver email are getting rejected by lack of DKIM, that'll show up in the DMARC reports as well.

That's why we recommend a third-party platform for hosting DMARC, because you can imagine, someone needs to parse all that data for you. It's going to be thousands and thousands of entries. Really nice third-party DMARC reporting platforms have management tools that you can use to flag different things and silence other alerts that you're getting.

But DMARC is basically, to make a long story short, DMARC is the reporting component of email verification. Most of these third-party platforms are not super expensive. I think they're on the order of $50 a month, probably per domain. If you're a larger organization that has a lot of domains that you're working with, it's going to be more expensive. But as DKIM requirements start to get stricter and stricter, having good DMARC reporting to understand what's happening with your email delivery is going to become more and more important.

Carolyn Woodard: It sounds like the choice of the DMARC third-party solution and monitoring that data and pulling the reports out of it is definitely something that would be your IT department or administrator.

Johan Hammerstrom: Yes, that's your IT department. That's proactive. You can review your DMARC reports with your IT provider every week, every month, or they can send you a summary of what you're seeing in DMARC.

Like I said before, the SPF has been around for 10, 15 years or more, and we're just starting to hear about it now. It's hard to know how quickly these trends will move, but I think we've reached a point where it's important to at least be aware of these things. I think with DKIM and DMARC organizations that have at least 20 staff or more should start to have a plan for putting these systems into place.

Other Email Services and DKIM

Carolyn Woodard: Can I ask you how this differs from, I think there are several, like MailChimp, I think HubSpot as well will tell you if an email was opened or clicked on. it sounds like that's different from what DMARC is telling you. Can you talk a little bit about that?

Johan Hammerstrom: Yeah, that's a great question. MailChimp and HubSpot will send the email with a special link. They’ll know if the email has been opened because when the email is opened, that triggers a certain type of traffic to go back to MailChimp or HubSpot.

Then when you click on a link in the email, that triggers another type of traffic to go back. The mass emailing solutions, their ability to measure click-through and open rates are all something that they're handling directly. At the risk of getting too nerdy, that's not happening at the SMTP level, so that has nothing to do with the email delivery. That is all based on the special codes and links that they’re building into the emails as they're crafting them.

Carolyn Woodard: I was just thinking about it in terms of one of the use cases that you talked about, and probably your development team would want to be involved, at least in the strategic level of talking about DMARC and DKIM, is like you said, if someone is not receiving your emails, like a major donor, major gift emails, depending on what system you're using, some of those emails go straight out through your CRM, so having the DMARC reporting to tell you that extra level of deliverability, I think would be something that that team would probably want to know about. And they may be able to help you advocate for it.

Johan Hammerstrom: I think I probably should have been clear about this at the outset. DMARC and DKIM are all about protecting other people from your email, number one. Number two, making sure that your email gets delivered.

I think there's a real misconception. I think that's a good conceptual shift because that'll help you really get in the mindset of what DKIM and DMARC are about. Because I think they very often get associated with cybersecurity. People immediately assume DMARC and DKIM protect us from threat actors. That's actually not what they do at all. They protect other people from threat actors that pretend to be you.

There's a collective good. If everybody implements DKIM, then we're all protecting each other from threat actors. But implementing DKIM, that’s a mass action problem in some ways because it is not simple, there are barriers to starting to use DKIM. 

Carolyn Woodard: But it does seem that if we can get to a mass level of protection, as you said, that cyber insurance is requiring more and more people and organizations to use this, it seems like it would have to cut down on phishing that everyone would be receiving eventually.

Johan Hammerstrom: Yes, I think it would make it almost impossible for someone to fake the domain that they're sending as. I think what we've seen that become less and less common as more and more people are setting up DKIM. There is a selfish reason to do it, because you don't want someone pretending to be you, and pretending to be your domain.

There are good reasons to do this in addition to the common good, which should be a good enough reason to do it. What we do see is more and more threat actors, they will register a name like Microsoft with two i's, because that'll be hard for people aren't looking closely, and they'll assume it's coming from Microsoft, but it's Microsoft with two i's or, Google with a 1 instead of the L, just visual tricks that we're starting to see more and more of. Those are difficult to protect against. That's where training becomes important.

Multiple Domains and DKIM

Carolyn Woodard: I guess that just brought up a last question for me. You mentioned earlier organizations that have multiple domains, and I know it used to be pretty standard to purchase, the .net in addition to .com or .org, you would have those additional domains, and they would point to your main website. Threat actors will own Microsoft.net instead of microsoft.com, and you just don't even really look at it and notice. 

If you do have multiple domains for your organization, you and your IT team should be talking about that in this context of the SPF, DKIM and DMARC conversation.

Johan Hammerstrom: Yeah, for sure. I think that's where starting to do a more thorough security assessment becomes valuable. What is the threat level? It’s easy to spend a lot of money on cybersecurity and target the wrong things. You really need to understand what are the specific risks your organization is facing? Is there a big risk that someone's going to spoof your email, or is the bigger risk that your email is not going to get delivered because the recipient server is not accepting email that isn't verified? If that's the bigger risk, then let's invest the money in good DKIM and DMARC, and we don't need to buy every version of our domain. But if you're a very prominent organization, high profile, likely to be targeted, then you probably need to do both. 

Carolyn Woodard: Anytime you start thinking about and talking about cybersecurity, especially with senior leadership in the organization, that really needs to be your mindset. What are the specific threats that our organization is facing? Having an assessment can help you walk into those meetings with people who are not as technical and be as transparent and clear about where the threats are and where your organization is more prepared and maybe less prepared to counter those threats. I will put in a little plug that we do those assessments so you can get in touch with us. But there are a lot of places that can do those assessments, and there are some that are online.

If you're a small organization, you can get a checklist and just go through it to develop the idea of what you need to talk about. Well, thank you so much, Johan. I appreciate your time today, and I feel so much smarter. After hearing these terms a lot, I didn't know who to ask, and I'm really glad that I asked you.

Johan Hammerstrom: Well, as someone who has some responsibility for the email that we send out at Community IT, it's important for you too. This is a good chance for us to talk about this. Using the acronyms kind of shuts everybody down because everyone thinks “I'm never going to know what that means.” I think finding ways to translate these topics into terms that other business owners, owners of key business functions of your organization throughout the organization can understand. Not only will they get brought into it, but they'll be more effective at doing their work. That'll make the organization as a whole more effective and more likely to accomplish its mission.

I'm glad you and I were able to have this conversation. That was good. Thank you.