Blog · Dmarc
When Email Gateway Outages Justify Bypassing Inspection: A Risk Framework
Your email gateway is down. The business is asking if mail can be released. Someone in the room is going to make a call -- and nobody has a framework for making it.
This is one of the most uncomfortable operational decisions in email security. Bypass the gateway and you are processing mail without spam scanning, malware detection, DLP, or content inspection. Keep the gateway bypassed too long and you have no way to know what slipped through. Block all mail and the business calls it a crisis.
The answer is not obvious. But the decision-making process can be.
What "gateway inspection" means in this context
"Gateway inspection" covers a range of controls that run on the email boundary: spam classification, malware sandboxing, URL rewriting, DLP rules, attachment detection, and sometimes DKIM/SPF/DMARC authentication validation. When a gateway fails, one or more of these controls stops running.
The risk of bypassing is not uniform. It depends on which controls are offline, for how long, and in what threat environment. The risk of NOT bypassing also varies -- some organizations can absorb a few hours of no email; for others it is a production incident within minutes.
The risk framework: three questions
Before touching any bypass controls, answer three questions. Rate each 1 to 5.
Question 1: How critical is email to current operations?
If email is the primary communication channel for active deals, incident response, or customer-facing operations, the cost of blocking mail is high. If the organization can route to a backup channel for an hour or two, the cost of blocking is lower and bypass is harder to justify.
Question 2: How long is the outage likely to last?
If the gateway will be back in 30 minutes, the bypass window is short and the exposure is limited. If the outage is expected to run four hours or more, the exposure window grows significantly. Longer windows demand stricter compensating controls.
Question 3: What is the current threat environment?
Routine gateway outages in a quiet period are different from outages during active credential-harvesting campaigns or when your domain is visibly being spoofed. If you have threat intelligence suggesting active abuse, the risk of uninspected mail is materially higher.
Add the three scores.
| Score range | Decision |
|---|---|
| Below 8 | Bypass is hard to justify. Explore temporary routing or accept downtime. |
| 8 to 12 | Bypass is defensible with strict conditions. Apply compensating controls and a hard time limit. |
|---|---|
| 13 to 15 | Bypass is justified. Apply compensating controls and monitor closely. |
This is not a bureaucratic scoring exercise. It is a forcing function to make the tradeoffs explicit before you are sitting in a meeting being pressured to "just open it up."
Set the time limit before you bypass
The worst bypass decisions happen when the gateway comes back online and nobody formally closes the bypass. Email keeps flowing without inspection. Nobody notices for hours.
Set a maximum bypass duration as part of the initial decision. If you do not know how long the outage will last, set a one-hour review window. At the one-hour mark, someone has to explicitly re-evaluate. This is not a suggestion. Make it a step in the incident response runbook.
What compensating controls look like
A bypass without compensating controls is not a risk-managed decision. It is a risk-amplifying one.
Minimum compensating controls during a bypass:
- Increase monitoring on mail relay and outbound servers. Unusual internal sending patterns are a warning sign when inbound inspection is offline.
- Consider manual review for executive accounts or high-value mailboxes.
- Notify the incident response team to be on standby for phishing reports.
- Brief the help desk on what to watch for: users reporting suspicious messages they were not expecting.
- If the gateway has a quarantine buffer, do not release it automatically during the bypass window.
The visibility gap and how to close it partially
When the gateway is bypassed, you lose visibility into DMARC, SPF, and DKIM authentication results. You cannot see what the gateway would have flagged. You are flying partially blind.
This is where aggregate DMARC reporting helps. DMARCFlow processes the aggregate reports that come from receiving mail servers -- reports that reflect what receivers observed about your authentication, regardless of what your gateway saw. During a bypass window, you lose your gateway's inspection data but not necessarily your DMARC aggregate data. After the incident, you can review what messages your domain sent during the bypass window and whether any showed authentication anomalies that warrant follow-up.
This does not replace gateway inspection. But it gives you a partial after-action view of what passed through without inspection and whether any authentication signals suggested compromise or spoofing.
When to restore normal operations
Restore normal operations when the gateway is confirmed operational and any quarantine buffer has been reviewed or released. Formal sign-off from the security team should be part of the close-out process, not an afterthought.
If messages were held in the gateway's quarantine during the outage, review them before bulk-releasing. Some may be legitimate messages that should have been delivered. Some may be threats the gateway would have caught.
The real lesson
The goal of this framework is not to make bypass decisions painless. It is to make them visible and systematic before the pressure mounts.
When you have answered the three questions and documented the decision, you have something to point to. You can explain to the business why you made the call you made, and you have a record for the incident review. The questions themselves also function as a communication tool: they force the conversation about risk to happen before the bypass, not during it.
If you are asked to make this decision in a live incident and you do not have a framework, answer those three questions out loud in the room. The act of naming the tradeoffs often clarifies the answer.
FAQ
Does bypassing the gateway affect DMARC reporting?
No. DMARC aggregate reports come from receiving mail servers, not from your gateway. Those reports continue regardless of whether your gateway is inspecting messages. During a bypass window you lose your gateway's inspection logs, but the DMARC reports from receivers still arrive and can be reviewed after the incident to assess what the bypass window may have missed.
What if my compliance requirements mandate continuous email inspection?
Some regulated environments have specific requirements for email monitoring. If you are in one of those environments, consult your compliance team before implementing any bypass. The risk framework above is an operational tool, not a compliance override.
Should I ever permanently disable gateway inspection for specific senders?
No. Permanent bypass of inspection controls for specific senders is a significant risk that should be evaluated through your formal change management process, not during an incident. Temporary bypass during an outage is a documented exception. Permanent configuration changes require a separate review.
How do I know if something bad slipped through during a bypass?
After the incident, review DMARC aggregate reports for the bypass window. Look for messages from your domain that show SPF or DKIM failures, or for sending patterns that are unusual for your normal mail flow. If you have internal sending logs from your mail servers, cross-reference those against the DMARC reports to identify any gaps.