A Finance employee gets an email on a Tuesday morning. The sender’s name is familiar. The signature looks right. The request is believable.
Maybe a vendor wants to update banking information. Maybe an employee needs a payroll change before the next run. Maybe someone is asking for a document that would not normally raise an eyebrow.
Nothing about the message screams “scam.”
And that is exactly the problem.
The emails that cause trouble are not always the ridiculous ones. They are often the ones that fit neatly into an employee’s normal day.
So the real question for municipal leadership is not simply, “Do we have spam filtering?”
It is:
What is supposed to stop the wrong email from being trusted?
That question is bigger than one security product, one employee training session, or one setting inside Microsoft 365. It reaches into who is allowed to send email as your municipality, how employee accounts are protected, what staff are supposed to do when something feels off, and whether anyone can actually show leadership that those protections are still working.
For most municipalities, pieces of that answer already exist. The harder part is knowing whether the pieces actually fit together.
Someone Can Pretend to Be Your Municipality Without Hacking Your Email
This is one of the easiest email problems to misunderstand.
Suppose a resident receives what appears to be an email from the Village. The name looks right. The address looks close enough. Maybe the message references a payment, a permit, or some other legitimate municipal business.
The resident trusts it because it appears to have come from an organization they already know. But nobody at the municipality sent it. No municipal mailbox had to be compromised. Someone simply made an email appear to come from the municipality.
That is where terms like SPF, DKIM, and DMARC come into the conversation. Municipal leaders do not need to become experts in any of them. But they should understand what those protections are trying to accomplish.
They help other email systems answer a fairly basic question:
Is this message actually authorized to represent this municipality?
That matters because your domain carries trust. Residents recognize it. Vendors recognize it. Other government organizations recognize it. Employees recognize it.
If someone can borrow that trust simply by making an email look official, what looks like an email configuration issue can quickly become a public trust problem.
But there is another wrinkle that is very common in municipal environments.
Microsoft 365 May Not Be the Only Thing Sending Email for You
Ask someone which systems send email on behalf of the municipality and the first answer may be:
“Microsoft 365.”
Then someone remembers the utility billing platform.
And the agenda software.
And the emergency notification system.
Maybe there is also an HR platform, a permitting system, a payroll provider, or another vendor sending legitimate messages using the municipal domain. None of that is unusual. It is exactly how modern municipal operations work.
When No One Has a Complete Picture of Who Sends Email as You
The problem appears when nobody has a complete picture anymore. A system gets added. Another gets replaced. A vendor changes. An employee who knew how everything was configured retires, and suddenly part of the municipality’s understanding of how those systems fit together retires with them.
Eventually, the municipality may have several different services speaking on its behalf, and no one is completely sure which ones are supposed to be there.
That makes email security partly a technology question and partly an ownership question. Before asking whether a particular setting is correct, there is a simpler question worth asking:
Do we know who is legitimately allowed to send email as us?
That answer should not live only in one person’s head.
Pretending to Be an Employee Is Different From Actually Becoming One
There is another distinction that matters. Sometimes an attacker is only pretending to be someone from the municipality. Other times, they are actually inside a real municipal mailbox. Those are very different situations.
If a real account has been compromised, the person on the other end may be able to read actual conversations. They can see how people communicate. They may learn who approves payments, which vendors the municipality uses, when someone will be out of the office, or what kinds of requests employees are accustomed to receiving.
That makes the next fraudulent email much more convincing. It may come from a real account, appear inside an existing email thread, or reference details only someone inside the conversation would normally know.
That is why a Microsoft 365 compromise can unfold quietly. The first sign may not be a locked computer or a giant warning on the screen. It may simply be an employee saying:
“That email looked completely normal.”
This is also why domain authentication alone is not enough. Protecting the municipality’s name is one problem. Protecting the real people who use that name every day is another.
Multi-factor authentication, login protections, access reviews, monitoring, and administrative access all matter here. Leadership does not need to know how each one is configured.
But someone should be able to answer:
Who is checking that they are?
Employees Are Usually Trying to Get the Work Done
Email-security conversations can become unfair to employees very quickly. Someone clicked something, someone replied, someone believed a request, and the answer becomes “more training.”
Training matters. But municipal staff are not sitting around all day waiting for a phishing test. They are processing payroll, answering residents, managing records, paying invoices, preparing board materials, handling permits, coordinating with vendors, and trying to finish something before the next deadline.
A convincing fraudulent email succeeds because it blends into that work. A request to change an employee’s direct deposit may not sound unusual to someone who handles payroll changes. A vendor asking to update banking information may not sound suspicious to someone who talks to that vendor every week. A department head asking for something quickly may sound exactly like a department head asking for something quickly.
Build a Process That Does Not Depend on Perfect Judgment
The better defense is not expecting every employee to become a fraud investigator.
It is deciding ahead of time which requests should never rely on email alone. A payroll change might require verification outside the original message. A vendor banking change might require calling a known phone number already on file. A suspicious message should have one obvious place employees know to send it.
If someone clicked or responded, there should be a clear next step that does not begin with figuring out who might be responsible. That is where good email security starts feeling less like a technology program and more like a well-run office.
The safe response should be easy to follow even on a busy day, especially with payroll changes and other financial requests where one believable email can lead to a very real loss.
“We Have Microsoft 365” Is Not Really an Answer
Microsoft 365 gives municipalities a lot of capability, but simply having the platform does not tell leadership how well email is protected. The same is true of spam filtering, MFA, employee training, or any other individual control.
You can have several good tools in place and still have gaps between them.
That is why the more useful questions are about ownership and follow-through. Who reviews which outside services are sending email as the municipality? Who notices when an old vendor no longer needs to? Who checks whether MFA applies to the right accounts? Who reviews administrative access? Who investigates suspicious messages reported by staff?
And if an email problem becomes more serious, who decides whether leadership, insurance, legal counsel, or another outside party needs to become involved?
Those questions rarely belong to one person, and that is fine. The problem is when everyone assumes somebody else has them covered.
The Proof Matters Too
There is another question municipal leaders are increasingly being asked:
How do you know?
Not, “Do you think MFA is turned on?”
But, “Can you show us?”
Not, “Does somebody monitor suspicious activity?”
But, “Who does that, and what happens when they find something?”
That distinction matters during insurance discussions, audits, leadership reviews, and especially after an incident. Good security is not only about having protections. It is also about being able to show who owned them and that they were being maintained.
That ability to show what was in place, who owned it, and how it was being managed is part of building a defensible cyber program.
For municipal leadership, this does not mean collecting binders full of screenshots. It means there should be enough documentation and ownership that the answer does not depend on one person saying:
“Trust me, we have that covered.”
Email Needs Protection While It Travels Too
There is one more part of email security that tends to disappear behind all the talk about phishing. Messages also need protection while they move between email systems.
TLS helps encrypt those connections, while MTA-STS can help participating mail systems enforce secure delivery rather than quietly accepting an insecure connection. Those protections matter, but they solve a different problem from SPF, DKIM, and DMARC.
One protects how email travels. The other helps establish whether the sender should be trusted.
That distinction matters because there is no single “email security setting.” Different protections solve different problems, which is why buying one product or checking one box is not the same as knowing the municipality’s email environment is well managed.
Encryption Does Not Make a Bad Request Good
The same is true of encryption. Protecting sensitive information while it is transmitted can be very important, but encryption does not make the person on the other end trustworthy.
A secure connection can still carry a fraudulent request. A compromised employee account can still send an encrypted message. Sensitive information can still be sent to the wrong person, and a vendor payment can still be changed based on an email that looked legitimate.
That is why technology has to work alongside good municipal processes. The technology can help identify risk, but the process determines what employees do when that risk reaches their inbox anyway.
A Conversation Worth Having With Whoever Supports Your Technology
You do not need to walk into your next leadership meeting with a list of acronyms. Start with the questions that actually matter.
Ask whether someone outside the municipality can send an email that appears to come from your domain. Then ask the more important follow-up:
How do we know?
Ask whether anyone has a complete list of the vendors and systems that legitimately send email on the municipality’s behalf. Ask what happens if a real employee mailbox is compromised tomorrow morning, whether staff know exactly what to do when a vendor asks for new banking information or an employee requests a payroll change, and who reviews administrative access.
Then ask one of the simplest questions of all:
If someone asked us tomorrow what protections were in place, could we show them?
Those answers will tell leadership far more than a product list ever will.
Email Security Is Really About Trust
Email is woven into almost every part of municipal work. Employees use it, residents use it, vendors use it, other agencies use it, and board members use it.
That is why protecting email is about much more than keeping junk out of inboxes. It is about protecting who gets to speak as the municipality, keeping real employee accounts from quietly becoming someone else’s, and making sure staff have a clear way to question something that does not feel right.
It is also about giving leadership enough visibility to know that somebody is actually watching the pieces.
So instead of asking:
“Do we have a spam filter?”
A much better question is:
Who can send as us, who can get into our accounts, what happens when something suspicious gets through, and could we prove what protections were in place?
If nobody can answer that clearly, that is a useful place to start.
Can Someone Pretend to Be Your Municipality?
You should not have to guess whether the basic protections around your municipal domain are working. RWK’s Domain & Email Security Scan can help identify how your domain is configured and where email-authentication gaps may need attention.
Run Your Domain & Email Security Scan
Questions Leaders Are Asking
Can someone send an email that looks like it came from my municipality without hacking our email system?
Nobody at the municipality sent it. No municipal mailbox had to be compromised. Someone simply made an email appear to come from the municipality. That is where terms like SPF, DKIM, and DMARC come into the conversation. They help other email systems answer a fairly basic question: Is this message actually authorized to represent this municipality?
Why isn't having Microsoft 365 enough to protect our municipality's email?
Microsoft 365 gives municipalities a lot of capability, but simply having the platform does not tell leadership how well email is protected. The same is true of spam filtering, MFA, employee training, or any other individual control. You can have several good tools in place and still have gaps between them.
What systems other than Microsoft 365 might be sending email on behalf of our municipality?
Ask someone which systems send email on behalf of the municipality and the first answer may be: 'Microsoft 365.' Then someone remembers the utility billing platform. And the agenda software. And the emergency notification system. Maybe there is also an HR platform, a permitting system, a payroll provider, or another vendor sending legitimate messages using the municipal domain.
How should municipalities handle employee requests for payroll changes or vendor banking updates sent by email?
The better defense is not expecting every employee to become a fraud investigator. It is deciding ahead of time which requests should never rely on email alone. A payroll change might require verification outside the original message. A vendor banking change might require calling a known phone number already on file. A suspicious message should have one obvious place employees know to send it.
How is an attacker pretending to be a municipal employee different from one who has actually compromised a real account?
If a real account has been compromised, the person on the other end may be able to read actual conversations. They can see how people communicate. They may learn who approves payments, which vendors the municipality uses, when someone will be out of the office, or what kinds of requests employees are accustomed to receiving. That makes the next fraudulent email much more convincing. It may come from a real account, appear inside an existing email thread, or reference details only someone inside the conversation would normally know.