# How do you safely whitelist a sender in Microsoft 365 and Google Workspace?

URL: https://iblockspam.com/blog/whitelist-sender-microsoft-365-google-workspace
Last updated: 2026-10-09
Published: 2026-10-09
Topic: Running email day to day
Author: iBlockSpam Team

> Safely allow (whitelist) a sender in Microsoft 365 and Google Workspace without opening a spoofing hole: Tenant Allow/Block List, approved senders and gateways.

## Short answer

Add the narrowest allow entry that fixes the problem, and keep authentication checks on. In Microsoft 365, create an allow entry in the Tenant Allow/Block List rather than an SCL -1 transport rule. In Google Workspace, add the sender to an approved senders address list with sender authentication required. Avoid domain-wide entries that anyone can spoof.

Allowing a sender, often called whitelisting, is the quickest fix when good mail lands in junk. It's also one of the easiest ways to weaken your filtering by accident. Done badly, it tells your system to trust any message that merely claims to come from a domain.

## Why was the sender blocked in the first place?

An allow entry hides a symptom. Often the cause is fixable at the sender's end, and fixing it helps every recipient, not just you.

1. **Get a copy of the blocked message** from quarantine or the junk folder.
2. **Read the headers** in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer). Look at `Authentication-Results` for SPF, DKIM and DMARC, and at Microsoft's `X-Forefront-Antispam-Report` or Gmail's reason banner.
3. **If authentication failed**, ask the sender to fix their SPF, DKIM or DMARC. A sender who fails authentication shouldn't be allowed domain-wide.
4. **If authentication passed** and the content was misjudged, report it as a false positive to your provider, then consider an allow entry.

Our guides to [false positives](https://iblockspam.com/blog/false-positives-legitimate-email-flagged) and [why an email landed in spam](https://iblockspam.com/blog/why-did-this-email-land-in-spam) go deeper on diagnosis.

## Why are domain-wide allow entries risky?

Allow lists usually match the From address that people see. Microsoft notes that Tenant Allow/Block List entries apply to the `5322.From` address. Google says it checks "if the From: sender address matches any addresses or domains in the address lists," and doesn't use the `Return-Path` for matching.

The From address is trivial to forge. If your rule says "trust everything from `supplier.example`" and doesn't check authentication, an attacker who puts `accounts@supplier.example` in the From line skips your spam filter. That's exactly the address you'd expect an invoice-fraud attempt to use.

Microsoft's [allowlist guidance](https://learn.microsoft.com/en-us/defender-office-365/create-safe-sender-lists-in-office-365) is blunt: never configure mail flow rules with only the sender domain as the condition to skip spam filtering, because it "significantly" increases the likelihood that attackers can spoof the sending domain and skip all spam filtering. It also says not to use your own domains or popular domains such as microsoft.com as conditions.

The safe pattern on every platform is the same: **allow narrowly, and require authentication.**

## How to allow a sender in Microsoft 365

If a sender's mail keeps landing in Junk, check [why Microsoft 365 sends email to junk](https://iblockspam.com/blog/microsoft-365-emails-going-to-junk) first; the fix is often a setting, not an allow entry.

Microsoft lists its allow methods from most to least recommended:

| Rank | Method | Main risk |
|---|---|---|
| 1 | Allow entries in the Tenant Allow/Block List | Lowest; entries expire and authentication still applies |
| 2 | Exchange mail flow (transport) rules | Spoofing if the rule matches only the sender domain |
| 3 | Outlook Safe Senders | Per-mailbox; bypasses parts of filtering and interferes with zero-hour auto purge |
| 4 | IP Allow List in the connection filter policy | Skips spam filtering and SPF, DKIM and DMARC |
| 5 | Allowed sender or domain lists in anti-spam policies | Skips spam, spoof and phishing protection (except high confidence phishing) and authentication |

Microsoft says to use the alternatives only "if you can't use allow entries in the Tenant Allow/Block List for some reason." Whatever you choose, messages identified as malware or high confidence phishing are always quarantined.

### Create a Tenant Allow/Block List entry

From the [Microsoft Learn procedure](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-email-spoof-configure):

1. In the Microsoft Defender portal, go to **Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists**, or open `https://security.microsoft.com/tenantAllowBlockList`.
2. On the **Domains & addresses** tab, select **Add**, then **Allow**.
3. Enter one email address or domain per line, up to 20.
4. Under **Remove allow entry after**, keep the default **45 days after last used date**, or pick 1 day, 7 days or a specific date up to 30 days ahead.
5. Add a note saying why, and who asked. Select **Add**.

Entries start working within about 5 minutes. A few points to know:

- Direct allow entries can override bulk, spam, high confidence spam and phishing (not high confidence phishing) verdicts. For malware or high confidence phishing, you must submit the message on the **Submissions** page as **I've confirmed it's clean** and choose **Allow this message**.
- Microsoft explains that if messages "pass other checks in the filtering stack," they're delivered; its example is a message that passes email authentication, URL filtering and file filtering. That's the protection that a bare transport rule removes.
- Without Defender for Office 365, you can have up to 500 allow entries for domains and addresses.

### When a partner legitimately sends as your domain

Some services, such as a payroll provider or a ticketing system, send mail with your own domain in the From address and get caught by spoof detection. Don't allow your own domain. Use the **Spoofed senders** tab instead, which allows a *domain pair*: the spoofed user and the sending infrastructure. Microsoft explains that "only the combination of the spoofed user and the sending infrastructure" is allowed. Better still, have the service sign with DKIM for your domain so it passes DMARC and needs no exception. Our [DKIM setup guide](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) covers this.

### If you really need a transport rule

Microsoft documents a safer rule for when the Tenant Allow/Block List won't do:

1. Condition: **The sender > domain is** the partner's domain.
2. Extra condition: **The message headers > includes any of these words**, header `Authentication-Results`, values `dmarc=pass` and `dmarc=bestguesspass`.
3. Actions: **set the spam confidence level (SCL) > Bypass spam filtering**, plus **set a message header** such as `X-ETR` with a note explaining the bypass.

The authentication condition is what makes the rule safe. Without it, you've built an SCL -1 bypass for anyone who can type the partner's domain.

## How to allow a sender in Google Workspace

In Gmail, you build an address list, then use it as an approved senders list in spam settings.

### Step 1: Create an address list with authentication required

1. In the Google Admin console, go to **Apps > Google Workspace > Gmail > Routing** and select **Manage address lists**.
2. Create a list and add individual addresses where possible, or a domain if you trust the whole organization.
3. Leave sender authentication turned on for each entry.

Google's [address list help](https://knowledge.workspace.google.com/admin/gmail/advanced/use-address-lists-to-apply-settings-to-specific-people-or-domains) says the authentication option "is turned on by default for each address or domain" and recommends you "always keep this option turned on" to help protect against spoofing. A message counts as authenticated if it passes SPF with the From address matching the Return-Path, or has a valid DKIM signature whose domain matches the From address. Google's [2019 announcement](https://workspaceupdates.googleblog.com/2019/05/improvements-to-gmail-sender-lists.html) renamed the checkbox "Require sender authentication (recommended)" and encouraged admins to enable it for any senders where it was off.

### Step 2: Use the list as approved senders

1. Go to **Apps > Google Workspace > Gmail > Spam, Phishing and Malware**.
2. Select the organizational unit, scroll to **Spam**, and select **Configure** or **Add another rule**.
3. Choose the option to bypass spam filters for the approved senders list, select your address list, and save.

Per Google's [custom spam filter help](https://knowledge.workspace.google.com/admin/gmail/advanced/add-custom-spam-filters-to-gmail), "Incoming messages from domains or addresses on the selected approved senders list bypass Gmail spam filters," and you must select at least one address list or the option has no effect. Changes can take up to 24 hours.

Avoid two other options on that page. Google describes the setting that lets all incoming messages bypass spam filters as not recommended, and another option hides warnings about possible suspicious messages. Both trade safety for convenience.

Google also offers an IP allowlist. Messages from an allowlisted IP "won't be put in the spam label," but recipients may still see a warning banner ([Allowlists, denylists, and approved senders](https://knowledge.workspace.google.com/admin/gmail/advanced/allowlists-denylists-and-approved-senders)). Only use it for IPs you control or that are dedicated to one sender, never for shared sending platforms.

## How to allow a sender at a filtering gateway

If your MX points to a filtering gateway in front of Microsoft 365 or Google Workspace, mail passes two sets of filters. An allow entry only helps in the layer that made the block, so check the headers first to see which one did.

At the gateway, apply the same rules: allow individual addresses where you can, and require the sender to authenticate. iBlockSpam's [approved and blocked sender lists](https://iblockspam.com/features/allow-block-lists) can require sender verification. With it turned on, an approved entry doesn't let through a message that merely forges the From address. If the gateway passes a message and Microsoft 365 or Gmail then junks it, the fix belongs in that platform, using the steps above. See our [Microsoft 365](https://iblockspam.com/platforms/microsoft-365) and [Google Workspace](https://iblockspam.com/platforms/google-workspace) setup pages for how the layers fit together.

## How do you keep your allow list clean?

- [ ] Diagnosed the block from headers before allowing anything.
- [ ] Allowed an address rather than a whole domain wherever possible.
- [ ] Kept an authentication requirement on every entry.
- [ ] Never allowed your own domain or a large public domain such as a free webmail provider.
- [ ] Set an expiry, or put a review date in the note.
- [ ] Recorded who requested the entry and why.
- [ ] Reviewed all allow entries at least quarterly and removed ones no longer needed.

## Next steps

- Export your current allow entries in Microsoft 365 and Google Workspace and look for domain-only entries without authentication.
- Replace any SCL -1 rules that match only a sender domain with Tenant Allow/Block List entries, or add a `dmarc=pass` condition.
- Ask partners who keep getting blocked to check their SPF, DKIM and DMARC setup, for example with the free [DMARC Checker](https://iblockspam.com/tools/dmarc-checker).
- If you need the opposite, see [how to block a sender or domain in Microsoft 365](https://iblockspam.com/blog/block-sender-or-domain-microsoft-365), including how long each kind of block lasts.
- If you use a gateway, confirm its allow lists can require sender verification, as iBlockSpam's can.

Related: [Outlook junk email filter settings](https://iblockspam.com/blog/outlook-junk-email-filter-settings) explains the Safe Senders list each user controls.

Browse more guides on [running email day to day](https://iblockspam.com/blog/topic/operations).

## Frequently asked questions

### What is the safest way to whitelist a sender in Microsoft 365?

Microsoft's first recommendation is an allow entry in the Tenant Allow/Block List. Allow entries for domains and addresses still require messages to pass other checks, such as email authentication, and they expire by default 45 days after last use. Use transport rules or anti-spam allowed lists only if the Tenant Allow/Block List can't do the job.

### Why is an SCL -1 transport rule risky?

A rule that sets SCL to -1 based only on the sender domain lets anyone who forges that domain skip spam filtering. Microsoft warns this 'significantly' increases the risk of spoofing. If you must use a rule, add a condition that the Authentication-Results header contains dmarc=pass.

### How do I whitelist a sender in Google Workspace?

Create an address list under Gmail routing settings, keep 'Require sender authentication' turned on for each entry, then use that list as the approved senders list in your organization's spam settings. Messages from those senders bypass Gmail spam filters only when they're authenticated.

### When is it OK to whitelist an entire domain?

Rarely. Prefer a single address. A domain-wide entry covers everyone at that domain, including any compromised account, and invites spoofing if authentication isn't enforced. Allow a whole domain only for a trusted partner with working SPF, DKIM and DMARC, and only with an authentication requirement.

### Why does whitelisted mail still go to spam?

Usually because a different layer blocked it. Allow lists in one product don't affect another. Malware and high-confidence phishing are quarantined in Microsoft 365 regardless of allow lists, and a gateway in front of your mailbox has its own lists. Check the headers to see which system made the decision.

### Should I ever allow my own domain?

No. Microsoft advises against using your own accepted domains or popular domains as conditions to skip filtering. Attackers forge your own domain precisely because people trust it. Fix internal or third-party senders with proper authentication instead.

## Sources

- [Microsoft Learn: Create allowlists](https://learn.microsoft.com/en-us/defender-office-365/create-safe-sender-lists-in-office-365)
- [Microsoft Learn: Manage allows and blocks in the Tenant Allow/Block List](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-about)
- [Microsoft Learn: Allow or block email using the Tenant Allow/Block List](https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-email-spoof-configure)
- [Google Workspace Admin Help: Use address lists to apply settings to specific people or domains](https://knowledge.workspace.google.com/admin/gmail/advanced/use-address-lists-to-apply-settings-to-specific-people-or-domains)
- [Google Workspace Admin Help: Add custom spam filters to Gmail](https://knowledge.workspace.google.com/admin/gmail/advanced/add-custom-spam-filters-to-gmail)
- [Google Workspace Admin Help: Allowlists, denylists, and approved senders](https://knowledge.workspace.google.com/admin/gmail/advanced/allowlists-denylists-and-approved-senders)
- [Google Workspace Updates: Improvements to Gmail sender lists (2019)](https://workspaceupdates.googleblog.com/2019/05/improvements-to-gmail-sender-lists.html)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.

---

Source: iBlockSpam, https://iblockspam.com/blog/whitelist-sender-microsoft-365-google-workspace (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt
