B2B / Corporate-Gateway Deliverability

Mail to business domains (@company.com) is usually not filtered by the mailbox provider the KB's consumer-focused articles describe. It passes first through a secure email gateway (SEG) — Proofpoint, Mimecast, Barracuda, Cisco/IronPort, or Microsoft 365's Exchange Online Protection — chosen and configured by the recipient organization's IT admin. Gateways answer to the admin, not to the recipient, and behave fundamentally differently from Gmail or Yahoo. This article covers the model and the three major third-party gateways; for M365 tenant filtering, see Microsoft sender requirements.

Provenance: the Proofpoint Essentials mail-flow and URL Defense pages are login-gated on help.proofpoint.com; content here is from Wayback Machine snapshots (May 2025 and March 2025 respectively). The Mimecast URL Protect definitions article is Cloudflare-gated on the support site; content is from a July 2025 Wayback snapshot.

How gateway filtering differs from consumer mailbox providers

Dimension	Consumer providers (Gmail/Yahoo/Outlook.com)	Corporate gateways (Proofpoint/Mimecast/Barracuda)
Who sets policy	Provider's global filter + per-user engagement models	The recipient organization's IT admin, per tenant
Primary signals	Engagement (opens, replies, deletes), complaint rate, domain/IP reputation	Static IP/domain reputation feeds, content rules, admin allow/block lists
Engagement feedback	Opens/moves/complaints feed the filter	Essentially none — user behavior rarely influences filtering
Complaint loop	FBLs (ARF) available to senders	No FBLs; "complaints" surface as admin blocks
Sender visibility	Postmaster tools (GPT, SNDS)	None — you learn from bounces, silence, or the recipient
Failure mode	Spam folder	SMTP reject, silent quarantine (admin digest), or admin-hold
Recovery path	Fix behavior, wait for reputation to recover	Delisting portals + asking the recipient admin to allowlist
Consistency	One policy per provider	Every tenant is different — the same gateway can accept your mail at one company and reject it at the next

Consequences for a sender:

• Reputation is more binary. You are on a blocklist/low-reputation tier or you are not; there is no per-user personalization to partially save you.
• Quarantine is invisible. Many gateways accept the message (250 OK), then hold it in a quarantine the recipient sees only via a daily digest — your logs show "delivered", the recipient says "never got it".
• One admin decision covers thousands of mailboxes. A block at a large enterprise domain removes the whole domain at once; conversely, one allowlist entry fixes it at once.
• Identify the gateway from the MX record before diagnosing: *.pphosted.com / *.ppe-hosted.com → Proofpoint; *.mimecast.com → Mimecast; *.barracudanetworks.com / on-prem Barracuda appliance → Barracuda; *.mail.protection.outlook.com → Microsoft 365/EOP.

Proofpoint

Mail-flow / filtering order (Essentials)

Inbound messages are processed in this order:

1. DNS/IP reputation checks — 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 — a message blocked as Virus can never be released, by the customer or by Proofpoint.
5. Anti-spoofing scan — DMARC, DKIM, and SPF.
6. Filters — admin custom filters and safe/block sender lists. Executables (.exe, .dll, .bat, .js, and others) are blocked before custom filters. 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) — not bypassed by custom filters: even mail exempted by an allow filter still gets its links rewritten.

Practical readings: connection-level PDR/CSI rejections happen before content is ever seen (fix = IP reputation), while quarantine events are policy/content (fix = content or admin allowlist). An admin "Allow" entry bypasses spam scoring but not URL rewriting or virus checks.

PDR and ipcheck.proofpoint.com

PDR (Proofpoint Dynamic Reputation) is a machine-learning content-classification-driven IP reputation system aimed at identifying compromised/botnet IPs; identified IPs are delayed (deferred) or blocked across all Proofpoint-protected recipients at once. A sudden wave of deferrals or rejections at many unrelated business domains simultaneously is the classic PDR-listing symptom.

• Check and delist: https://ipcheck.proofpoint.com/ (redirects to proofpoint.com/us/ipcheck) — enter the IP to see whether it is blocklisted or being delayed, and submit information/a delist 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 expedited handling via the support portal; non-customers use the tool/email only.
• If a specific Proofpoint-protected organization blocks you (policy, not global reputation), Proofpoint will not act on your request — the recipient organization must open the ticket; only their authorized support contacts can contact Proofpoint Support.

URL Defense (link rewriting)

URL Defense rewrites every URL in delivered mail through urldefense.proofpoint.com (or urldefense.com) and scans the destination at click time. Rewritten (v2) format:

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

Parameter	Meaning
u	the original URL (encoded: : → -3A, / → _)
d	debug flags
c	PPS cluster ID
r	the recipient of the message
m	a message identifier
s	digital signature preventing tampering
e	blank end-of-URL marker

Sender-relevant behavior:

• DKIM interaction: by default URL Defense rewrites URLs in DKIM-signed mail, which breaks the DKIM signature post-delivery (relevant when mail is forwarded onward — see ARC). Admins can disable rewriting of DKIM-signed messages.
• Admin exemptions exist per domain/IP, per sender address, for plain-text URLs, and for bare IPs — this is what you ask a recipient admin to configure if rewriting is mangling your links.
• If link text shows a URL that differs from the actual href, the visible text URL is rewritten and becomes the link — a reason "pretty" display URLs over tracking hrefs can end up pointing somewhere unexpected in defended mail.
• On a malicious verdict the user gets a block page and the browser URL changes; Proofpoint false-positive reports require the original rewritten link from the email, not the block-page URL.
• There is no official public URL Defense decoder for Essentials; third-party decoders exist (the u= parameter is mechanically decodable).
• Click-time scanning means Proofpoint's infrastructure fetches your links — see Why click metrics lie below.

Proofpoint support paths (summary)

Situation	Path
IP delayed/blocked globally (PDR/CSI)	ipcheck.proofpoint.com → delist-request@proofpoint.com follow-up; ~72 h; no phone
Blocked by one specific protected org	Ask that org's admin; only their authorized contacts can open Proofpoint tickets
SORBS listings (historically operated by Proofpoint)	Via the SORBS website only

Mimecast

URL Protect (link rewriting)

Mimecast rewrites all links in inbound email and scans the destination in real time when clicked (domain checks + URL validation before the user is passed through). Rewritten links point at a regional Mimecast domain (e.g. protect-eu.mimecast.com/s/...; the exact host depends on the grid/region hosting the account). Configuration is per URL Protect definition, applied by policy; key settings a sender may collide with:

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

Delisting: Mimecast blocks senders via both its own global reputation checks and per-tenant policies. Its SMTP rejection text names the reason class (reputation vs. a named policy), which tells you whether to pursue Mimecast's sender-facing channels or the recipient's admin — rejections citing a specific tenant policy require that tenant's admin, exactly as with Proofpoint. (Mimecast's rejected/deferred-message troubleshooting article was not in this extraction's source set; treat per-code guidance from that page as future work.)

Barracuda

Barracuda Reputation Block List (BRBL) and removal

Barracuda runs its own public DNSBL (query zone b.barracudacentral.org), consulted both by Barracuda appliances and by third parties (see Blocklists). Removal is via https://www.barracudacentral.org/rbl/removal-request:

• Required fields: email server IP address, contact email address, phone number. Optional: Barracuda customer name/email, reason for removal.
• Requests with a valid justification are typically investigated and processed within 12 hours.
• Requests without valid information are ignored; duplicate submissions are disregarded — submit once, with a real explanation of cause and remediation.
• The form is an intake, not a documentation page: listing criteria and appeal procedure are not published.

Gateway allow/block list mechanics (Email Security Gateway)

Admin lists live under the appliance's BLOCK/ACCEPT pages and cover IP addresses, domains/subdomains, and sender or recipient email addresses:

• Allow-listed mail skips spam scoring but is still virus-scanned; IP controls and banned-attachment checks still apply. Allowlisting is not a full bypass.
• Message log semantics: "Allowed" = passed all filters; "Allow Listed" = matched an explicit allow entry. (Useful when a recipient admin reads their logs back to you.)
• Sender spoof protection (reject external mail using the tenant's own domain in From) is configurable globally or per domain, and the global setting supersedes per-user allow-list entries — a common reason "but they allowlisted us" still bounces when 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 just the visible From.
• SPF checking is disabled by default (DNS overhead) but when enabled can tag/block failures, with quarantine recommended for none results; known-forwarder IPs bypass SPF, rate control, and IP-reputation checks. DKIM verification is CPU-intensive and off by default; Barracuda warns that HTML lines over 990 characters can break DKIM validation. DMARC enforcement is available via the Cloud Protection Layer.
• Invalid bounce suppression tags outbound mail with an encrypted token and rejects bounces lacking it — one reason DSNs to Barracuda-protected senders sometimes bounce back.
• Barracuda appliances score content (spam-scoring thresholds are admin-set per tenant), so identical mail can be tagged at one Barracuda site and clean at another.

Barracuda rejections typically include a URL pointing at barracudanetworks.com/reputation with the listed IP — the direct pointer to the BRBL removal form above.

Practical guidance for senders

Warming into B2B lists

• Standard IP warm-up logic applies, but the feedback signal is different: gateways give you no postmaster dashboards and no FBLs, so watch bounce text and deferral rates per receiving domain, not engagement.
• Gateways key heavily on static reputation at connection time (PDR, CSI, BRBL, Spamhaus). A brand-new IP with no history triggers greylisting-style deferrals and rate limits; a dirty IP triggers outright rejection. Check the IP 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. Segment warm-up by receiving domain and back off a domain-by-domain basis on 4xx storms rather than pausing everything.
• Corporate lists decay faster than consumer lists (job-change churn is commonly estimated at 20–30%/yr); stale B2B lists hit high unknown-user rates, which gateways and their reputation feeds treat as a strong spam signal. Verify aggressively before warming.
• Engagement-based warming ("send to recent openers first") barely helps here — gateways don't watch opens. What helps is clean authentication (SPF/DKIM/DMARC all passing and aligned), since gateways run explicit anti-spoofing steps early in the pipeline, plus valid rDNS/HELO.

Interpreting gateway bounces

Symptom	Likely meaning	Action
5xx at connection/early SMTP citing reputation, a DNSBL, or a reputation URL	Global reputation block (PDR/CSI/BRBL/Spamhaus)	Delist via the vendor portal; fix root cause first
4xx deferrals across many unrelated business domains at once	PDR-style dynamic delay or new-IP throttling	Slow down, verify IP health, retry; delist if persistent
5xx citing "policy", "local policy", "prohibited by administrator", or a rule name	Tenant admin policy	Only the recipient org can fix; ask contact to request allowlisting
250 accepted, recipient never sees it	Quarantine/hold digest	Recipient searches quarantine; admin releases + allowlists
Bounce on mail From: the recipient's own domain	Sender spoof protection	Never use the recipient's domain in From; use your own authenticated domain
DSN/bounce messages to your bounce address themselves bouncing	Invalid-bounce suppression (tag validation)	Expected; ensure your Return-Path handling doesn't loop

Always capture the full SMTP reply text — gateway rejections usually name the vendor, the reason class, and often the exact remediation URL.

Why click metrics lie (security scanners)

Every major gateway rewrites links and fetches them from vendor infrastructure — at delivery time (sandboxing/pre-scan), at click time (URL Defense, URL Protect, Microsoft SafeLinks), and sometimes repeatedly. Each fetch hits your click-tracking redirect and registers as a "click". Effects and detection:

• B2B click rates are inflated and untrustworthy as engagement signals; a "clicked every link within 1 second of delivery" pattern is a scanner, not a person.
• Heuristics for filtering bot clicks in event data: clicks within seconds of delivery; all links in a message clicked (including unsubscribe and footer links); clicks from datacenter IP ranges or the gateway vendor's ASN; HEAD requests or non-browser user agents; multiple recipients at the same domain "clicking" identically.
• Never treat a click on an unsubscribe or confirmation link as intent for B2B recipients — scanners follow those too. Use one-click List-Unsubscribe POST semantics and require an explicit confirming action for anything destructive triggered by GET.
• Mimecast's Warn/User-Awareness interstitials mean even a real click may be logged by the gateway yet never reach your page; conversely your page may be fetched by Browser Isolation infrastructure rather than the user's device.
• This is the corporate-side twin of Apple MPP's proxy opens — see the tracking/MPP article in operations/ for pixel mechanics, MPP proxy opens, and how to design sunset policies on distorted data (../operations/tracking-mpp-and-bot-clicks.md).
• Rewriting also affects deliverability of forwarded mail: URL Defense breaks DKIM on signed messages it rewrites, so downstream re-filtering of forwarded corporate mail sees broken signatures.

Asking recipients for allowlisting

For any list with meaningful B2B concentration, publish an allowlisting request the recipient's IT team can act on. Ask them to allow, in order of preference:

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

Caveats to set expectations with customers: allowlisting on most gateways still leaves virus scanning, attachment blocking, and IP controls active; it is per-tenant, so it must be requested at every important recipient organization; and it does not survive the recipient switching gateway vendors.

What does NOT work

• Engagement remediation ("win-back campaigns to improve reputation") — gateways don't measure engagement.
• Waiting out a listing — BRBL and PDR listings persist until delisted or the underlying behavior stops being observed; use the portals.
• Contacting the gateway vendor about a tenant-policy block — vendors only act on their own global reputation listings; tenant blocks are the tenant's.
• Rotating IPs to escape a listing — content-derived listings (PDR classifies by content; Barracuda scores content) follow the mail stream to the new IP, and fresh IPs restart the throttling problem. See reputation monitoring for the general delisting workflow.