Proxy Management

Overview

MailFleet proxy management stores approved network routes as reusable profiles on your desktop. Attach them to SMTP or API provider workflows when your organization requires outbound campaign traffic to egress through specific gateways.

MailFleet supports three assignment patterns: master proxy (workspace default), campaign-wise assignment (per-campaign override), and managed network profile selection (across approved profiles).

Proxies organize legitimate operational routing — they do not replace provider credentials, DNS authentication, or permission-based list requirements.

When to use proxy profiles

Use proxy profiles when your security policy, client contract, or network architecture requires MailFleet to connect to SMTP/API providers through designated paths.

• Agency workflows with per-client approved egress
• Separating staging and production network routes
• Regional gateways required by compliance or provider setup
• Corporate firewalls that mandate outbound SMTP through a proxy

Create a proxy profile

Open Proxy Management in MailFleet and add a new profile. Use labels that identify client, region, or environment — not generic names like "Proxy 1" that become ambiguous at scale.

1. Open Settings → Proxy Management (or the proxy section in your workspace)
2. Click Add profile and enter host, port, and authentication if required
3. Add a descriptive label (e.g. "Client A — US East — Production")
4. Add notes for contract ID, firewall ticket, or IP allowlist details
5. Run Test connectivity and confirm success before saving for assignment

Routing modes explained

Choose the assignment mode that matches how your team sends mail. You can combine modes: a master proxy for most work, with campaign-wise overrides for exceptions.

• Master proxy — set one profile as the default route for providers or the workspace until you override it
• Campaign-wise assignment — select a specific proxy on an individual campaign; overrides master for that send only
• Approved profile pool — MailFleet selects from a defined set of approved network profiles per connection or send batch; use only with network-team approval for controlled load distribution

Assign proxies to providers

Provider-level assignment applies a proxy to every campaign that uses that SMTP or API profile. This is efficient when one client always sends through the same gateway.

If a provider connects directly without a proxy, leave the proxy field empty for that profile — do not attach a staging proxy to production providers.

1. Open the SMTP or API provider profile
2. Select the proxy profile from the dropdown (or choose None for direct connection)
3. Save the provider and run a small test campaign
4. Review campaign logs for connection or authentication errors

Assign proxies to campaigns

Campaign-wise assignment is useful when multiple campaigns share a provider but only some require a proxy — or when each campaign maps to a different client gateway.

Campaign assignment overrides provider defaults when both are configured. Document the override in campaign notes for audit clarity.

1. Create or edit a campaign
2. Open network / proxy settings for the campaign
3. Select Inherit from provider, Master proxy, a specific profile, or approved profile pool
4. Save and run a test send before scheduling the full list

Test connectivity

Always test after creating, editing, or rotating proxy credentials. A failed test is cheaper than a failed campaign.

• Use the built-in connectivity test on the proxy profile screen
• Confirm SMTP ports 587 or 465 (or your provider port) are allowed through the proxy
• For API providers, confirm HTTPS CONNECT or equivalent is permitted
• Run a 1–5 recipient test campaign and inspect logs before full volume

Monitor errors in campaign logs

Routing problems appear in campaign logs as connection timeouts, proxy authentication failures, or TLS negotiation errors — often before any deliverability signal.

Filter logs by provider and error type to isolate whether the issue is proxy-side, provider-side, or authentication-related.

• Connection timed out — firewall, wrong port, or proxy downtime
• 407 Proxy Authentication Required — update credentials or IP allowlist
• SMTP banner never received — proxy may block SMTP protocol passthrough
• Intermittent failures — check proxy concurrent connection limits

Agency multi-client setup

Agencies typically create one proxy profile per client (or per client environment) and assign them campaign-wise so operators cannot accidentally route Client A traffic through Client B's gateway.

Pair proxy labels with matching provider profile labels and export campaign logs per client for reporting.

• Naming convention: Client — Region — Environment
• Separate staging profiles; never reuse production proxies for list tests
• Document proxy ownership in profile notes
• Include proxy profile name in internal runbooks for handoffs

Responsible use and compliance

Proxy profiles must align with MailFleet Acceptable Use Policy, your email provider terms, and applicable law. Legitimate uses include approved egress, testing, and operational separation.

Prohibited uses include filter evasion, unsolicited mail, rotating deceptive identities, or bypassing provider suspensions. Violations may result in account action.

• Obtain provider and client approval before routing production mail
• Maintain permission-based lists regardless of proxy configuration
• Keep SPF, DKIM, and DMARC aligned with sending domains
• Review /acceptable-use-policy before scaling campaigns

Troubleshooting checklist

Work through this list when proxy tests fail or campaigns stall at connection:

1. Verify host, port, username, and password on the proxy profile
2. Confirm your desktop IP is allowlisted on the proxy if required
3. Test the same provider without proxy to isolate proxy vs provider issues
4. Check corporate VPN or firewall rules on the MailFleet workstation
5. Ask your network team whether SMTP or HTTPS is permitted through the gateway
6. Review campaign logs for the exact SMTP/API error code
7. Re-test after any DNS, credential, or firewall change