Security

Security at Mailsoftly

Last updated: October 2026

This page describes the measures that protect Mailsoftly and the data our customers keep in it. It supplements our Privacy Policy and our Terms of Service. Reviewers can request our security documents through the Trust Center.

Mailsoftly is an email marketing service provided by Albert Solino Corp., a California corporation doing business as Mailsoftly ("Mailsoftly", "we", "us"). Customers trust us with their contact lists and their messages, so this page sets out how the service is hosted, protected, monitored and recovered.

1. Overview

Mailsoftly is a hosted email marketing application. Customers sign in through a browser to manage contact lists, build campaigns and send email, either through our sending infrastructure or from their own connected mailbox. The application and all customer data are hosted in the United States.

We maintain written security policies covering access control, secure development, vulnerability management, incident response, business continuity, data retention and deletion, vendor management and logging. Customers can request them at [email protected].

2. Infrastructure and certifications

The application runs on Salesforce Heroku with a managed Postgres database. Email is delivered through Amazon Web Services and our other sending providers, and files and secrets are held in Amazon Web Services. Cloudflare sits in front of it as the TLS endpoint and edge protection layer, filtering requests before they reach the application.

Our core infrastructure providers (Salesforce Heroku, Amazon Web Services, Cloudflare) are SOC 2 Type II audited and ISO 27001 certified, with reports available from each provider's trust portal. The application servers, the database and the file storage buckets are all in a single United States region.

3. Data protection

• In transit. TLS is enforced on every connection to the application, HTTP is redirected to HTTPS, HTTP Strict Transport Security is emitted, and session cookies are secure, HttpOnly and SameSite Lax.
• At rest. The database is encrypted at rest by the platform, and uploaded files are stored in Amazon S3 in the United States.
• Secrets. Credentials for connected Microsoft 365 and Google mailboxes, mailbox app passwords and CRM integration tokens are held outside the database in a managed secrets store, encrypted.
• Passwords and keys. Passwords, recovery codes and trusted-device tokens are stored only as hashes. API keys issued today are stored only as a hash, carry an explicit scope and expire one year after issue; older keys issued before these controls are being retired.
• Isolation. Separation between accounts is enforced in the application: records are loaded within the signed-in user's organization, and out-of-scope ids return not found. In September 2026 we reviewed every place the application looks up a record from a request id and closed the gaps we found.
• Private files. An administrator can switch on private file links for the account. Files in the account's file gallery then stay private in storage, with public access blocked, and open only through a viewer link that issues a short-lived download. Images placed in emails stay publicly reachable by design, because they have to load in the recipient's inbox.
• Secure document links. A sensitive document can be sent as a secure link instead of an attachment. The recipient confirms details already on file before the download opens, repeated failed attempts lock the link, links expire and can be revoked, every successful unlock is recorded in the account's activity log, and the files are removed after a retention period the account sets.
• Deletion. The account owner can delete the account in Settings, or ask us in writing. Campaigns sent through our infrastructure, scheduled sends and automations stop at once, and the deletion can be cancelled for 30 days. Database content is then purged, and uploaded files are removed within a further 30 days. Backups age out on their normal schedule. Unsubscribe and complaint records and the billing and legal records we must keep are retained.

4. Account security

Passwords must be at least 8 characters. An account locks after 10 failed attempts and unlocks after one hour or by emailed link, and reset links expire after six hours. Users can add two-step verification with a code from an authenticator app, plus ten single-use recovery codes. Wrong verification codes count toward the lockout, and signing out ends every signed-in session.

An administrator can set rules for a whole organization:

• require two-step verification for every member who signs in with a password, with an enrollment period you choose, after which anyone not enrolled cannot use the account (Google and Microsoft sign-ins rely on the identity provider's own verification);
• restrict sign-in to Microsoft work accounts, so password sign-in and personal Microsoft accounts are refused and your own tenant governs the factors and conditional access;
• sign members out automatically after a chosen period of inactivity, on every sign-in method;
• switch Mailsoftly support access off, so our support team cannot open the account.

Access inside an account is role based, and only administrators invite or remove members. Administrators read an activity log in their own settings. It records team and role changes, ownership transfers, support access and file privacy settings, contact imports and exports, deletion requests, and the life of lists, campaigns, SMS messages, templates, forms, pages, automations, senders, domains and reply-to addresses. Each entry shows how the change was made: in the web app, through an API key, through a connected app, in a support session, by Mailsoftly support, by a recipient or automatically. Entries cannot be edited in the application once written.

Support access. When support access is on and our team needs to reproduce a problem, they open the account in a session that shows a banner with its end time and ends after one hour. The sign-in and every change made during the session appear in the activity log labeled as Mailsoftly support.

Staff access. Our internal tools are limited to named Mailsoftly staff accounts protected by an authenticator app. The legacy administration console was disabled in September 2026 and its accounts deleted. Two-factor authentication is required by policy on every production platform account, and the quarterly access review tracks and closes exceptions.

Session recording. The application uses analytics and session recording to improve the product. On request we switch both off for an account, and they then do not load on that account's pages.

5. Application security

• Changes are developed on named branches and merged into a protected main branch that cannot be force-pushed or deleted.
• Automated gates run on every push to main and fail the build: static analysis of the application code, a vulnerability audit of the Ruby dependencies against the public advisory database, and a check that AI providers are only called through our single AI gateway. The merge commit and the pipeline run are the record of each change.
• Security headers are applied on every response, including X-Content-Type-Options, X-Frame-Options, Referrer-Policy and HSTS. X-Frame-Options is relaxed only on the views customers embed on their own sites, such as forms, hosted pages and email archives. Server identification headers are stripped and cross-site request forgery protection is application-wide.
• Campaign previews are sandboxed so scripts cannot run, and hosted pages, public campaign pages and secure documents carry an enforced content security policy.
• We bundle the open-source libraries our pages use rather than loading them from public content delivery networks. A small number of vendor scripts load from the vendor's own servers: the email editor, Stripe payments, the bot checks on sign-in and forms, and analytics, which can be switched off for an account.
• Cloudflare filters abusive traffic at the edge, and in-application throttles limit sign-in, two-step verification, public forms and API traffic. Sign-up and the password step of sign-in carry a bot challenge.
• The application is assessed annually by an authorized security laboratory under Google's App Defense Alliance CASA program, with remediation and retest before the Letter of Validation is issued. The current Letter is available on request.

6. Sending and abuse prevention

• Sender authentication. Customers authenticate their sending domain by publishing the DNS records we generate, so messages are signed with DKIM and aligned under SPF. We provide DMARC guidance and never overwrite a policy a customer already publishes.
• Suppression. Bounce and complaint feedback from the sending providers is processed automatically, and unsubscribes, bounces and complaints go to suppression lists so those addresses are not mailed again.
• Reputation and abuse. Bounce and complaint rates are checked for each sending lane on a schedule and alert on a change. Campaign content, public forms and hosted pages are screened automatically for phishing and scam patterns, and clear-cut abuse, especially on new accounts, may be restricted automatically and is then reviewed by our team, who can lift the restriction.

Our Terms of Service prohibit purchased, rented and scraped lists, and we enforce that.

7. Monitoring and incident response

Application errors are captured by an error monitoring service and request logs stream to a log management service. Credentials, tokens, one-time codes, card fields and email addresses are redacted from request parameters before they are logged. Logs are searchable for 30 days and archived for 365 days in locked storage, and automated alerts on authentication and rate-limit events go to our security team. An external monitor checks the application from an independent host every 60 seconds, treats two consecutive failures as an incident and alerts until the service recovers. Every sign-in is recorded with country, method, device and a risk score that flags a new country, impossible travel or a datacenter address, and those anomalies are reviewed daily.

We maintain a written incident response policy. If we confirm a security incident affecting a customer's data, we notify that customer's named contacts without undue delay and within 72 hours of confirming it, and follow up with a written summary once it is closed. Where a contract sets different terms, the contract prevails.

8. Business continuity

The application tier is stateless and is redeployed from a container image, so no customer data lives on an application server and a failed instance is replaced rather than repaired.

The managed database runs with continuous protection, giving point-in-time recovery across a rolling window. A daily scheduled backup is enabled, and the platform keeps seven daily backups plus a weekly backup for four weeks. A separate encrypted copy of the daily backup is kept for 30 days in locked storage outside the hosting platform. Our policy requires a restore test at least annually. The most recent test, in September 2026, restored a scheduled production backup into an isolated database in under 20 minutes. Account, contact and content data were restored and checked against production record counts; three analytics and delivery tables were outside the scope of that test.

Our recovery targets are a recovery point objective in minutes within the point-in-time window and 24 hours beyond it, and a recovery time objective of 4 hours for a database restore. These are targets, and the restore test is how we check them.

9. Subprocessors

We use a small number of service providers to run Mailsoftly, and they process personal data only on our instructions. The full list, with each provider's purpose and location, is in Section 10 of our Privacy Policy, which we update when we add or replace a provider.

10. Privacy and compliance

Our Privacy Policy describes what we collect and why, our GDPR Compliance page sets out our roles as controller and processor, our CCPA Privacy Notice covers California residents, and Turkish users can read our KVKK Aydınlatma Metni.

Customer data is hosted and stored in the United States, and we process Customer Content to provide the service and, as described below, to improve it. We do not sell personal information and we do not share it for cross-context behavioral advertising. Deletion follows the lifecycle in Section 3.

AI features. Every AI feature in Mailsoftly runs through a single gateway in our application, and an automated check in the build keeps AI provider calls inside that gateway. The gateway is where AI is switched off for an account.

Mailsoftly may use Customer Content, in de-identified and aggregated form, to improve the service, including training models that power its features. Customers can opt out by writing to [email protected]. Accounts under the Regulated Environment profile are always excluded, and all AI features are switched off for them. Data received from Google or Microsoft through a connected mailbox or sign-in is never used to train models. The AI providers we use are engaged under API terms that exclude customer content from training their own models.

Regulated Environment profile. For public sector and other regulated customers, Mailsoftly sets a Regulated Environment profile on the account by contract. Under it, by default, AI features and connected AI assistant apps are off, API access is off (if the contract enables it, keys must be limited in scope and expire), the editor is limited to our in-house editor, the account neither feeds nor reads cross-account list signals, and abuse screening never restricts the account automatically. Administrators see the profile's state in Settings > Security.

11. Reporting a vulnerability

If you believe you have found a security issue in Mailsoftly, tell us. Our contact details are published at https://app.mailsoftly.com/.well-known/security.txt in the RFC 9116 format, or write to [email protected] with "Security report" in the subject line.

We acknowledge a report within five business days. We ask for responsible disclosure in return: give us a reasonable period to fix the issue before discussing it publicly, do not access, modify or download another customer's data, and do not run tests that degrade the service for others, such as denial of service, spam or brute force testing.

12. Changes and contact

We may update this page as the service changes. When we do, we post the updated version here and revise the date above.

Questions, or requests for our policy documents, the CASA Letter of Validation or our certificate of cyber liability insurance: [email protected], or the request form in our Trust Center.

Albert Solino Corp., doing business as Mailsoftly
Related pages: Privacy Policy, Terms of Service, GDPR Compliance