Skip to content
INFIMA Knowledge Base

Allowlist phishing tests in a client's email security

A client’s security team wants to allowlist our phishing tests, or their email security is getting in the way of them. What to allowlist depends on the kind of tool they run and where it sits, not on the sender addresses in our templates. Find the client’s tool below and add only what it needs.

You’ll need

Section titled “You’ll need”
  • The name of the client’s email security tool, and whether it filters mail on the way in or scans mailboxes after mail arrives. The client’s IT contact will know.
  • Access to that tool, or someone at the client who has it.
  • The Administrator role in INFIMA, for the Microsoft 365 setting below.

Tools that scan the mailbox after delivery

Section titled “Tools that scan the mailbox after delivery”

Ironscales and similar tools connect to the client’s Microsoft 365 tenant and scan mail after it lands. They can find our phishing tests even when the client is sync’d, and remove them, often from every inbox at once after one user reports a test.

  1. Open the client → Tailor. On the Phishing card, click Edit.

  2. Turn on Synthetic Received Header and click Save Changes.

  3. Allowlist 34.232.212.184 in the tool, wherever it lets you exclude phishing simulation traffic by IP address. The address’s forward and reverse DNS both match phishsim.infimasec.com. If the tool can only exclude by sender (Barracuda Impersonation Protection, for example), allowlist the client’s own Return-Path instead: once the setting is saved, the card shows it next to This client’s Return-Path, with a Copy button. Add that exact address, never its domain. If the card says the client’s simulations don’t carry a Return-Path to allowlist, contact our support team with the client’s name and the name of the tool.

Do both steps: the setting gives the tool something to match, and the allowlist entry tells it what to skip. Keep in mind:

  • Microsoft 365 only. The setting changes only phishing tests we deliver straight into Microsoft 365 mailboxes, the ones the client’s Sent Emails page shows with Microsoft API as the method. Only those carry the header and the Return-Path.
  • New tests only. It applies to tests sent after you save. Tests the tool already removed stay removed until someone releases them in the tool; An email security tool is removing phishing tests from inboxes walks through the cleanup.

Mail gateways

Section titled “Mail gateways”

A mail gateway filters mail on its way into the client’s mailboxes. Our phishing tests reach a gateway only when they travel through normal mail flow, and then the client’s Sent Emails page shows InfimaMail as their method instead of Microsoft API or Gmail API. That happens for:

  • Manually set-up clients (no directory sync).
  • Users in a sync’d client whose mailbox we can’t reach through the sync, such as an on-premises Exchange mailbox in a hybrid setup, or an unlicensed mailbox.

For those, exempt 34.232.212.184 on the gateway. It’s the address our phishing tests come from.

Every other user in a sync’d client gets their tests delivered straight into the mailbox, so a gateway never sees them.

Training emails come from a different address. For those, see A user isn’t getting training emails.

Section titled “Link scanners”

Tools that scan or rewrite links in mail can block our landing pages before the user sees the teachable moment. Allowlist our landing domains in the tool’s URL allow list. They’re listed in Phishing landing pages.

Why not allowlist our tests’ From addresses

Section titled “Why not allowlist our tests’ From addresses”

Don’t add the From addresses of our phishing tests, or their domains, to any allowlist:

  • We don’t own those domains. Each template sends from a lookalike domain, and anyone can register one and use it to send real phishing. An allowlist entry for it would let that mail through too.
  • Some tests send from personal email services such as Gmail, Yahoo and Proton Mail. Allowlisting those lets in mail from anyone with an account there.
  • Allowed senders skip the tool’s checks. The tool stops checking their links, so a real attack from one of those senders would reach users untouched.

Use the IP address entries above instead. If the client’s tool can only exclude mail by sender, allowlist the client’s own Return-Path. It’s on a domain we own and made for that client alone, not a template’s sender, so add only that exact address. If the tool can only exclude senders has the steps.

You’ll know it worked when

Section titled “You’ll know it worked when”
  • New phishing tests stay in users’ inboxes, and the client’s tool stops opening incidents or quarantining them.
  • Users who click a test reach the teachable-moment page instead of a block page.
  • On the client’s Sent Emails page, recent tests show as delivered to the inbox.

Frequently asked

Section titled “Frequently asked”

The client is sync’d. Do they need any of this? Only if their tool scans the mailbox after delivery, or a link scanner blocks our landing pages, or some of their users’ phishing tests show InfimaMail as the method on the Sent Emails page. A sync’d client with none of those needs nothing.

The client is on Google Workspace and a tool is removing tests. The Synthetic Received Header setting only applies to Microsoft 365. Contact our support team with the client’s name and the name of the tool.

Should I turn on Synthetic Received Header for every client? No. Turn it on only for clients whose tool removes phishing tests after delivery.

Section titled “Related”