Government agency email occupies a specific and peculiar position in the deliverability landscape. The stakes are higher than in commercial email — a citizen who does not receive a benefits determination letter, a tax notice, or a public health alert because the email landed in spam has a real-world problem that is not comparable to a missed promotional offer. The infrastructure is often more constrained than in commercial settings — legacy systems, bureaucratic procurement cycles, and multi-agency IT governance create technical debt that affects email security configuration. And the threat landscape is more severe — .gov domains are premium targets for phishing and impersonation because recipients inherently trust email that appears to come from government sources.
Most deliverability writing focuses on commercial senders trying to get marketing email to the inbox. Government email has a different set of problems: it is more likely to be impersonated (requiring aggressive DMARC enforcement), more likely to face trust deficits with recipients who are suspicious of unsolicited government email, and more likely to be constrained by IT governance structures that make rapid configuration changes difficult. This guide addresses those specific problems.
Why Government Email Deliverability Has Higher Stakes Than Commercial
When a retail company's promotional email lands in spam, the consequence is a missed sale. When a government agency's email about benefit eligibility, permit status, or health alert lands in spam, the consequence can be a missed deadline, a lost benefit, or a failed public health intervention. The asymmetry between commercial and government email stakes is not abstract — it shows up in very specific failure modes that the agencies I have worked with or observed have experienced.
A state workforce agency sending unemployment determination letters via email: if those emails go to spam, recipients may miss the window to appeal determinations they believe are incorrect. The agency then receives phone calls and walk-in traffic from people who "never got" the email, creating operational burden that is entirely avoidable with proper email infrastructure. A county public health department sending COVID test result notifications during 2020-2021: delayed delivery by even a few hours created public health exposure while recipients waited for their status. A federal immigration agency sending biometrics appointment confirmations: recipients who missed confirmations because the email went to spam had to reschedule, generating backlogs that rippled through the appointment system for weeks.
These are not edge cases — they are regular occurrences in government email operations that have historically operated without the deliverability investment that comparable commercial operations would make. The business case for deliverability investment in government is not about revenue per email; it is about service delivery and public trust, which are the government's fundamental obligations.
The CISA BOD 18-01 DMARC Mandate and Its Legacy
In October 2017, CISA (then called DHS's National Protection and Programs Directorate) issued Binding Operational Directive 18-01, which among other requirements mandated that all federal executive branch agencies configure DMARC for all second-level .gov domains by January 15, 2018, starting at p=none and reaching p=reject within one year. This was, at the time, the most significant government-driven mandate for email authentication in any country — and it drove DMARC adoption among federal agencies faster than any voluntary programme had achieved.
The compliance results of BOD 18-01 were significant but imperfect. A 2023 review by the Global Cyber Alliance found that a majority of federal .gov domains had implemented DMARC, with a meaningful fraction at p=reject. However, the review also found that a significant number of federal domains had DMARC records with configuration errors, had SPF records that were approaching or exceeding the 10-lookup limit, and had not registered their domains in DMARC aggregate report monitoring that would reveal ongoing authentication failures.
BOD 18-01 applied to federal executive branch agencies. State and local government agencies — which in aggregate have far more constituent-facing email communication than the federal agencies — were not covered by the directive and have had no equivalent mandate. State and local .gov domain DMARC adoption varies enormously by jurisdiction: some states have proactively mandated DMARC for all state agencies; others have no state-wide policy and individual agency configurations vary from p=reject to no DMARC record at all. The phishing risk from a state agency domain with no DMARC is equivalent to the risk from any commercial domain — and state government domains are impersonated in phishing campaigns targeting state residents specifically.
The Infrastructure Reality: Legacy Systems and Modern Requirements
The single largest obstacle to DMARC enforcement at government agencies is the complexity of the sending infrastructure. A typical large government agency sends email from 15-30 different systems: the primary Microsoft 365 or on-premises Exchange deployment for staff email, a constituent-facing notification system for status updates and confirmations, a grants management system, a public health notification platform, a contract management system, several mission-specific applications, and legacy systems that have been sending email for 20 years without ever having their authentication properly configured.
Getting all of these systems to authenticate correctly under a single DMARC policy is genuinely difficult — not because the technical solution is complex, but because the governance problem is. Each system may be managed by a different IT contractor, running on a different procurement cycle, with a different team responsible for DNS updates. A DMARC advance to p=quarantine will reveal every system that is not authenticating correctly. In a commercial organisation, the response is to fix the authentication on each system over 2-4 weeks. In a government agency, the response may involve 3 different contractors receiving change orders, 2 budget cycles, and an IT governance committee review — compressing what should be a 4-week process into a 9-month project.
The practical approach that works in government contexts: start with DMARC aggregate reporting (p=none with rua= configured to a monitored inbox) and maintain it long enough to actually identify every sending source, understand who owns each one, and build the remediation plan before any policy advance. In commercial settings, 30 days of p=none monitoring is often sufficient. In government, 90-180 days of monitoring is more appropriate because the number of systems and the complexity of the ownership and remediation paths is significantly greater. The goal is to reach p=reject eventually — but reaching p=quarantine with confidence that you know what you are quarantining is the more important intermediate milestone.
Constituent Communication: Reaching People Who Distrust Government Email
A 2024 consumer survey found that a significant fraction of US adults routinely ignore or delete email that appears to be from government agencies, because they associate government-themed email primarily with scams. This is a rational response: government agencies are among the most impersonated senders in phishing campaigns, and the volume of fraudulent tax notifications, Social Security Administration scams, and fake benefits letters that reach consumer inboxes has conditioned many recipients to treat all government-sourced email as suspect.
This creates a deliverability paradox: the agencies that most need to reach citizens are sending from domains that citizens have learned to distrust. The technical deliverability work — authentication, DMARC enforcement, ISP reputation management — addresses the machine-level question of whether the email reaches the inbox. The constituent trust question — whether the recipient chooses to engage with the email once it arrives — is a separate problem that DMARC alone does not solve.
BIMI (Brand Indicators for Message Identification) is one tool that addresses both problems simultaneously. BIMI places the agency's verified logo in the email client's inbox display for messages that pass DMARC enforcement. For government agencies, BIMI's verified logo display — the small government seal appearing next to the email in Gmail — provides a visible authentication signal that sophisticated recipients learn to associate with genuine government email versus impersonation. BIMI requires: (1) DMARC at p=quarantine or p=reject, (2) a verified BIMI logo certificate from a Certification Authority (Mark Certificates from DigiCert or Entrust), and (3) a DNS BIMI record pointing to the logo. The implementation complexity is moderate; the constituent trust benefit for government agencies is significant.
SPF Complexity in Government: The Multi-System Problem
SPF records for government agencies are frequently approaching or exceeding the 10-DNS-lookup limit — a consequence of the many sending systems described above, each requiring its own include: directive. An agency that sends through Microsoft 365 (include:_spf.protection.outlook.com), a bulk notification platform (include:spf.notifications.platform.gov), a grants management system (include:spf.grants-system.com), and several legacy application servers (direct IP includes) can easily accumulate 12-15 lookups in a single SPF record — exceeding the limit and causing SPF failures for some sending infrastructure even if all the include: entries are individually correct.
The SPF lookup limit problem has two solutions: SPF flattening (converting nested includes into explicit IP address lists that consume fewer lookups) and SPF record restructuring using subdomains (sending some email streams from sending subdomains with separate, simpler SPF records rather than routing everything through the root domain's SPF). In government contexts, both approaches require changes to DNS records that may be managed by a central IT office and subject to change control processes — the technical solution is straightforward but the governance process to implement it takes time.
# SPF audit for government domains — count lookups before you hit the limit:
import dns.resolver
def count_spf_lookups(domain, depth=0, visited=None):
"""Count the number of DNS lookups required to resolve an SPF record"""
if visited is None:
visited = set()
if domain in visited or depth > 10:
return 0
visited.add(domain)
try:
answers = dns.resolver.resolve(domain, 'TXT')
spf = next((str(r) for r in answers if 'v=spf1' in str(r)), None)
if not spf:
return 0
except Exception:
return 1 # Count the failed lookup
count = 0
for term in spf.split():
if term.startswith('include:') or term.startswith('redirect='):
nested_domain = term.split(':', 1)[1] if ':' in term else term.split('=', 1)[1]
count += 1 # The lookup for this include/redirect
count += count_spf_lookups(nested_domain, depth+1, visited)
elif term in ('a', 'mx', 'ptr') or term.startswith('a:') or term.startswith('mx:'):
count += 1 # a, mx, ptr each consume a lookup
return count
# Check a .gov domain:
domain = "example.gov"
lookups = count_spf_lookups(domain)
print(f"{domain}: {lookups} DNS lookups in SPF resolution")
if lookups > 10:
print(f" WARNING: Exceeds 10-lookup limit — SPF will fail for some sources")
elif lookups > 8:
print(f" CAUTION: Approaching 10-lookup limit — review before adding more")
Inbound Email Security: When Your Own Filters Block Legitimate Mail
Government agencies typically operate aggressive inbound email security — Proofpoint, Mimecast, or Microsoft Defender for Office 365 with strict configurations — that occasionally blocks legitimate email from vendors, partners, and other government agencies. The irony of investing heavily in outbound deliverability while simultaneously operating inbound filters that block wanted email from partners is common in government IT environments.
The most frequent government-specific inbound filtering problem: email from other government agencies in other jurisdictions blocked because the sending agency has not yet achieved full authentication compliance. A state agency sending email from a .gov domain without DMARC enforcement may find that its communications to federal agencies with aggressive security configurations are filtered, because the federal agency's security gateway sees a .gov domain without DMARC enforcement and treats it as higher phishing risk — which is technically correct behaviour, since .gov domains without DMARC are easier to impersonate than .gov domains with p=reject. The fix is DMARC enforcement at the sending agency — which is the same fix as for outbound deliverability. Authentication investment improves both outbound delivery and inbound acceptance from security-conscious receiving organisations simultaneously.
Monitoring .gov Email Deliverability
Government agencies typically do not monitor email deliverability at the level that comparable-scale commercial operations would — the operational culture, the absence of revenue-per-email metrics, and the diffusion of email operations across many contractors and systems all contribute to deliverability monitoring being an afterthought rather than a routine operational practice. The result is that deliverability problems at government agencies are often discovered by constituents who report non-receipt rather than by agency IT operations that would have detected the problem earlier.
The minimum effective monitoring stack for government email: (1) DMARC aggregate report monitoring — configure rua= in the DMARC record to a monitored mailbox and review the reports at least monthly. The reports reveal authentication failures from systems that should not be sending on behalf of the agency domain (potential impersonation or misconfigured systems) and authentication failures from legitimate systems that are not correctly configured. (2) Gmail Postmaster Tools — register the .gov domain at postmaster.google.com and review domain reputation weekly. Many constituents have personal Gmail accounts; a .gov domain with Low reputation at Gmail is failing to reach a significant fraction of its intended recipients without any visible bounce or error at the sending infrastructure level. (3) DMARC XML report parsing — raw DMARC report XML is difficult to read; use dmarcian or EasyDMARC's free tier to visualise the reports in a usable format. This is a free, 15-minute setup that makes the DMARC monitoring data accessible to non-technical programme managers who may be more effective advocates for remediation investment than IT staff working through procurement channels.
When IT Contractors Manage the Email: Accountability Gaps
A significant fraction of government email infrastructure is managed by IT contractors rather than agency staff. This creates an accountability gap in email deliverability that is specific to government operations: the contractor manages the technical configuration; the agency is responsible for the outcomes; the incentive structures do not naturally align around deliverability as an outcome that the contractor is measured on.
A contractor managing Microsoft 365 for a state agency has typically scoped to "keep the email running" — meaning accounts are functional, messages deliver from agency staff to recipients, and the technical uptime SLA is met. That scope does not automatically include DMARC monitoring, SPF record maintenance, or Gmail Postmaster Tools review. These activities need to be explicitly included in the contract scope and measured in the contractor's performance metrics to reliably occur. Without explicit contractual requirements for authentication maintenance, DMARC reporting review, and deliverability monitoring, these activities fall into the gap between what the contractor is paid to do and what the agency needs to have done.
The procurement language that addresses this gap: include in any email infrastructure services contract explicit requirements for DMARC aggregate report review (monthly), authentication failure reporting to the agency (quarterly), and SPF record audit to verify compliance with the 10-lookup limit (semi-annually). These requirements are not technically demanding — a competent email administrator can perform all three in a few hours per month — but without explicit contract language, they are not performed because they are not measured.
Government email deliverability is ultimately a public service quality problem that happens to require technical solutions. The agencies that invest in authentication, monitoring, and contractor accountability around email infrastructure deliver better constituent service, have fewer phone and in-person contacts from people who "never got" the email, and protect their constituents from phishing impersonation that erodes trust in government communications broadly. The return on the investment is measurable — in reduced support contacts, in constituent satisfaction metrics, and in the absence of the kind of high-profile impersonation incidents that generate news coverage and legislative scrutiny. The case for government email deliverability investment does not need to be made on technical grounds; it makes itself on public service grounds for any agency that honestly accounts for the cost of email delivery failure.