Agari’s Sensor is designed to gather metadata from enterprise email traffic to aid analysis and increase visibility. The Sensor is designed to be compatible with Microsoft’s Exchange Online Services under the aegis of Office 365.
Establishing Dual Delivery, where messages destined to the organization’s end-user mailboxes are simultaneously copied to one or more Agari Sensors, provides the sensor with access to email streams. Doing so requires a few simple configuration changes to your O365 configuration. This document describes how to make the necessary changes quickly and safely.
All versions of Office 365 include a feature known as Journaling which can be used to establish Dual Delivery. Note that because O365 is a cloud-based service, the system running your Sensor will need to be accessible from the Internet with a public IP address.
For more information on general architecture of the Sensor, installation requirements, expected performance, monitoring, and testing, see the Deployment Requirements and Installation Guide documents.
- Create a Connector that routes journaled messages to your Sensor.
- Create a journal rule in O365 that copies messages to your Sensor.
- Confirm that your Sensor is working.
- Whitelist Agari’s alerts server to ensure that you and your users receive alerts.
Create a Connector to route journaled messages to your Sensor
Log in to your O365 dashboard (typically at https://portal.office.com). You will need to use an account with appropriate permissions to create the rule required.
In order to route journaled messages to the Sensor, you need to invent a fake domain that messages will be routed to. This may seem a bit illogical, but it is necessary due to the way O365 handles routing.
Begin by heading to the Exchange Admin center by clicking the drop-down menu and the Admin Centers submenu on the left-hand side of your administration dashboard:
Inside the Exchange admin center Click mail flow and choose the connectors tab to view your current list of Connectors:
Click the “+” button to create a new Connector. The “From:” drop-down should be set to Office 365 and the “To:” drop-down should be set to Partner organization. (It’s possible that your configuration may be more complex, or otherwise differ from these instructions, but the general idea is that messages coming from the journaling feature of O365 will receive special routing.):
Now click Next. On the following screen, set the Name to something like Agari Sensor. You can include text in the Description field as desired. The Turn it on checkbox should be left in the default checked state:
Click Next. Leave the radio button selected at Only when email messages are sent to these domains and click the “+” button to add a new domain. Here you will invent a domain name that does not exist, and which will never be used for email delivery. Do not use a subdomain of your own company, as it may not function correctly. For example, if you are company.com, do not use “*.agari.journaling.company.com”. Instead, simply create a fake and unlikely domain such as “*.invented.agari.journaling.domain.com”. You do not need to create DNS for this domain, and it does not need to be genuine in any other way, as long as it follows the proper syntactic form of a domain name. Make sure to have “*.” at the beginning of this field.
Note: If you are familiar with wildcards or regular expressions, you may be wondering how “email@example.com” will match the pattern described above, since it would seem to require a subdomain be present. For whatever unfortunate reason, this is just the shorthand O365 uses to mean “anything at invented.agari.journaling.domain.com”. Their web form will not allow “*domain.com” or “*@domain.com”, but “*.domain.com” will in fact match “firstname.lastname@example.org”.
Click Next. On the following screen, change the radio button to select Route email through these smart hosts. Click the “+” button to add a smart host, and enter the IP address of your Sensor machine (188.8.131.52, in this example):
Click Next. On the next window you can configure the TLS settings for the Sensor. We recommend that you leave Always use Transport Layer Security enabled. Set the radio button to Any digital certificate, including self-signed certificates. (If you have installed verified TLS certificates in your Sensor, you may choose to select Issued by a trusted certificate authority (CA) instead.)
Click Next. You should see a confirmation screen that looks something like this:
Click Next and you will be given the opportunity to confirm that the Connector is reachable. Click the “+” button and specify an email address in the dialog window that uses the same invented domain you specified earlier (in the above example, “invented.agari.journaling.domain.com”). The part of the address left of the “@” sign is irrelevant: you can make anything up:
Now click Validate and you should see a window appear after a short delay:
The previous dialog will now show a list validation results. If any of them read Failed, you can click on the pencil button to view the log from that test and address any issues in the configuration. If all went well, the window will look something like this:
If you see Succeeded for both Tasks, you can click Save and the Connector creation will be complete.
Create a journal rule to copy messages to the Sensor
Before creating the journal rule, you must create a mail user that will be used to receive Non-Delivery Reports (“NDR’s”) for journaled messages (unless you already have such a mail user in place that you wish to use instead). It is advised that someone monitor this address periodically to ensure that there are no connectivity issues between O365 and the Sensor machine.
Click Recipients on the left-hand side, and then choose the contacts tab. Click the “+” menu and choose Mail User.
In the dialog that appears, you can choose almost any values you prefer. We suggest something like Journaling for the First Name, NDRs for the Last Name, “journalingndrs” for the Alias, and a User ID of “journaling_ndrs”, thus creating something like “email@example.com” as the email address. Enter an appropriate password for the account. When you are finished, the dialog will look something like this:
Click Save. Now you are ready to make the journaling rule.
On the left-hand-side of the screen, click Compliance Management. Then click on the Journal Rules page.
Before you can create a journal rule, you must specify the address to which non-delivery reports will be sent. If you have already established other journaling, there may already be an address shown on this page. If not, click the Select address link that appears after Send undeliverable journal reports to:, and use it to choose the “firstname.lastname@example.org” mail user that you created previously.
Next, to make a new journal rule, click the “+” menu.
In the *Send journal reports to: field, enter a made-up address using the domain you invented in the previous step. Following our example above, we’ll use “email@example.com” in this example. The part of the address left of the “@” character is unimportant (it will be ignored by the Sensor) but a well-formed address must be entered here, and of course the domain must match exactly the one you configured previously.
In the *Name: field, enter “Agari Dual Delivery”.
In the *If the message is sent to or received from… drop-down menu, you can choose [Apply to all messages] if you want all messages to be sent for analysis.
- If, instead, you would like only messages to a subset of your user base to be evaluated by Agari, you can choose “A specific user or group…” and select a group from the list that appears. The group you select here must be created via the recipients > groups section of the Exchange admin center. You can use a Distribution Group, a Security Group, or, if you want to avoid changing the group as new members join or leave your organization, you can use a Dynamic Distribution Group, the membership of which is calculated every time a message comes in, according to a set of rules that you define.
In the *Journal the following messages… drop-down, choose External messages only. (It may be tempting to select All messages, but this would also include messages that are sent from one of your users to another of your users, which are not useful to the Sensor.)
The dialog window should now look something like this:
Click Save. A confirmation saying Do you want this rule to apply to all future messages? will appear. Click Yes. As soon as you do this, messages will begin to flow to the Sensor.
Confirm that your Sensor is working
Once you have established Dual Delivery, the Sensor should begin receiving messages. It may take some time for result to begin appearing, but this will serve as evidence that the Sensor is functioning.
Whitelist the Agari alerts server
When Agari deems an email suspicious, the Agari alerts server will send you (or a role account) and, optionally, the recipient of the email, an email-based alert message regarding the perceived threat. Besides identifying the threatening message, the alert email may contain additional information about the type or severity of the threat. Furthermore, in case of operational problems, the Agari alerts server may also send out alerts regarding your Sensor and the overall health of your Agari Phishing Defense service. Given the importance and utility of these alerts, Agari recommends that you whitelist the Agari alerts server to ensure that your system does not block, quarantine, or otherwise interfere with these messages.
The messages that the Agari alerts server sends may sometimes contain portions of the content of the original messages. Since the original messages may contain spam, or otherwise be perceived as suspicious by email filtering software, it’s possible that the Agari alerts may themselves accidentally be perceived as threats. Thus it is doubly important to whitelist the Agari alerts server to prevent the triggering of “false positives” in the filtering software. If there are intermediate steps filtering your email stream before it gets to the system we are configuring with this document. For example, other intermediate MTAs, or other anti-phishing solutions that filter your email stream should also be configured to whitelist the Agari alerts server. Agari’s Sales Engineering and Customer Success teams can assist with this if needed; it is generally a straightforward process.
These instructions will detail adding the Agari alerts server to your connection filter whitelist, and adding a mail flow rule to prevent spam filtering of the alerts.
In the Exchange admin center, click on protection on the left-hand side menu, and click on the connection filter tab. Your exact configuration may vary, and you will need to alter these directions in some cases, but the idea is to configure the IP Allow list of the applicable connection filter; typically this will be the “Default” connection filter. Click on the pencil icon to edit that filter:
In the window that appears, click on connection filtering, and click on the “+” icon to add an Allowed IP Address. (Make sure you are not adding a “Blocked IP Address”!). In the small window that appears, enter the IP address 184.108.40.206, and then click the OK button:
After so doing, you will see the IP appear in the configuration window:
After double-checking that the IP address was entered correctly, click Save to return to the connection filter tab. You should confirm that the Default connection filter shows IP Allow list: Configured on the right side of the screen.
Next you can establish a new mail flow rule. On the left side, click mail flow and then click on the rules tab. In the drop-down menu under the “+” button, select Bypass spam filtering…:
In the window that appears, enter something descriptive for the Name, such as “Whitelist Agari alerts server”. Open the Apply this rule if… drop-down menu, and under the The sender… option, choose IP address is in any of these ranges or exactly matches:
A small window will appear. Enter the IP address 220.127.116.11 in the field, and click the “+” button to add it. The window should look something like the image to the left.
After double-checking that the IP address was entered correctly, Click OK. Back on the new rule window, you have the option of scrolling down and enabling the checkbox that says Stop processing more rules. If you have other rules that filter messages or otherwise may impact delivery of these alerts, you should check that box. However, you may have other rules in place that make this a poor choice it will depend on your configuration and is left to your discretion.
The new rule window will now look something like this:
Click Save to save the new rule. The rules tab will now show your rule. Consider the ordering of any other rules that you have in the list: ideally, the Agari whitelist rule could come first in the list, to ensure that no other rules interfere with delivery. The completed rule is shown here (in an otherwise empty list of rules):
These two configuration changes should enable the Agari alerts server messages to be delivered as intended.
(As seen above, the IP address of the Agari alerts server is 18.104.22.168. Agari also maintains a DNS entry for this address at the domain outbound.agari.com. In general, of course, it is recommended to use the IP address, since the sending domain of an address can be easily spoofed, but the domain is provided in case it is useful.)
Thank you for using Agari! Don’t hesitate to contact us (at firstname.lastname@example.org) if you have any questions about or suggestions for improving this document.
Please sign in to leave a comment.