DNS Misconfigurations Let Attackers Spoof Fire/EMS Email

A lot of agencies think email spoofing is mostly a user-awareness problem. It is not.

Weak DNS email-authentication records give attackers room to operate. If the records are permissive, stale, or absent on one of your domains, scammers do not need much creativity. They can send phishing mail that appears to come from command staff, from HR, from a CAD vendor, or from a dispatch supervisor, and the receiving mail systems may have no strong reason to block it. In Fire and EMS, that matters more than it does in a generic office environment. Crews act on urgent messages. Supervisors trust mutual-aid partners. Vendors routinely send patch notices, links to portals, support instructions, billing notices, and training alerts. A weak email-authentication posture turns all of that routine traffic into attack surface.

The real problem is not one broken record. The real problem is incomplete email identity architecture. When SPF is permissive, DKIM is partial, DMARC stays in monitor mode, and DNSSec is absent, you are telling the rest of the internet that your domain identity is soft. Attackers will use that.

How to prevent email spoofing fire department domains

Start with the basic point: spoofing protection is a DNS problem before it becomes a mail-client problem.

Most agencies have at least one public-facing domain used for email. Many have several. That may include a city domain, a department-specific domain, an older domain left in service, a training subdomain, an HR subdomain, and sometimes a vendor-hosted communications subdomain that nobody reviewed after implementation. Attackers do not care which one your policy team considers primary. They care which one is easiest to impersonate.

Any one of those domains can become a problem if SPF is weak, if DKIM is unsigned or misaligned, if DMARC never reaches enforcement, or if DNSSec is missing from the trust chain. Once that condition exists, you have a path to impersonation.

A fake message from IT support asking a battalion chief to review a VPN change can be enough. A spoofed CAD vendor patch notice sent to dispatch supervisors can be enough. The same applies to payroll messages, benefits updates, password-reset prompts, tax forms, and annual training notices.

This is one reason I keep pushing agencies to treat communications infrastructure with the same seriousness as CAD-to-ePCR interfaces. The article on CAD-to-ePCR interfaces and the quiet HIPAA risk makes a related point from a different side: the quiet connective systems are often where the real exposure sits.

DMARC policy for public safety agencies

DMARC is where many agencies fail operationally, even when they have at least heard of it and even when a record is technically published.

The usual pattern is straightforward. The policy sits at `p=none`, the reporting mailbox is incomplete or ignored, and nobody is acting on what the reports actually show.

A `p=none` DMARC policy gives you observation rather than protection, which is useful for a short baseline period but useless as a permanent end state.

If your domain has been in steady-state operations for months or years and DMARC is still in monitor mode, that is not caution. That is non-enforcement. Attackers benefit from that delay.

A practical DMARC rollout for a public safety agency usually looks like this:

1. Inventory every system and vendor that sends mail using your domain.

2. Publish DMARC with `p=none` and working `rua` reporting.

3. Review aggregate reports for at least 30 days.

4. Fix legitimate senders that are failing alignment.

5. Move to `p=quarantine` and watch for breakage.

6. Move to `p=reject` once the authorized senders are clean.

That sequence is not complicated. It does require ownership. Someone has to know which systems send on behalf of the agency, who approves an added sender, and where DMARC reporting gets reviewed. If nobody owns those steps, the policy drifts, the exceptions accumulate, and spoofing keeps working.

For Fire and EMS agencies, DMARC enforcement matters more because the working culture rewards speed. People move quickly during incidents, during staffing shortages, and during vendor outages. Attackers prefer that environment because they only need one convincing message to arrive at the wrong moment.

DKIM setup for EMS email security

DKIM failures are usually less visible to non-mail admins, but they matter just as much. DKIM gives the receiver a cryptographic way to validate that a message was authorized by the domain owner. When signing is absent, when a selector is stale, when the key is too weak, or when the alignment is broken, that control falls apart.

Common problems I expect to see in this sector include:

• 1024-bit keys that should have been replaced with 2048-bit RSA keys
• third-party senders using their own signing domain without proper alignment
• subdomains sending operational email with no DKIM configuration
• stale selectors left in place after migrations
• failed key rotation because nobody documented the dependency

The agency consequence is straightforward. A recipient sees a message that looks valid because the display name and address are familiar, but the domain has not published a strong enough technical signal to let the receiver reject the forgery with confidence.

This gets worse when agencies rely heavily on vendors. Your ePCR vendor, your benefits system, the training platform, the alerting platform, donor software, and city-wide communications tooling may all send mail that touches your domain, your staff, your public image, or some combination of those. If those senders are not documented and validated, your DNS record set becomes a patchwork. That is not a stable security posture. It is just accumulated exceptions.

The same vendor-governance issue shows up in other areas too. Your ePCR vendor's BAA probably isn't enough makes the compliance version of this argument. The paper agreement is not the control. The technical implementation is the control.

DNS email authentication best practices public sector teams should implement

For most agencies, the work breaks into four control areas.

1. Lock down SPF

SPF should authorize only legitimate senders. That means no `+all`, no `?all`, and no permanent soft posture because nobody wanted to chase vendor records. Use `-all` once the inventory is complete. If you are hitting the 10-lookup limit, fix the architecture instead of leaving a broken record in place.

2. Enforce DKIM where mail actually flows

Sign mail for all operational domains and subdomains. Use 2048-bit keys. Rotate them on a schedule you can support. Verify that third-party platforms sign in a way that aligns with your domain strategy.

3. Move DMARC to enforcement

Build reporting first. Fix alignment issues. Then progress through quarantine and on to reject. Reaching `p=reject` is the point where unauthorized mail stops being merely observed and starts being blocked.

4. Add DNSSec to protect the trust chain

DNSSec is often ignored because SPF, DKIM, and DMARC get more attention during mail projects. That is a mistake. Without DNSSec, an attacker who can poison DNS responses can interfere with the records your email-authentication stack depends on. If your registrar supports it and your authoritative DNS platform supports it, enable DNSSec and maintain the chain correctly.

Phishing attacks against fire departments 2024 and beyond

The lure will change. The attack pattern will not.

Attackers will continue to impersonate:

• CAD or dispatch vendors with urgent updates
• neighboring agencies in mutual-aid relationships
• internal IT staff requesting password resets
• chiefs or deputy chiefs sending urgent document requests
• HR or payroll staff asking users to review benefits or tax forms

The operational reason these work is simple. Public safety agencies run on fast trust and clear authority. A message that appears to come from command staff or a known vendor lands in a context where people are used to acting quickly.

That is why email authentication should be paired with broader operational controls. Use conditional access. Use phishing-resistant MFA. Add vendor verification procedures. Require documented out-of-band confirmation for urgent administrative requests. The DNS layer is necessary. It is not sufficient by itself.

If your broader concern is how modern tooling changes the public safety threat surface, the articles on AI, HIPAA, and EMS ePCR narrative risk and PHI on the mobile data terminal cover the same operating principle from different sides: the system people trust under stress is the system attackers will target.

Execution model for agency leadership and IT

If you lead IT, if you own infrastructure, or if you are the agency executive approving the risk posture, the next steps are not theoretical.

• Inventory every domain and subdomain tied to agency communications.
• Identify every approved sender, including third-party services.
• Audit SPF for hard-fail posture and lookup count.
• Validate DKIM signing and key strength across all senders.
• Publish and operationalize DMARC reporting.
• Move DMARC from monitor to quarantine to reject.
• Enable DNSSec and confirm DS records at the registrar.
• Build a change-control process so new vendors cannot send mail on your behalf without review.

This is not glamorous work. It is still high-value work. A lot of successful phishing campaigns start because basic domain controls were never finished.

Frequently Asked Questions

Why do phishing emails spoofing our fire chief still reach our crews even though we have SPF

SPF only covers part of the identity problem. It checks the envelope sender, it does not fully address visible impersonation, and it does not give you enforced domain policy on its own. The stronger answer is aligned DKIM plus DMARC at `p=reject`, so receivers have both technical validation and a clear instruction to block unauthorized mail.

Can our CAD vendor send email on our behalf without breaking SPF

Yes, if the vendor is explicitly authorized in SPF or if they DKIM-sign with proper domain alignment. The agency should document that sender, validate the actual mail flow, and then re-check the setup during migrations or vendor changes.

What is the risk if we do not implement DNSSec for our email domains

Without DNSSec, DNS responses tied to SPF, DKIM, or DMARC are easier to tamper with through cache poisoning or manipulated records. That weakens the trust chain underneath your mail-authentication controls.

How long should we run DMARC in monitoring-only mode before enforcing

Usually about 30 days is enough to establish a baseline if someone is actively reviewing the reports and fixing legitimate sender issues. After that, move to quarantine, then reject. Staying at `p=none` indefinitely is not a protection strategy.

What is the first thing a Fire or EMS agency should do if it suspects email spoofing

Begin by checking whether SPF, DKIM, plus DMARC are published and aligned across every sending domain. After that, review DMARC aggregate reports, confirm who is authorized to send mail, and search for recent malicious messages that used your domain or impersonated executive staff.

Email spoofing against Fire and EMS agencies is not a niche issue. It is an identity-control failure with operational consequences. If your DNS records are wrong, attackers can borrow your agency's name to move phishing into places where people act fast and verify late.

Fix the DNS layer first, then build the rest of the control stack on top of it.

-- Steven