Overview / Mail Accounts

Mail Accounts

Create, test, and maintain the sending profiles Virtual Mailer uses for campaign delivery, tracking deployment, and unsubscribe handling.

Purpose

What Mail Accounts Control

A Mail Account is the sending profile a campaign uses when it is executed. It stores the delivery method, server details, authentication settings, sender identity, send pacing, and optional tracking deployment credentials.

Delivery

Controls how messages are transmitted, such as SMTP, Outlook Interop, DirectSend MX, Pickup Directory, or provider-hosted SMTP like SendGrid.

Identity

Defines the sender name, mailbox credentials, and server-level authentication required by your provider.

Operations

Supports throttling, account testing, tracking script deployment, and POP-before-SMTP workflows when required by older environments.

Recommended workflow: create one account, validate it with a small live test, then attach it to campaigns after inbox placement and unsubscribe behavior are confirmed.
Main Screen

Working in the Mail Accounts Module

  • Create: use New to open the account editor and define a fresh sending profile.
  • Edit: double-click an account row to open the editor.
  • Delete: remove unused accounts only after confirming no active campaigns depend on them.
  • Filter Row: narrow the grid when you manage multiple providers, brands, or client accounts.
  • Linked Campaigns: the editor shows whether any campaigns currently reference the account.
Deleting an account that is already assigned to campaigns can force cleanup work across those campaigns. Review linked campaigns before removal.
Quick Start

Recommended Setup Workflow

  1. Create a descriptive Account Name that tells operators exactly what the route is used for, such as Main SMTP - Marketing or SendGrid - transactional warmup.
  2. Select the correct Send Method for the provider or local delivery path.
  3. Enter the server, port, authentication, and sender details.
  4. Set safe throttling values for your provider and sender reputation stage.
  5. Use Test before assigning the account to high-volume campaigns.
  6. If you use open tracking or hosted unsubscribes, open Tracking & POP... and configure deployment separately.
  7. Run a real mailbox test and confirm inbox placement, sender identity, unsubscribe links, and tracking behavior.
Field Guide

Core Editor Fields

Field What It Means Guidance
Account Name Internal label used throughout Virtual Mailer. Make it operationally clear. Include provider, purpose, and environment when helpful.
Send Method Delivery engine Virtual Mailer will use. Use SMTP for most deployments unless you specifically need Outlook Interop, Pickup Directory, or DirectSend MX.
SMTP Server Server hostname for SMTP-based delivery methods. Use the exact hostname your provider supplies. Do not enter a web URL.
Port Network port used for the selected send method. Common values are 587, 465, or 25 depending on provider requirements.
Encryption SMTP transport security mode. Auto is the best default unless your provider explicitly requires TLS 1.2, TLS 1.3, or no encryption.
Requires Authentication Determines whether username and password fields are used. Most hosted providers require authentication. Leave enabled unless you operate a trusted internal relay.
Sender Name SendGrid-specific sender display name field shown only when the Send Method is SendGrid SMTP. This is a SendGrid requirement in Virtual Mailer. It must match the sender-name configuration used in SendGrid, alongside the SendGrid email and API key fields.
User Name SMTP login name or provider-specific value. For some providers this is a mailbox address. In the SendGrid relay mode, the form repurposes this field as SendGrid Email and expects the verified sender email that matches your SendGrid configuration.
Password SMTP password or API key. Use the provider-issued credential. In the SendGrid relay mode, this field becomes API Key and must match the SendGrid account configuration used for relay.
Pickup Directory Folder used only when the Pickup Directory send method is selected. Messages are written as .eml files instead of being transmitted immediately.
Send X per session Batch size for each send cycle. Lower values reduce throttling risk during reputation warm-up and on shared mail infrastructure.
Wait Y seconds Pause between batches. Use this to smooth throughput and avoid provider rate limits.
Send Methods

Choosing the Right Delivery Method

Method Best Use Operational Notes
SMTP Most production sending scenarios Recommended default for standard provider-hosted delivery and authenticated domain sending.
SendGrid SMTP SendGrid-based delivery Uses smtp.sendgrid.net with username apikey and your API key as the password.
Outlook Interop Desktop-user send-through-Outlook workflows Depends on a local Outlook profile and workstation setup. Better for user-driven sends than background batch operations.
DirectSend MX Advanced internal or explicitly trusted environments No provider-authenticated SMTP relay. Deliverability can be poor on the public internet if sender identity and IP reputation are not strong.
Pickup Directory Offline review, testing, or handoff workflows Writes message files to disk instead of sending. Useful for inspection and downstream processing.
If you are uncertain, choose SMTP. It is the most predictable and supportable path for public delivery.
Method Selection

Quick Guidance by Scenario

Scenario Recommended Method Reason
Most business sending SMTP Best default for authenticated delivery with broad provider support.
Sending as a local Outlook user Outlook Interop Uses the workstation's Outlook profile and mailbox context.
Internal trusted-only delivery DirectSend MX Advanced option when recipient servers already trust the sender environment.
Review, offline handoff, or archival Pickup Directory Creates message files without transmitting them immediately.
SendGrid UI

What Changes When SendGrid SMTP Is Selected

When the Send Method combo is switched to SendGrid SMTP, the editor changes the visible fields and labels to reflect the SendGrid-specific workflow.

  • SMTP Server: shown but forced to smtp.sendgrid.net.
  • Port: shown but forced to 587.
  • Encryption: shown but forced to TLS.
  • Requires Authentication: hidden because SendGrid auth is always expected in this mode.
  • User Name field: relabeled to SendGrid Email.
  • Sender Name field: becomes visible and is relabeled to SendGrid Name.
  • Password field: relabeled to API Key.
In SendGrid mode, all three values must align with your SendGrid setup: SendGrid Email, SendGrid Name, and API Key. Virtual Mailer treats these as required when SendGrid SMTP is selected.
SMTP Guidance

SMTP Configuration Best Practices

Server and Port

  • Use the server name exactly as provided by the mail host.
  • 587 is the most common modern submission port.
  • 465 is sometimes used for SSL/TLS-only submission.
  • 25 is often restricted and should not be your first choice unless required.

Authentication and Encryption

  • Leave authentication enabled unless your relay is explicitly trusted and unmanaged public sending is not involved.
  • Prefer Auto encryption unless your provider requires a fixed TLS version.
  • Use app passwords or API keys when the provider offers them.
  • Confirm your From domain is authenticated with SPF, DKIM, and where relevant DMARC.
An SMTP connection test only proves that credentials and server access work. It does not guarantee good inbox placement or compliance with the recipient network's policies.
Send Pacing

Throttling and Warm-Up Strategy

Virtual Mailer lets you control how quickly messages leave the selected account. Use this deliberately, especially for new sender domains, new IP space, or providers with rate limits.

  • Conservative starting point: 25 messages per session with a 10 second pause is a reasonable low-risk baseline.
  • Increase gradually: raise batch size only after you see stable delivery, low complaint rates, and no provider throttling.
  • Use smaller batches for new domains: warm-up periods should be deliberate rather than immediate full-volume sends.
  • Match provider limits: if your SMTP service enforces hourly or daily caps, set pacing below those thresholds.
If campaigns pause, slow down, or encounter transient SMTP errors, reduce batch size before assuming the server is broken.
Tracking and POP

The Tracking and POP Dialog

The Tracking & POP... button opens additional settings used for two specific features:

  • POP before SMTP: required only for older mail systems that demand a POP login before sending.
  • Tracking and unsubscribe deployment: used to upload the hosted tracking and unsubscribe scripts to your web server.
The dialog allows staged setup. You can save a valid Tracking URL before the transfer host and credentials are complete, but deployment and synchronization will not work until the transfer settings are also configured.

POP Before SMTP

Most modern providers do not need POP-before-SMTP. Leave it disabled unless the mail host explicitly instructs you to use it.

Field Use Guidance
SMTP server requires POP login before sending Enables the POP-before-SMTP workflow. Only turn this on when your provider documents the requirement.
POP Server / Port Server and port used for the POP login step. Use the provider's exact POP server details.
Use same settings as my outgoing server Reuses SMTP credentials for POP authentication. Enable this if the provider uses the same login identity for both services.
User Name / Password POP credentials when different from outgoing credentials. Only required if the POP account uses separate authentication.

Tracking and Unsubscribe Deployment Fields

These fields control how Virtual Mailer deploys and later synchronizes the hosted tracking and unsubscribe scripts.

The destination web server must support PHP for the deployed tracking and unsubscribe scripts to function correctly after upload.

Field What It Does Guidance
FTP Host Server used to upload the PHP tracking files. Enter the file-transfer hostname, not the website URL.
Port Transfer port for the selected protocol. Current common defaults are 21 for FTP and FTPS, and 22 for SFTP.
User / Password Credentials for the file-transfer account. Use a scoped account with access limited to the tracking deployment location when possible.
Protocol Selects the transfer protocol used by the current release. FTPS (Recommended) is the default for new accounts. SFTP (SSH) is also secure. Plain FTP is legacy and unencrypted.
Open Logging Script Filename for the tracking script. Must be filename-only and end in .php. Do not enter a path or full URL.
FTP Upload Folder Server path where the scripts will be uploaded. Enter the remote folder, such as ./tracking or the host's mapped directory path.
URL to FTP Folder Public web URL that corresponds to the upload folder. Enter the folder URL only, for example https://yourdomain.com/tracking/. Do not include the script filename.
Deploy Tracking Script Uploads the tracking and unsubscribe handlers to the server. Use after all transfer settings are verified.
The URL field should point to the folder that will host the scripts, not directly to pixel_tracking.php or unsubscribe.php.
Saving the account validates the Tracking URL and script-name format, but it does not require FTP host and user fields to be complete. Those transfer settings are enforced when you deploy scripts or when the campaign editor attempts synchronization.

For the full deployment and sync workflow, see Tracking and Unsubscribe.

Transfer Security

FTPS vs SFTP vs FTP

FTPS (Recommended Default)

  • Uses FTP over TLS/SSL encryption.
  • Protects credentials and transferred files in transit.
  • Usually runs on port 21.
  • Requires the server certificate to match the configured FTP host name for full validation.
  • Best fit for many shared-hosting providers that advertise FTP with TLS support.

SFTP (Preferred)

  • Uses SSH for encrypted transport.
  • Protects credentials and transferred files in transit.
  • Usually runs on port 22.
  • Recommended when the hosting provider supports it.

FTP (Legacy)

  • Does not encrypt credentials or transferred files.
  • Often still available on shared hosting, but weaker from a security standpoint.
  • Usually runs on port 21.
  • Use only when SFTP is unavailable.
Use FTPS or SFTP whenever possible. If FTPS is selected, the configured FTP host should match the server certificate name. Use plain FTP only when secure options are unavailable.
Testing

How to Validate a Mail Account

  1. Create or update the account and save it.
  2. Use Test in the editor to verify connection and authentication.
  3. Send a small live message to real inboxes you control.
  4. Confirm the sender name, From address, and reply behavior look correct.
  5. Check whether the message lands in inbox, promotions, spam, or quarantine.
  6. If tracking is enabled, deploy the scripts, send a test campaign, and confirm opens and unsubscribes sync back correctly.
Always validate with a real recipient mailbox test. Technical connection success does not replace end-to-end delivery verification.
Readiness

When Tracking Is Considered Ready

For campaign-level tracking sync, Virtual Mailer now treats an account as tracking-ready only when both of these are true:

  • Tracking URL: a valid public folder URL is configured.
  • Transfer configuration: the account has a transfer host, user name, and valid protocol for FTP, FTPS, or SFTP.
A saved Tracking URL by itself is not enough to make the Sync Tracking command available in the Campaign Editor.
Provider Notes

Common Provider Patterns

  • Generic SMTP providers: use the provider's hostname, submission port, encryption recommendation, and mailbox or API credentials.
  • Microsoft 365 / hosted Exchange: modern auth restrictions, MFA, or tenant policy can affect account setup. Validate mailbox permissions and app-password availability where relevant.
  • Google Workspace / Gmail: app passwords may be required when standard password auth is blocked. If Google shows the app password with spaces, remove those spaces before entering it into Virtual Mailer.
  • SendGrid: use the SendGrid Setup guide and configure username apikey.
  • Internal relay servers: verify whether auth is required and whether recipient-domain restrictions are enforced by the relay.
Outlook Behavior

What to Expect with Outlook Interop

  • Microsoft Outlook must be installed and a valid Outlook profile must exist.
  • Outlook does not need to be open before sending. Virtual Mailer can start and use its own Outlook instance as needed.
  • If Outlook requires authentication, the user may still see a mailbox or login prompt during send operations.
  • This method is better suited for mailbox-based user sending than for high-volume unattended throughput.
Troubleshooting

Common Problems and Fixes

Problem Likely Cause What to Check
Authentication failed Wrong username, password, or provider auth policy Recheck credentials, app passwords, API key format, and whether the account is allowed to send via SMTP.
Connection timed out Wrong host, blocked port, firewall, or SSL/TLS mismatch Verify hostname, port, encryption mode, and local/network firewall rules.
Messages send but land in spam Deliverability or sender identity issues Review SPF, DKIM, DMARC, domain warm-up, content quality, and recipient engagement patterns.
Tracking deploy fails Wrong transfer credentials, wrong remote path, protocol mismatch, or FTPS certificate validation failure Confirm the transfer server, folder path, selected protocol, certificate hostname match for FTPS, and whether the account has write permission to the target folder.
Tracking sync finds nothing Scripts not deployed, logs empty, or sync credentials/path incorrect Validate deployment first, then inspect the remote log location and account transfer settings.
Pickup Directory errors Folder missing or write access denied Make sure the target folder exists and the application can write to it.
Operational Advice

Recommended Naming and Lifecycle Practices

  • Name accounts for the route they represent, not just the mailbox. Example: SMTP - newsletters.example.com.
  • Separate high-volume marketing routes from lower-volume operational or client-specific routes when practical.
  • Do not reuse old or uncertain credentials. Replace them cleanly and retest.
  • Review linked campaigns before changing or deleting an account.
  • Retest accounts after provider credential rotation, mailbox policy changes, or DNS/authentication updates.
Related Guides

Next Steps