Swish

Permission-first sending

Email & Messaging Practices

How Swish approaches consent, authentication, unsubscribe, suppression, bounces, complaints and responsible sending through infrastructure including Amazon SES.

Effective 11 September 2026Version 1.1
Production marketing standard

For production marketing sent through Swish-managed infrastructure, recipients must have affirmatively opted in to the relevant marketing or explicitly requested the communication. Possessing an email address is not, by itself, treated as marketing permission.

1. Recipient permission

Customers must send promotional email only to recipients whose permission covers the type of communication being sent. Swish supports confirmation or double-opt-in workflows where configured. Customers remain responsible for the lawful basis for their own communications and for complying with applicable electronic-marketing rules.

Purchased, rented, scraped, harvested and third-party consumer mailing lists are not permitted in the Swish-managed sending programme. Swish is not intended to operate as a cold-email blasting service.

2. Consent and request evidence

Customers should retain evidence of who opted in or requested contact, when the permission was given, the method used, the information shown at the time and the channel/purpose covered. Where the relevant workflow is used, Swish can retain marketing-permission, confirmation and activity state with the contact.

3. Sender authentication

Production sending identities must be verified and authenticated. Swish supports domain controls such as DKIM, SPF/custom MAIL FROM and DMARC alignment where configured. Customers must not spoof or misrepresent another organisation’s domain or identity.

4. Sender identity and content

Messages should clearly identify the sending business and use accurate subjects, sender names and content. Customers should send the type of information the recipient signed up for or requested and should avoid misleading, manipulative or materially different content.

5. Unsubscribe and suppression

Marketing emails must provide a clear and functioning opt-out route. Swish records supported unsubscribe events and uses suppression controls to prevent future marketing where an address has opted out. Customers must not re-import or otherwise circumvent a valid suppression unless the recipient later provides fresh, appropriate permission.

6. Bounces and complaints

Swish processes supported delivery, bounce and complaint events from the email provider. Hard-bounced addresses and complaint events are used to suppress further marketing. Customers should investigate abnormal complaint/bounce rates and should not repeatedly retry addresses that have failed or complained.

7. Tenant and workspace separation

Swish is a multi-tenant platform operated centrally by Modern Synergy Limited. Where supported by the provider, customer sending identities, configuration, suppression and reputation controls are separated by tenant/workspace so independent organisations do not become one unrestricted shared mailing list.

8. Sending volume and reputation

New sending identities should begin with controlled, appropriate volumes and increase responsibly. Customers should avoid sudden high-volume sends to old, unengaged or poorly evidenced recipients. We may impose operational limits or require remediation where deliverability indicators create risk to recipients, providers or the Swish service.

9. Transactional and service messages

Transactional, security and service messages should be limited to the purpose that triggered them. They must not be disguised marketing. If promotional content is included, the applicable marketing and opt-out requirements still apply.

10. Questions or abuse reports

Questions about Swish-managed sending, recipient permission or suspected abuse can be sent to hello@swish.click.