When Should a SOC Block at DNS vs Email Gateway vs Proxy?

When a threat indicator lands in your queue, one of the first decisions you face is where to block it. Choosing the wrong layer does not stop the threat. It just creates a false sense of control.

Most SOC teams default to "block it everywhere" when they are not sure. That approach sounds safe, but it generates policy debt, alert fatigue, and log noise. Worse, it sometimes breaks legitimate services. The DNS layer, email gateway, and forward proxy each intercept threats at different points in an attack chain. Each one has blind spots the others do not share. Knowing which layer owns which threat type is a core operational skill.

This runbook maps threat types to blocking layers, explains the decision criteria for each, and gives you a checklist to follow during triage.

TL;DR: Quick Blocking Layer Decision Table

The Blocking Layer Problem SOC Teams Face

The DNS layer, email gateway, and forward proxy are three distinct network security layers, but they operate at different stages of an attack. A threat blocked at DNS never reaches a user. A threat blocked at the email gateway never gets opened. A threat blocked at the proxy is already in an active session.

That sequence matters because each layer's timing determines both its effectiveness and its side effects. Block too early and you may act on incomplete intelligence. Block too late and the session is already established. Block at the wrong layer and the threat takes a different path you did not cover.

The three layers also have fundamentally different observability. DNS gives you resolution telemetry across every protocol. Email gateways give you content-level inspection before delivery. Proxies give you full HTTP/S session visibility, including the payload. Choosing the right layer is partly about stopping the threat and partly about placing your detection surface where it does the most work.

When to Block at the DNS Layer

What the DNS Layer Actually Stops

A DNS block prevents a domain from resolving. The endpoint never establishes a connection to the destination. This happens before any protocol handshake, before any payload is requested, and before any session is logged on the destination server.

That makes it the fastest and most transparent block available. There is nothing to decrypt, no session to terminate, no content to inspect. The resolver returns NXDOMAIN, and the request stops.

What it cannot stop: anything that bypasses the DNS resolver entirely. Direct IP connections, hardcoded IP addresses in malware, and DNS-over-HTTPS (DoH) traffic routing to a third-party resolver all evade DNS filtering. Motivated actors routinely probe these bypass paths once a blocking posture is in place.

Threat Types That Belong at DNS

Command-and-control (C2) domains are the primary use case. When a host is calling home to a C2 domain, blocking at DNS cuts the communication channel at the earliest possible point. The endpoint cannot receive commands. Exfiltration over that channel stops. This is especially effective against C2 traffic that rotates domains frequently, as long as your DNS blocking feeds are updated in near-real time.

Domain generation algorithm (DGA) domains are another strong fit. DGA malware generates hundreds of candidate domains per day, only a few of which are actually registered and controlled. DNS blocking tied to DGA detection models can sinkhole these before the malware finds an active C2 node.

Newly registered domains used in phishing infrastructure belong here too. Threat actors frequently register domains days or hours before a campaign. Blocking domains under 7 days old at DNS is a blunt but effective heuristic for environments willing to accept occasional false positives on legitimate new domains, as the exact threshold varies by organization risk tolerance, but sub-7-day registration is a widely used starting point. The NSA and CISA jointly recommend protective DNS filtering as a foundational control precisely because it operates before any other layer sees the traffic.

DNS tunneling is detected and blocked at the resolver level by inspecting query characteristics: unusually long subdomains, high query entropy, abnormal record type distribution, and excessive query rates to a single parent domain.

Decision Criteria: Use the DNS Layer When

• The threat is domain-based and identified before a session starts
• You have a confirmed malicious domain from a threat intelligence feed
• The malware is calling out to C2 infrastructure
• You want to log all resolution attempts for forensic analysis regardless of whether you block

DNS Layer Blind Spots

• Direct IP connections (no DNS query issued)
• DoH traffic to external resolvers like 8.8.8.8 or 1.1.1.1
• IPv6 AAAA lookups if your DNS blocking only covers A records

When to Block at the Email Gateway

What the Email Gateway Actually Stops

The email security gateway inspects inbound messages before they reach the recipient's inbox. It sees the envelope, the headers, the body, and the attachments. It can evaluate sender reputation, scan URLs at click time, detonate attachments in a sandbox, and strip malicious content before delivery.

This inspection window is where phishing campaigns are most vulnerable. The attacker needs the user to receive and interact with the message. The gateway is the last automated control between the attacker's infrastructure and the user.

Threat Types That Belong at the Email Gateway

Phishing is the primary use case. Whether the attack delivers a malicious link, a credential harvesting page, or a payload attachment, the email gateway is the correct first layer. The gateway can match sender patterns, check DMARC alignment, evaluate the URL against reputation databases, and sandbox attachments before any of that content touches a user's machine.

Business email compromise (BEC) is detected here through header analysis and sender impersonation rules. BEC has no malicious payload or link to block at DNS or proxy level. The email gateway is the only automated layer that sees the attack at all.

Malicious Office documents and weaponized PDFs are detonated in sandbox environments by modern gateways. No DNS query is issued until the document executes. Waiting for DNS activity means the document already ran.

Credential harvesting links embedded in HTML emails are a strong email gateway use case, particularly with time-of-click URL rewriting. When the user clicks, the gateway evaluates the URL in real time against updated threat data.

Decision Criteria: Use the Email Gateway When

• The threat vector is inbound email
• The indicator is a sender address, email header pattern, or attachment hash
• The attack involves no malicious infrastructure that DNS can preemptively block
• BEC or social engineering is suspected

Email Gateway Blind Spots

• Outbound C2 over SMTP (some gateways do not inspect egress as thoroughly)
• Threats delivered through encrypted email services or end-to-end encrypted attachments
• Internal relay abuse between compromised mailboxes (internal-to-internal traffic)
• Threats delivered through OAuth-connected third-party apps rather than email

When to Block at the Proxy

What the Proxy Actually Stops

The proxy intercepts HTTP and HTTPS traffic once a session is already in progress. It has already seen the DNS resolution succeed and the TCP connection establish. At this point, it is inspecting the actual request and response content.

This is your last automated inline control before a payload reaches an endpoint. The proxy can inspect URL categories, block specific file types from being downloaded, TLS interception to inspect encrypted content, and compare downloaded content against reputation and hash databases.

Threat Types That Belong at the Proxy

Payload delivery via HTTP/S is the primary use case. Drive-by downloads, malware distribution networks, and staged loader payloads delivered over web sessions are best stopped at the proxy. The proxy can block the download based on the URL, the file type, the content hash, or the destination domain category.

Data exfiltration over HTTP/S is visible at the proxy but not at DNS or the email gateway. If a compromised host is beaconing over HTTPS to a cloud storage service or C2 over HTTP long-polling, proxy traffic analysis surfaces this when the DNS layer cannot.

Malvertising is nearly impossible to stop at DNS without blocking entire advertising networks. The proxy can evaluate the actual content being served at click time and terminate the session before the malicious redirect executes.

Decision Criteria: Use the Proxy When

• The threat is in an active HTTP/S session
• DNS did not block the initial resolution (domain was unknown or used direct IP)
• You need content-level inspection rather than domain-level blocking
• Payload delivery is the specific threat you are containing

Proxy Blind Spots

• Non-HTTP protocols (SSH tunneling, SMTP, IRC-based C2, custom binary protocols)
• Direct IP connections over non-standard ports not routed through the proxy
• Bypasses via split tunneling in VPN configurations
• Applications with certificate pinning that reject proxy-inserted TLS certificates

The Decision Table

Apply this during triage. The primary column assumes your default tool is available. The fallback column applies when the primary layer cannot execute the block.

When to Apply All Three Simultaneously

Multi-layer blocking is warranted in three situations: when you have confirmed C2 infrastructure where the campaign is active across multiple delivery vectors; when a ransomware distribution campaign is in progress and the attacker is using phishing for initial access, C2 via DNS for command channels, and HTTP/S for payload staging; or when threat intelligence confirms a coordinated attack targeting your organization specifically.

Even in these cases, set a time window for multi-layer blocking. Permanent blocks across all three layers accumulate and are rarely reviewed. Most multi-layer blocks should expire within 24-72 hours unless there is an ongoing active threat justifying their extension.

The cost of over-blocking is real. Blocking a legitimate business domain at DNS breaks every application on your network that depends on it. Blocking a shared hosting IP at the proxy disrupts unrelated sites. Email gateway blocks on sending domains can block partner organizations. Every multi-layer block needs an owner and an expiration.

Using Domain Intelligence to Inform the Blocking Decision

Before you block at any layer, you need confidence that your indicator is actually malicious. Blocking on an unverified indicator creates disruption and erodes analyst trust in the blocking process.

Domain intelligence fills this gap. Three checks take under five minutes and meaningfully improve blocking confidence:

Domain age verification. Disposable infrastructure is almost always newly registered. As a general heuristic, a domain created within the last 7 days and associated with a suspicious URL or C2 pattern is a high-confidence block candidate. A domain with a 10-year registration history is more likely to be a compromised legitimate site, which changes how you block it. Use a WHOIS lookup to check registration date before escalating a block.

DNS record history. Fast-flux domains rotate IP addresses every few minutes to evade IP-based blocking. A domain showing IP changes every 5-30 minutes over the past 24 hours in DNS records lookup data is a strong indicator of malicious hosting infrastructure. Static legitimate domains rarely show this pattern.

Registration pattern analysis. Threat actors often register domains in batches from the same registrant email, registrar, or ASN. If one domain is confirmed malicious, checking historical WHOIS lookup data for the registrant contact reveals sibling domains that share the same infrastructure. Blocking the confirmed domain without checking for siblings leaves the rest of the campaign active. Reverse WHOIS search surfaces all domains sharing a registrant, enabling pre-emptive blocking of the broader infrastructure.

Case Study: A Phishing Campaign That Needed Three Layers

The following is a composite scenario based on common SOC response patterns. It illustrates how the decision framework applies when a threat moves across layers during an active incident.

A SOC analyst at a mid-size logistics firm received an alert from the email security gateway: a phishing message had been delivered to 14 mailboxes before the gateway's URL reputation feed updated to flag the sending domain. The gateway blocked retroactively and pulled the messages from inboxes. Standard response, case closed.

Except one user had clicked before the block landed.

Endpoint telemetry showed an outbound connection to a domain the analyst had not seen before. Running a WHOIS lookup on it returned a registration date three days prior. No prior history, a privacy-protected registrant, and a nameserver shared with two other domains registered the same day. All three domains were clean on threat intel feeds at that moment.

The analyst blocked all three at DNS based on registration age and infrastructure pattern, not on a confirmed feed match. Fourteen minutes later, the first domain appeared in a third-party threat feed as a confirmed Cobalt Strike C2 beacon host. The other two domains appeared within six hours.

The proxy logs showed the initial HTTP beacon request had reached the endpoint before the DNS block was applied. Because the DNS block stopped subsequent resolution, the malware could not receive further commands after the first check-in. No lateral movement occurred.

Three things determined the outcome. The email gateway caught the delivery vector. Domain age and nameserver pattern analysis surfaced the C2 infrastructure before it hit any feed. The DNS block stopped command channel communication before the malware could act on its initial beacon.

Had the analyst waited for feed confirmation on the unknown domains, the dwell time would have extended to at least six hours. The checklist in the next section codifies this decision sequence.

SOC Runbook Checklist: Blocking Layer Selection

Work through these steps in order during triage. Stop when you have a confirmed blocking decision.

Step 1: Classify the indicator. Is this a domain, IP address, URL, sender address, or file hash? Domains go to step 2. Sender addresses go to email gateway. File hashes go to EDR. IP addresses skip to step 5.

Step 2: Check domain age. Run a WHOIS lookup on the domain. Under 7 days old (a common heuristic threshold) and associated with a suspicious pattern? Block at DNS. Over 1 year old? Confirm whether this is a compromised legitimate domain before blocking at DNS (a full block would break legitimate traffic too; consider URL-level blocking at the proxy instead).

Step 3: Check DNS record history. Does the domain show rapid IP rotation? Flag as fast-flux. Block at DNS and add the current IP set to firewall deny rules.

Step 4: Identify the threat vector. Was this indicator discovered in an email? If yes, block at the email gateway first. Was it discovered via endpoint telemetry, proxy logs, or network flow data? Block at proxy or DNS depending on whether a session is already active.

Step 5: Is a session currently active? If the endpoint is currently communicating with the destination over HTTP/S, add a block rule at the proxy to drop further requests to that destination. Then block at DNS to prevent the endpoint from reconnecting after the proxy rule takes effect.

Step 6: Check for sibling infrastructure. If the domain is confirmed malicious, run a reverse WHOIS check for related domains. Block preemptively if registrant or nameserver patterns match known malicious actors.

Step 7: Set an expiration on the block. Document who owns the block and when it should be reviewed. Schedule a review at 24 hours for high-noise environments, 7 days for confirmed APT infrastructure.

Building Reliable Blocking Decisions

The decision between DNS, email gateway, and proxy is not a one-time configuration choice. It is a judgment call made on each threat, under time pressure, with incomplete information. The runbook above gives you a structured path through that judgment, but the underlying principle is simpler: block as early in the attack chain as the intelligence allows.

When you have a domain indicator before any session is open, DNS is the right answer. When the threat entered through email before you caught it, the gateway is the right answer. When a session is already in progress, the proxy is where you work. The layers are not interchangeable. Each one sees a different slice of the attack.

The domain intelligence checks in steps 2 and 6 are where most analysts recover time they would otherwise spend second-guessing a block. Registration age distinguishes disposable attack infrastructure from compromised legitimate services. DNS record history separates fast-flux C2 from normal hosting variance. Registrant pattern analysis turns a single confirmed IOC into a map of the broader campaign. Running these three checks before blocking is what keeps your block list accurate rather than accumulating noise.

For SOC teams running SOAR workflows, these checks integrate directly via API. WhoisFreaks API plans provide programmatic access to WHOIS registration data, historical DNS records, and reverse WHOIS lookups, so the domain intelligence step in the runbook runs automatically as part of alert triage rather than as a manual lookup.