B2B / Corporate-Gateway Deliverability

When you send to business addresses (@company.com), your mail is usually not filtered by a consumer mailbox provider such as Gmail or Yahoo. It passes first through a secure email gateway (SEG) that the recipient organization's IT administrator chooses and configures: Proofpoint, Mimecast, Barracuda, Cisco IronPort, or Microsoft 365's Exchange Online Protection. Gateways answer to the administrator, not to the recipient, and they behave very differently from consumer providers.

Below are the gateway model and the three major third-party gateways. For filtering in M365 tenants, see Microsoft sender requirements.

Source note: the Proofpoint Essentials pages on mail flow and URL Defense require a login on help.proofpoint.com, so the content here comes from Wayback Machine snapshots (May 2025 and March 2025 respectively). The Mimecast support article on URL Protect definitions is behind a Cloudflare check, so its content comes from a July 2025 Wayback snapshot.

How gateway filtering differs from consumer mailbox providers

What this means for a sender:

• Reputation is closer to all or nothing. You are either on a blocklist or low reputation tier, or you are not. No personalization for individual users can partly save you.
• Quarantine is invisible. Many gateways accept the message (250 OK), then hold it in a quarantine that the recipient sees only in a daily digest. Your logs show "delivered", and the recipient says they never got it.
• One administrator's decision covers thousands of mailboxes. A block at a large enterprise domain removes the whole domain at once. In the same way, one allowlist entry fixes it at once.
• Identify the gateway from the MX record before you diagnose: *.pphosted.com or *.ppe-hosted.com means Proofpoint; *.mimecast.com means Mimecast; *.barracudanetworks.com or an on-premises Barracuda appliance means Barracuda; *.mail.protection.outlook.com means Microsoft 365 (EOP).

Proofpoint

Order of mail flow and filtering (Essentials)

Proofpoint Essentials processes inbound messages in this order:

1. Reputation checks on DNS and IP address: PDR (Proofpoint Dynamic Reputation) and CSI (Cloudmark Sender Intelligence).
2. DNS validity checks (inbound sender DNS check).
3. Attachment Defense (if licensed).
4. Anti-virus scanning. Neither the customer nor Proofpoint can ever release a message blocked as a virus.
5. Anti-spoofing scan: DMARC, DKIM and SPF.
6. Filters: custom filters set by the administrator, and safe and block sender lists. Executables (.exe, .dll, .bat, .js, and others) are blocked before custom filters run. Any filter that triggers Quarantine or Allow skips the anti-spam step.
7. Anti-spam content engine.
8. URL Defense scan and rewrites (if licensed). Custom filters do not bypass this step: even mail exempted by an allow filter still has its links rewritten.

In practice, PDR and CSI rejections at connection time happen before any content is seen, so the fix is IP reputation. Quarantine events come from policy or content, so the fix is content or an allowlist entry from the administrator. An "Allow" entry from the administrator bypasses spam scoring, but not URL rewriting or virus checks.

PDR and ipcheck.proofpoint.com

PDR (Proofpoint Dynamic Reputation) is an IP reputation system driven by machine-learning classification of content. It aims to identify compromised IP addresses and IP addresses in botnets. Once identified, an IP address is delayed (deferred) or blocked for every recipient Proofpoint protects, all at once. A sudden wave of deferrals or rejections at many unrelated business domains at the same time is the classic symptom of a PDR listing.

• Check and delist: https://ipcheck.proofpoint.com/ (which redirects to proofpoint.com/us/ipcheck). Enter the IP address to see whether it is blocklisted or delayed, and submit information or a delisting request from the same tool.
• Follow-up: email delist-request@proofpoint.com if the tool does not resolve it. Inquiries can take 72 hours to process. There is no phone support for delisting.
• Proofpoint customers get faster handling through the support portal. Everyone else can use only the tool and the email address.
• If a specific organization that Proofpoint protects blocks you (a policy decision, not global reputation), Proofpoint will not act on your request. The recipient organization must open the ticket, because only its authorized support contacts can contact Proofpoint Support.

URL Defense (link rewriting)

URL Defense rewrites every URL in delivered mail so that it passes through urldefense.proofpoint.com (or urldefense.com), and scans the destination when the link is clicked. The rewritten (v2) format looks like this:

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.google.com&d=DwMBaQ&c=...&r=...&m=...&s=...&e=

Behavior that matters to senders:

• Interaction with DKIM: by default, URL Defense rewrites URLs in DKIM-signed mail, which breaks the DKIM signature after delivery. This matters when the mail is forwarded onward (see ARC). Administrators can turn off rewriting for DKIM-signed messages.
• Exemptions set by the administrator exist for a domain or IP address, for a sender address, for URLs in plain text, and for bare IP addresses. This is what you ask a recipient's administrator to configure if rewriting is damaging your links.
• If the link text shows a URL that differs from the actual href, the URL in the visible text is rewritten and becomes the link. This is why a "pretty" display URL placed over a tracking link can end up pointing somewhere unexpected in protected mail.
• When a link is judged malicious, the user sees a block page and the URL in the browser changes. To report a false positive to Proofpoint, you need the original rewritten link from the email, not the URL of the block page.
• Proofpoint offers no official public decoder for URL Defense links in Essentials. Third-party decoders exist, because the u= parameter can be decoded mechanically.
• Because links are scanned at click time, Proofpoint's infrastructure fetches your links. See Why click metrics lie below.

Proofpoint support paths (summary)

Mimecast

URL Protect (link rewriting)

Mimecast rewrites all links in inbound email and scans the destination in real time when a link is clicked (it checks the domain and validates the URL before letting the user through). Rewritten links point to a regional Mimecast domain (for example, protect-eu.mimecast.com/s/...; the exact host depends on the grid or region that hosts the account). Each URL Protect definition sets the configuration, and a policy applies it. These are the main settings a sender may run into:

• Rewrite mode: Relaxed rewrites only valid URLs with top-level domains. Moderate adds IP addresses. Aggressive rewrites anything shaped like a URL, and is the only mode that rewrites URLs containing illegal characters.
• URL category scanning blocks links by category. Compromised, Phishing & Fraud, Malware and Botnets are blocked at every level. Spam Sites and Suspicious are blocked at Moderate and Aggressive. Private IPs, and the extra machine-learning zero-day model, apply only at Aggressive. A tracking or landing domain in the "Spam Sites" or "Suspicious" category is therefore blocked for most tenants.
• Action on an unsafe URL: Allow (logged), Warn (an interstitial page; the user may continue) or Block (a block page). URLs in attachments cause the attachment to be stripped instead. Browser Isolation (a remote safe-browsing session) may replace direct access for suspicious sites.
• All clicks are logged, and every click is scanned again. This is another source of bot traffic in sender analytics.
• Links are rewritten as HTTPS by default. URLs in the subject line can be removed or rewritten (rewritten links are up to 200 characters, which visibly changes the subject). Plain-text mail can be converted to HTML specifically so its links can be rewritten ("Create Missing HTML Body").
• The Ignore Signed Messages option skips rewriting for digitally signed mail, to preserve the signatures.
• Display URL Destination Domain appends the real destination domain to the rewritten link, for example protect-eu.mimecast.com/s/1dBvZWHZ?url.uk.m.mimecastprotect.com.
• Advanced similarity checks flag links that look similar to the tenant's internal or monitored domains. Lookalike or cousin sending domains can trip this check even when they are legitimate.
• Scanning of URLs in attachments covers HTML, TXT and PDF files, archives, and Office and OpenOffice formats up to 50 MB (encrypted files over 40 MB are treated as malicious). QR codes in images are scanned, and a malicious verdict on a QR code can Reject or Hold the whole message (a defense against "quishing").
• User Awareness pages can challenge a percentage of clicks with an interstitial page before letting the user through. A click can therefore be logged even when the person never reaches your page.
• Mimecast never rewrites its own login*.mimecast.com domains.

Delisting: Mimecast blocks senders both through its own global reputation checks and through the policies of each tenant. Its SMTP rejection text names the class of reason (reputation, or a named policy). That tells you whether to use Mimecast's channels for senders or to contact the recipient's administrator. A rejection that cites a specific tenant policy needs that tenant's administrator, exactly as with Proofpoint. (Mimecast's troubleshooting article on rejected and deferred messages was not among the sources used here, so guidance for individual codes from that page is not covered yet.)

Barracuda

Barracuda Reputation Block List (BRBL) and removal

Barracuda runs its own public DNSBL (query zone b.barracudacentral.org). Both Barracuda appliances and third parties consult it (see Blocklists). To request removal, use https://www.barracudacentral.org/rbl/removal-request:

• Required fields: the IP address of the email server, a contact email address and a phone number. Optional: the Barracuda customer name or email, and the reason for removal.
• Requests with a valid justification are typically investigated and processed within 12 hours.
• Requests without valid information are ignored, and duplicate submissions are disregarded. Submit once, with a real explanation of the cause and the remediation.
• The form only collects requests. Barracuda does not publish its listing criteria or an appeal procedure.

How allow and block lists work (Email Security Gateway)

The administrator's lists live on the appliance's BLOCK and ACCEPT pages. They cover IP addresses, domains and subdomains, and sender or recipient email addresses:

• Allowlisted mail skips spam scoring but is still scanned for viruses. IP controls and checks for banned attachments still apply. Allowlisting is not a full bypass.
• In the message log, "Allowed" means the message passed all filters, and "Allow Listed" means it matched an explicit allow entry. The distinction helps when a recipient's administrator reads their logs to you.
• Sender spoof protection rejects external mail that uses the tenant's own domain in the From header. It can be set globally or for each domain, and the global setting overrides allowlist entries for individual users. This is a common reason mail still bounces after "they allowlisted us": you put the recipient's own domain in the From header.
• Custom sender filters match on Envelope From, Header From and Reply-To. All three identities matter, not only the visible From address.
• SPF checking is off by default because of the DNS overhead. When it is on, it can tag or block failures, and quarantine is recommended for none results. IP addresses of known forwarders bypass SPF, rate control and IP reputation checks. DKIM verification uses a lot of CPU and is off by default. Barracuda warns that HTML lines over 990 characters can break DKIM validation. DMARC enforcement is available through the Cloud Protection Layer.
• Invalid bounce suppression tags outbound mail with an encrypted token and rejects bounces that lack it. This is one reason delivery status notifications (DSNs) sent to senders protected by Barracuda sometimes bounce back.
• Barracuda appliances score content, and each tenant's administrator sets the spam scoring thresholds. Identical mail can therefore be tagged at one Barracuda site and pass clean at another.

Barracuda rejections typically include a URL at barracudanetworks.com/reputation with the listed IP address. That URL leads directly to the BRBL removal form above.

Practical guidance for senders

Warming into B2B lists

• The usual IP warm-up logic applies, but the feedback is different. Gateways give you no postmaster dashboards and no FBLs, so watch the bounce text and deferral rates for each receiving domain, not engagement.
• Gateways rely heavily on static reputation at connection time (PDR, CSI, BRBL, Spamhaus). A brand-new IP address with no history triggers deferrals and rate limits similar to greylisting; an IP address with a bad history triggers outright rejection. Check the IP address against ipcheck.proofpoint.com, b.barracudacentral.org and the major public blocklists before the first send.
• B2B lists concentrate risk: one enterprise domain may be 5–10% of the list. Warm up separately for each receiving domain, and when a domain returns a storm of 4xx deferrals, back off for that domain alone rather than pausing everything.
• Corporate lists decay faster than consumer lists (churn from job changes is commonly estimated at 20–30%/yr). Stale B2B lists hit high rates of unknown users, which gateways and their reputation feeds treat as a strong spam signal. Verify addresses thoroughly before warming up.
• Warming by engagement ("send to recent openers first") barely helps here, because gateways do not watch opens. What helps is clean authentication, with SPF, DKIM and DMARC all passing and aligned, since gateways run explicit anti-spoofing steps early in the pipeline. Valid rDNS and HELO also help.

Interpreting gateway bounces

Always capture the full SMTP reply text. Gateway rejections usually name the vendor and the class of reason, and often give the exact URL for remediation.

Why click metrics lie (security scanners)

Every major gateway rewrites links and fetches them from the vendor's infrastructure. It does this at delivery time (sandboxing or pre-scanning), at click time (URL Defense, URL Protect, Microsoft Safe Links), and sometimes repeatedly. Each fetch hits your click-tracking redirect and is recorded as a "click". The effects, and how to detect them:

• B2B click rates are inflated and cannot be trusted as engagement signals. A pattern of "clicked every link within 1 second of delivery" is a scanner, not a person.
• Heuristics for filtering bot clicks out of event data: clicks within seconds of delivery; all links in a message clicked (including the unsubscribe and footer links); clicks from data-center IP ranges or from the gateway vendor's autonomous system number (ASN); HEAD requests or user agents that are not browsers; several recipients at the same domain "clicking" identically.
• Never treat a click on an unsubscribe or confirmation link as intent from a B2B recipient, because scanners follow those links too. Use the POST behavior of one-click List-Unsubscribe, and require an explicit confirming action before any destructive change that a GET request would trigger.
• With Mimecast's Warn and User Awareness interstitials, the gateway may log a real click that never reaches your page. Conversely, Browser Isolation infrastructure may fetch your page instead of the user's device.
• This is the corporate counterpart of the proxy opens caused by Apple MPP. For how tracking pixels work, how MPP proxy opens behave, and how to design sunset policies on distorted data, see Tracking and Measurement Distortion in operations/.
• Rewriting also affects the deliverability of forwarded mail. URL Defense breaks DKIM on the signed messages it rewrites, so any filter that checks forwarded corporate mail further along sees broken signatures.

Asking recipients for allowlisting

If a meaningful share of your list is B2B, publish an allowlisting request that the recipient's IT team can act on. Ask them to allow the following, in order of preference:

1. Your sending IP ranges. An allow at connection level beats content filtering, and on Barracuda an allow for a known forwarder or IP address also bypasses SPF and rate control.
2. Your envelope-from (Return-Path) domain and your DKIM domain, not only the friendly From address. Gateway sender filters match Envelope From, Header From and Reply-To separately.
3. Exemption from link rewriting for your tracking domain (in Proofpoint, "Exclude URLs that contain specified domains"; in Mimecast, exceptions in the definition), if rewriting breaks your links or your analytics matter.

Set expectations with customers. On most gateways, allowlisting still leaves virus scanning, attachment blocking and IP controls active. It applies to one tenant, so it must be requested at every important recipient organization. And it does not survive the recipient switching to another gateway vendor.

What does NOT work

• Remediating engagement ("win-back campaigns to improve reputation"), because gateways do not measure engagement.
• Waiting for a listing to expire. BRBL and PDR listings persist until you delist, or until the behavior behind them stops being observed. Use the portals.
• Contacting the gateway vendor about a block set by a tenant's policy. Vendors act only on their own global reputation listings; the tenant owns its blocks.
• Rotating IP addresses to escape a listing. Listings derived from content (PDR classifies by content; Barracuda scores content) follow the mail stream to the new IP address, and fresh IP addresses bring back the throttling problem. See reputation monitoring for the general delisting workflow.