Email Traffic

Email Traffic is the investigation screen that gathers the entire inbound and outbound email flow passing through DeepFilter into a single chronological list. The Quarantine screen shows only the emails that were stopped; Email Traffic records the whole flow, delivered messages included. This is therefore where you find the answer to questions such as "did an email from this sender arrive", "was the email with this subject delivered to the recipient or moved to quarantine", and "what reached a particular recipient over the last few days".

Each row in the list represents the journey of one email to a single recipient: when it was processed, who sent it and to whom, the threat score it received, and what finally happened to it. If an email was sent to several recipients, or delivery was attempted more than once, the same email may appear as several rows in the list (see Things to Watch Out For).

Filters that narrow the flow sit at the top, and below them is the chronological traffic list where each row is one recipient.

Action Results

The Action column summarises with a single badge what happened to each email at the end of the flow. It is the most consulted piece of information on the screen: it is where you see whether an email was delivered, whether it was stopped, or whether it is stuck along the way. When an email matches more than one condition, the highest-priority result is shown; the order is as follows:

• Quarantine (yellow) — The email was found risky, stopped and not delivered to the recipient. It can be examined and released from the Quarantine screen. In the example, fraud emails such as "URGENT: You won 1000000 USD" landed here with a score of 13.40.
• Unverified Recipient (red) — Because the recipient has no account on the delivery server, the email was rejected at the SMTP stage without ever entering content scanning; the sender receives a response saying the recipient could not be found. This result occurs only in inbound traffic and only while Recipient Verification is enabled for the delivery server (see Inbound Email → SMTP Flow). It belongs to the same red family as Rejected; the distinction is in the badge text. On these rows the Subject column shows a plain explanation — that the recipient could not be found on the delivery server — and you see the raw rejection text returned by the server by opening the row and looking at the detail panel.
• Rejected (red) — The email was permanently rejected at the connection stage; it was turned away without even entering content scanning. The sender receives a "not accepted" response.
• Soft Rejected (orange) — The email was temporarily rejected without being accepted (greylisting, which holds new senders back for a short while, or a rate limit). The sending system is expected to try again after a while: legitimate servers retry and the email goes through, while much of the spam infrastructure does not retry and is eliminated.
• Deferred (yellow) — DeepFilter accepted the email but could not deliver it to the destination mail server at that moment and placed it in its own retry queue. Delivery is pending on the DeepFilter side and is retried automatically a short while later.
• Bounced (red) — Delivery failed permanently; the email could not reach its destination and was returned to the sender.
• Clean (green) — The email passed through the clean flow and was delivered to the recipient. It was not stopped because its score stayed below the threshold. In the example, the "Ödenmemiş fatura" (unpaid invoice) email with a score of 5.40 was delivered this way.
• Recalled (grey) — The email was delivered to the recipient but was later recalled from the user's mailbox (see Recalling a Delivered Email). Although delivery succeeded, the copy is no longer in the mailbox, so this neutral badge is shown instead of the green Clean badge; hovering over it reveals the recall mode, the administrator who performed the recall and the date. If the recall is still in progress the badge does not change and a Recalling… note appears beneath it; if the attempt produced no result, a Recall failed or Read, skipped note is shown.
• Removed from Queue (grey) — The email could not be delivered and, while it was waiting in DeepFilter's delivery queue, it was removed from the queue and will never be delivered. The deletion may have been performed by an administrator from the panel or manually on the server. Previously such emails left the queue without producing a delivery record, so they stayed Pending in the list forever and were misleading; with this separate, definitive result it is now clear that the email was deleted. Which administrator performed the deletion is visible by opening the row and looking at the Deleted by information in the detail panel (see Row Detail).
• Pending (grey) — The email was processed, but its final delivery status has not yet been matched with the records. Once matching completes, the badge turns into the actual result (Clean, Deferred, Bounced or Removed from Queue).

Deferred and Soft Rejected are different

Both say "the email has not been delivered yet", but the retry sits on a different side. With Deferred, the email has already been accepted by DeepFilter; DeepFilter performs the retry — the work is progressing on your side. With Soft Rejected, the email was never accepted; the sending system performs the retry — the ball is in the other party's court. Look at this difference to tell whether an email is really lost or merely waiting.

Score

The Score column is the total threat score the scanning engine gives each email. The higher the score, the more likely the email is unwanted or malicious: a low score indicates the clean flow, a high score indicates risk. The colour of the badge splits the score into three bands so you can read the list quickly:

• Green — below 6: The clean range. Scores such as 0.15, 3.65 and 5.40 on the screen are in this band.
• Yellow — between 6 and 15: The caution/suspicious range. The 13.40 on the screen is in this band.
• Red — 15 and above: High risk; a strong indicator of a threat.

The colour is only there to help you read the score quickly; whether an email was actually stopped is told by the Action column. Read the score together with the action: a high score usually leads to Quarantine, while a score below the threshold leads to Clean. You see in the greatest detail why an email received that score by opening the row and looking at the Symbols section (see Row Detail).

Filters and Search

By default the list shows the inbound flow of the last 7 days. The bar at the top lets you narrow that flow down to the slice you want to examine.

Incoming / Outgoing — Splits the flow by direction. Incoming covers emails reaching recipients in your organisation from outside; Outgoing covers those sent to the outside from your organisation. The direction is calculated automatically from your defined domains. The two directions serve different purposes: on the incoming side you examine the threats aimed at you, and on the outgoing side you monitor the sending behaviour and reputation of your own users.

Date — Narrows the list to a time range. The options are: Today, Last 7 days (default), Last 14 days, Last 30 days, All and Custom range. The range is calculated by the Istanbul calendar day. If the email you are looking for is not in the list, the first thing to try is widening the date range.

Custom range is for investigations that the ready-made periods do not cover: you define a period yourself, such as a particular week of last month or the two days on which an incident occurred. When you select Custom range from the Date menu, Start and End fields open below the menu; both days are included in the range. The list refreshes only with Apply; no query runs while you are filling in the fields. Once applied, the range you selected is readable on the Date button. The start cannot be later than the end and a future day cannot be selected; when you make an invalid entry, a short explanation of the reason appears below the fields and Apply stays disabled. Clear drops the custom range and returns to the last ready-made period you used.

Action — Filters the list by result, and its options change with the direction.

In the incoming direction there are six options: All actions (default), Clean, Quarantine, Soft Rejected, Unverified Recipient and Recalled. For example, you select Quarantine to see only the emails that were stopped, Unverified Recipient to see recipients with no counterpart on the delivery server, and Recalled to see emails taken back from mailboxes. Unverified Recipient and Recalled are specific to incoming traffic only.

In the outgoing direction the same menu offers delivery statuses: All actions (default), Clean, Deferred, Bounced, Removed from Queue, Quarantine and Soft Rejected. The first four distinguish what became of the email on the far server; they let you list, with a single selection, whether an email your users sent reached its destination, is waiting in the queue, or came back. These four options are specific to outgoing traffic only, and the result they select is exactly the same as the badge in the list.

When you change direction, a selection that is not valid in that direction is not kept; the filter returns to All actions.

Clean says something different in each direction

In the incoming direction, Clean means scanning found the email clean and let it through the flow. In the outgoing direction the same option filters the result of delivery: the email was accepted by the far server. For an email leaving the organisation, "clean" means the other side accepted it, not that scanning found it clean.

Some badges cannot be selected in the filter

Pending and Rejected do not appear in the Action filter in either direction; they show up as badges in the list but cannot be filtered on. Pending is deliberately left out: rows whose delivery record has not been matched yet do not form a single set, and the filter result would not agree with the badges in the list. Deferred, Bounced and Removed from Queue can be filtered only in the Outgoing direction; in incoming traffic these badges appear in the list but cannot be selected in the filter. When looking for a result you cannot select, narrow the list by date and direction and scan the badges.

Search — Searches text in the sender, recipient, subject and attachment name fields; if the text you type occurs in any one of these fields, the row is listed. The search is not instant: after typing the text you must press Enter or click the Search button. This is to avoid creating unnecessary load on large traffic records. The counter at the top right (for example 484 recipients) shows the number of rows currently listed.

Recipient matching works at the row level. If the text you are looking for occurs only in the recipient address, the rows belonging to the other recipients of a multi-recipient email do not enter the list; only the matching recipient appears, and the counter counts those rows. This way, when you search for a person's address the list really shows the emails that reached that person. If the text also occurs in the sender, the subject or the attachment name, the match is on the email itself and all recipient rows of that email are listed. This behaviour applies in both the Incoming and the Outgoing direction.

When the filter, the search, the direction or the date changes, or when an advanced condition is applied, the list returns to the first page and any row detail open at that moment closes.

Advanced Search

The search box searches a single piece of text across several fields at once, but it does not let you choose which field to match on and it applies only one criterion at a time. Advanced search removes that limit: you choose the field, the comparison and the value, and you apply several conditions together. The Advanced filter button on the filter bar opens the condition panel; the number on the button shows how many conditions are currently applied. Advanced search can be used in both the Incoming and the Outgoing direction.

Advanced search does not replace the existing filters, it is added on top of them: the direction, the date, the Action filter, the text in the search box and the conditions you have built must all be satisfied at the same time. When you cannot find an email, review all of these layers first.

Fields you can build conditions on

Each condition consists of a field, an operator and a value. The type of the field determines which operators can be selected:

• Text fields — Sender, Recipient, Subject, IP address and Attachment name. Operators: contains, does not contain, equals, starts with, ends with. The comparison is case-insensitive and matches Turkish characters correctly; a subject written "ÖDEME" is found by a search for "ödeme".
• Score — A numeric field. Operators: ≥, ≤, = and between (a range using the Min and Max boxes). If you fill in only one end of the range, the condition works with that single end.
• Category — The threat type that flagged the email: Antivirus scan (ClamAV), Phishing detection, RBL / IP reputation, SPF check, DKIM check, RDNS / HELO check, Spam Analysis (AI / Bayes / Neural), Content detection (DLP), Blocked Sender and Restricted Sender. Operators: equals, not equals.
• AI — The artificial intelligence verdict: AI Trusted (HAM), AI Spam or AI Not Evaluated. Operators: equals, not equals.

Category matching looks for a contribution to the score

An email enters a category when a rule in that category actually raised its score. Rules that fired but contributed nothing to the score (working in the clean direction or neutral) do not count towards the category. That is why the condition "Category = Spam Analysis (AI / Bayes / Neural)" does not return the emails the artificial intelligence found clean; to find those, use the condition AI = AI Trusted (HAM).

Combining conditions

• Add condition opens a new row; each row is an independent condition. You can use the same field in more than one condition (for example Subject contains "invoice" and Subject does not contain "cancelled").
• The Match selection determines how the conditions are combined: All conditions (AND) — the default — requires all of them to be satisfied, while Any of them (OR) requires at least one to be satisfied.
• Conditions are not applied instantly: you edit them freely in the panel and run them by clicking the Apply button or pressing Enter. A row whose value is left empty is not applied, so a half-finished condition does not narrow the list.
• Applied conditions remain above the list as chips. When you remove a chip the list refreshes immediately; Clear all removes every condition. The chips stay visible even when the panel is closed, so you never lose sight of why the list has narrowed.
• The Recipient condition works at the row level: on a multi-recipient email only the row of the recipient matching the condition is listed, and the counter counts those rows.

Attachment name search

The attachment name comes from the names of the files attached to the email during scanning and is populated in historical records too — the condition works retrospectively, on the traffic of previous days as well. This field is how you determine which recipients a campaign reached, or who in the organisation was sent a particular file name.

The most frequently used form is a search by extension: the condition Attachment name — ends with — .iso lists every attachment carrying that extension. Use equals when you need the exact name, and contains when you are looking for part of a name.

File names inside archives are out of scope

The name searched is the name of the file attached directly to the email. File names inside a compressed archive (a .zip, for example) are not searched by this condition; the archive's own name is what is searched.

Some rows leave the list when a condition is applied

Rejected and Unverified Recipient records never entered content scanning, so they carry no score, rule or attachment information. For this reason, the moment a condition is applied to the incoming list these rows leave it and a warning stating this appears on the screen. For the same reason, if you apply a condition while the Action filter is set to Unverified Recipient, the list stays empty. To see these records, clear the conditions and use the search box and the Action filter.

Row Detail

When you click any row in the list, the full record of that email opens. This panel gives the detail behind the one-line summary and is used to examine why an email received the score it did or where its delivery got stuck.

The panel consists of three sections:

• General Info — Sender, recipient, the date to the second, the sender's IP address, the score, the action, the size of the email and the subject.
• Delivery Info — Whether the email reached its destination: the delivery status (Delivered / Deferred / Bounced / Removed from Queue — successful delivery reads "Delivered" here, expressing the same positive result as "Clean" in the main list), the server it was delivered to, the response code and the message returned by the far server. If the email was deleted from the delivery queue, the delivery status becomes Removed from Queue; if an administrator performed the deletion from the panel, the Deleted by line shows that administrator's name or email address, and if the account that performed it has since been removed, it reads Deleted user. If the deletion was performed manually on the server, no record of the person is kept and the Deleted by line does not appear. This section also holds the Delay information: how long it took for the email to be processed and delivered (in seconds below 60 seconds, in minutes above it). Delay exists only in this panel; there is no Delay column in the main table.
• Symbols — The breakdown of how the score was formed: every rule the scanning engine detected in the email and that rule's contribution to the score. The artificial intelligence verdict (clean/suspicious), whitelist matches and rate limit information appear here. If a sender hit a rate limit, this section also shows how many emails they attempted in the last hour. This is where you see most precisely why an email received a high or a low score.

If the email was recalled from the mailbox, the panel also contains a Recall block: the status of the item, the mode, the administrator who performed the recall and the date. The View job link there takes you to the job record showing all items of the recall (see Monitor → Recall); the Recall this subject as a campaign link opens the campaign flow prefilled with this email's details, so you can gather the remaining copies of the same wave into a single job.

Finding What Happened to a Specific Email

Prerequisites

• Make sure the date the email was sent falls within the selected date range; if not, widen the Date filter first.

Steps

1. Open the Email Traffic screen.
2. Select the relevant direction with the Incoming / Outgoing button, according to whether the email you are looking for is incoming or outgoing.
3. Type the sender address, the recipient or a word from the subject into the search box (for example "invoice").
4. Press Enter or click the Search button.
5. Look at the Score and Action columns on the resulting row; for detail, click the row to open the detail panel.

Verification — how to know it worked

• The list shows only the matching records and the counter at the top right updates to the number of results. When you click a row, the Delivery Info and Symbols sections come up populated.

Filtering by Result

For example, to list all emails quarantined in the last month:

Steps

1. Open the Email Traffic screen.
2. Select the period from the Date filter (for example Last 30 days). If the ready-made periods do not cover the time range you are examining, select Custom range, enter the start and end days, and click Apply.
3. Select the result you want to see from the Action filter (for example Quarantine).
4. If needed, change the direction with Incoming / Outgoing and repeat the same examination for the other flow; in the outgoing direction the Action filter offers delivery statuses.

Verification — how to know it worked

• The list shows only the emails matching the result you selected and the counter updates accordingly.

The same path is also used to track delivery of outgoing traffic: switching to Outgoing and selecting Deferred in the Action filter shows the messages waiting in DeepFilter's queue, selecting Bounced shows the emails the far side permanently turned away, and selecting Removed from Queue shows those taken out of the queue without being delivered — each in a single list. To examine one user's sending, combine this with the search box: type their address, press Enter, and only that person's emails in the relevant state remain.

Finding Emails Carrying a Specific Attachment

This is the path to follow when a malicious attachment is reported, or when you need to work out how many people in the organisation received the same file.

Prerequisites

• Make sure the date the email was processed falls within the selected date range; if you are not sure, set the Date filter to All.
• Know the name of the file you are looking for (or a distinctive part of the name, or its extension).

Steps

1. Open the Email Traffic screen and select the relevant direction with the Incoming / Outgoing button.
2. Click the Advanced filter button on the filter bar to open the condition panel.
3. Select Attachment name from the field list, choose equals as the operator if you know the exact name, contains if you are looking for part of the name, or ends with if you are searching by extension, and type the value (for example fatura_2026.xlsm or .iso).
4. If you want to narrow the search, enter a second condition with Add condition (for example Score — ≥ — 10) and leave Match on All conditions (AND).
5. Click the Apply button or press Enter.
6. Click the listed rows to examine the sender, the recipient and the Symbols breakdown.

Verification — how to know it worked

• The conditions you built appear as chips above the list, the Advanced filter button shows the number of conditions, and the counter at the top right updates to the number of matching rows.
• If the result is empty, loosen the condition: try contains instead of equals, widen the date range and check the other direction too.

Other investigations are set up the same way: for high-scoring emails from a sender domain, Sender — ends with — @ornek.com and Score — ≥ — 10; for phishing attempts from a single IP address, IP address — equals and Category — equals — Phishing detection.

Recalling a Delivered Email

The filter makes its decision as the email passes through; a phishing email that got past the filter is usually identified after delivery. Recall is the way to take that email out of users' mailboxes, and it is started from this screen: you select the rows you are interested in, examine the preview, and deletion begins only after your approval.

The scope is narrow: only incoming emails that were actually delivered can be recalled. An email that was quarantined, rejected or soft rejected never entered a mailbox; there is no copy to recall. In addition, the server the recipient was delivered on must have a Zimbra profile; the row of a recipient on a server without a profile cannot be selected.

The message in the mailbox is matched on four criteria: subject, delivery time, size and, when known, the header sender domain. The size comparison is tolerant so that messages enlarged by headers added during delivery are not eliminated; sender verification is done with the header domain only, and the envelope sender does not enter the comparison (the two differ for messages arriving through bulk email services). If more than one candidate is found for an item, that item is not recalled unless you explicitly tick it in the preview; if no candidate remains, the Error column in the preview states which criterion eliminated it.

Prerequisites

• You must be signed in with the full-access administrator role; domain administrators cannot perform a recall.
• The Zimbra connection and the recall feature must be enabled (see Management → Integration → Zimbra SOAP). If they are disabled, the row selection boxes do not appear at all.
• The servers the recipients were delivered on must have a defined and active Zimbra profile; rows on servers without a profile cannot be selected.
• The emails to be recalled must be listed on this screen; widen the Date filter first if necessary.

Steps

1. Open the Email Traffic screen and select the Incoming direction with the Incoming / Outgoing button.
2. Tick the checkboxes at the start of the rows you want to recall. Rows that cannot be selected are the ones not eligible for recall (emails that were not delivered, were quarantined, or have already been recalled). Rows whose box is struck through and which show the hint "The recipient's destination server has no Zimbra profile" do have a copy, but that delivery server is missing its Zimbra profile; once the profile is defined, the row becomes selectable.
3. Click the Recall button that appears on the top bar. If the same email reached a large number of recipients, you can proceed in a single job with Recall as campaign by giving the subject, sender and time window instead of selecting rows one by one.
4. Wait for the Preview step in the window that opens. In this step the mailboxes are scanned — which message is where and who opened it — and nothing is deleted.
5. Review the item table: untick the items you do not want recalled and consider the items labelled Confirmation required.
6. Click the Approve recall button. If the mode is Delete permanently, the button is two-stage; the first press shows the warning and the second press starts the operation.

Verification — how to know it worked

• The window moves to the Running step and shows the number of items processed; when the job finishes it reads Completed. When you refresh the list, the Action column of the recalled rows turns into the Recalled badge. All items of the job (who had opened it, which item failed) are recorded on the Monitor → Recall screen.

caution

Recall deletes email from users' mailboxes, and the job you start on this screen cannot be undone. In Move to trash mode the user can retrieve the message from the trash; in Delete permanently mode the message cannot be recovered, and even if the job is cancelled midway, what has been deleted up to that point does not come back. Review the item list before approving; if you are unsure about the scope, export the list as CSV and examine it.

note

Closing the window does not cancel the job. A job whose preview is running or which is awaiting approval stays on the Monitor → Recall screen; its approval, cancellation and progress can be managed from there as well. Jobs that are not approved cancel themselves after 24 hours.

Things to Watch Out For

Why the same email appears on multiple rows

An email creates more than one row in the list in two situations:

• Multi-recipient email: When an email is sent to several recipients, a separate row is written for each recipient (same sender, subject and score; different recipient). This lets you follow the fate of each recipient individually. When you search for a recipient address, or build a Recipient condition in advanced search, only the row of the matching recipient is listed; the rows of the other recipients do not enter the list.
• Retries: An email that receives a Soft Rejected result is retried again and again by the sender, and each attempt is rescanned and recorded as a separate row. A single email can produce hundreds of rows. These rows are deliberately not deleted; all attempts are kept for investigation (forensic trail) purposes.

Why the counter and the Dashboard numbers differ

The counter at the top right (N recipients) shows the number of rows (recipients) listed, not the number of unique emails. Because of the retries and multi-recipient emails described above, this number can be higher than the message count on the Dashboard. The Dashboard counts each email as one message and does not add retries to that number; Email Traffic, on the other hand, shows the raw record as it is, with a separate row for each recipient and each attempt. The two screens giving different numbers is therefore expected, not an error.

Troubleshooting

• An email stays "Pending" for a long time. Pending means the delivery record of the email has not been matched with the flow record yet. In most cases the matching completes shortly; refresh the list. If it stays Pending permanently, either no delivery record was ever created for the email (for example an email with missing identity information) or there is a delay in processing the delivery records. Click the row and check whether the Delivery Info is empty.
• The email I am looking for does not appear in the list. There are three common reasons: because the search is not instant, you may not have pressed Enter after typing the text; the email is outside the selected date range; or an advanced condition left over from an earlier investigation is still applied. First check whether there is a condition chip above the list and use Clear all if needed; then run the search with Enter; if there is still no result, set the Date filter to All and make sure you are looking in the correct direction (Incoming/Outgoing).
• I searched for a recipient address and the email's other recipients are not in the list. This is intentional: when the search text matches only in the recipient field, the list shows only the row of the matching recipient. To see all recipients of the email, type a word from the subject or the sender address into the search box; all recipient rows of the same email are then listed.
• The same email repeats dozens of times. This is not an error; every retry attempt of an email that received a Soft Rejected result is recorded as a separate row (see Why the same email appears on multiple rows). To see that the repeats come from the same sender and subject, you can click the rows and compare the details.