The Intelligence Agency That Chose to Watch

What a Compliance Scanner Would Tell You

Every automated compliance tool on the planet flags cia.gov the same way: DMARC policy not set to reject. Non-compliant with BOD 18-01. Medium or high severity. Red badge. Failed.

And if you stopped there — if you took that at face value and moved on — you would be making the same mistake that most of the security industry makes every day. You would be checking a box without reading the record.

Read the Record

Here is the CIA’s actual DMARC record, pulled from public DNS on March 19, 2026:

Now read it slowly. This is not a misconfiguration. This is a configuration.

• p=quarantine — Spoofed messages are not rejected at the SMTP layer. They are quarantined. The receiving mail server still processes them.
• ruf=mailto:demarcfailures@uce.cia.gov — Forensic failure reports enabled. Every authentication failure generates a detailed report sent directly to CIA. Most organizations disable ruf because of privacy concerns. CIA wants it.
• fo=1 — Generate a forensic report if any authentication mechanism fails. Not just when all fail. Maximum forensic coverage.
• aspf=s; adkim=s — Strict SPF and DKIM alignment. This is harder than the default relaxed mode. More messages will fail alignment. More messages failing alignment means more forensic reports generated.
• pct=100 — Full coverage. No sampling. Every message is evaluated.
• ri=86400 — Aggregate reports every 24 hours. Daily intelligence feed.

The strictest possible alignment settings. Forensic reports on any failure. Full coverage. And then — quarantine instead of reject.

This configuration maximizes the telemetry about who is attempting to spoof cia.gov.

They Are Not Alone

We surveyed DMARC records across 13 federal agencies and intelligence organizations. Here is what we found:

Of the 13 agencies surveyed, two are at quarantine. Both are intelligence collection organizations. Every other agency in our sample — including agencies with their own intelligence mandates (NSA, DIA, NGA, NRO) — has moved to reject.

The NSA is particularly instructive: they enforce and collect. p=reject with ruf= and fo=1. Their dual mandate (SIGINT collection and cyber defense via CSS/CNMF) is reflected in a configuration that rejects spoofed mail but still harvests forensic intelligence about the attempts. But the CIA and ODNI chose differently.

The Operational Security Perspective

We are not inside the CIA. We cannot confirm intent. What we can do is read public DNS records and observe what the configuration does.

Here is what p=quarantine does that p=reject does not:

• With p=reject, the receiving mail server drops the message at the SMTP level. The message is never processed. Some receiving servers may not generate forensic reports for rejected messages — the transaction ends before the data that populates a forensic report is fully available.
• With p=quarantine, the receiving mail server accepts the message, processes it, and moves it to quarantine (spam/junk). The message is processed far enough for the receiver to generate a detailed forensic report including headers, alignment results, and authentication outcomes.

If your core mission is to understand who is attempting to impersonate your domain, what infrastructure they are using, and how their operations evolve — quarantine preserves that visibility. Reject can reduce it.

Combine this with strict alignment (aspf=s; adkim=s), which is harder than the default and causes more messages to fail alignment, and fo=1, which generates forensic reports on any single mechanism failure, and the result is a configuration optimized for maximum forensic intelligence collection.

The SPF Question

CIA’s SPF record is v=spf1 mx -all — the tightest possible configuration. Only their own mail servers are authorized; everything else is a hard fail. A reasonable question arises: RFC 7489 notes that -all can cause some receiving servers to reject messages during the SMTP transaction, before DKIM is evaluated and before DMARC can assess the result. If CIA depends on DMARC forensic reports, does -all break that?

In practice, no. DMARC forensic reports are generated by receiving mail servers — Gmail, Microsoft 365, Yahoo, and other major providers that handle the vast majority of global email. These modern implementations evaluate DMARC fully (including DKIM) before making a disposition decision, regardless of the SPF result. The receivers that might reject prematurely on -all are typically older or custom SMTP implementations that would not generate DMARC forensic reports in any case.

The result: mx -all combined with p=quarantine and strict alignment creates a layered posture. SPF provides the tightest possible sender authorization. DMARC provides the monitoring layer that captures forensic intelligence about authentication failures. The two mechanisms complement rather than conflict — the -all hardens the perimeter while quarantine preserves the visibility window with the receivers that matter.

The Legal Context

BOD 18-01 applies to federal executive branch agencies. The CIA operates under unique presidential authorities established by the National Security Act of 1947 and Executive Order 12333. Whether BOD 18-01 applies to the CIA in the same way it applies to other executive agencies is a question of legal authority, not technical compliance. The CIA reports directly to the President and has operational authorities that other agencies do not.

ODNI, as the coordinator of the entire Intelligence Community, occupies a similar position of authority over intelligence operations.

How I Got Here

The Lesson for Every Domain Owner

We are not suggesting that you weaken your DMARC policy. For the vast majority of domains, p=reject is the correct posture. It protects your brand, your users, and your reputation.

What we are suggesting is this:

1. Read the record, not just the badge. A compliance scanner that says “FAIL” is giving you a data point, not a conclusion. The conclusion requires context.
2. Understand the tradeoff. Enforcement protects. Monitoring reveals. Both have value. The question is which serves your mission.
3. Understand the forensic reporting landscape. The ruf= tag requests forensic failure reports, and the agencies that are serious about understanding their threat landscape enable it. However, RFC 7489 §7.3 warns that forensic reports can expose PII, and major consumer mailbox providers — Google, Microsoft, and Yahoo — do not honor ruf= requests. The DMARCbis draft has formally removed ruf= from the specification. For the CIA, this limitation may matter less: intelligence agencies communicate with government, military, and contractor mail systems that do generate forensic reports — and those are exactly the senders they want telemetry about. The lesson is contextual: ruf= is not universally effective, but it is not universally dead either. Its value depends on who sends mail to your domain.
4. Strict alignment is underused. aspf=s; adkim=s is harder to configure correctly, but it eliminates ambiguity. If the agencies that handle classified information use strict alignment, it is worth your consideration.

Why This Matters for DNS Tool

This investigation is why we built the ICSAE — Intelligence Compliance and Standards Assessment Engine. A rigid compliance checker would flag CIA as “failed” and move on. Our engine is designed to report both axes:

• Normative result: Does the record meet the stated standard? (In this case: no, per BOD 18-01.)
• Contextual interpretation: Is there evidence that the configuration is deliberate? (In this case: the combination of strict alignment, forensic reporting, and full-coverage monitoring is consistent with a telemetry-optimized posture.)

Both answers are true simultaneously. The record does not meet BOD 18-01 requirements. And the record is configured in a way that is consistent with deliberate intelligence collection. These are not contradictory statements — they are two dimensions of the same observation.

That is what intelligence analysis looks like. Not a checkbox. A calibrated assessment with cited evidence and stated confidence.

Verify It Yourself

Every observation in this case study is derived from public DNS records. You can reproduce every finding with standard tools:

DNS records are public by design. The Domain Name System is an open, distributed, queryable database. That is not an accident. It is the architecture.