Privacy Policy

1. Who we are

MailLoyal is an independent application. The developer is the data controller for the little that this policy describes, and can be reached at mehmetali@creativetorontonian.ca.

MailLoyal operates no servers of any kind. There is no MailLoyal account to create, no sign-up, no login to us, and no way for us to identify you.

2. What MailLoyal stores on your device

All of the following is stored only on the device, in the app’s private storage, and is removed when you delete the app.

MailLoyal does not read your device address book, your photo library (beyond the single image you pick to attach), your location, your calendar, your call or message history, your advertising identifier, or any other app’s data.

3. What leaves your device, and to whom

There are five possible destinations. None of them is a MailLoyal server.

3.1 Your mail server

Everything a mail client normally sends: your username and password at login, the commands to list and fetch mail, the messages you send, and the flags you change. The connection is always encrypted — MailLoyal tries implicit TLS first, then STARTTLS, and if neither is available it stops and tells you. MailLoyal never falls back to an unencrypted connection, so your password is never transmitted in the clear.

Your mail provider’s own privacy policy governs what they do with that data.

Sending a signature by email (Signatures → Send by email) is one of the messages you send: it goes from your own account through your own mail server, to the address you choose, like any other message. It contains the signatures you picked, shown in the email and repeated in a small attached file, MailLoyal-signatures.json, plus the note you typed, if any. Nothing goes through a MailLoyal server. When an email like that reaches you, MailLoyal reads only that attached file, from your own mail server, and only into memory; nothing is added to your signatures until you review it and press Add, and a signature from an email never becomes your default on its own. On the review screen its logo — which loads from a web address the sender chose, and so tells that site when it is shown — stays hidden until you allow it. The email itself follows your image setting (§4), like any other message.

3.2 Automatic server discovery (setup only)

When you add an account, MailLoyal tries to work out your server settings for you. Over HTTPS it may request the addresses below, in this order. The lookup made while you type your address stops at the first one that answers; the step-by-step connection check may ask all three:

1. https://autoconfig.thunderbird.net/v1.1/<your-domain> — the Mozilla ISPDB, a public directory of mail-server settings run by Mozilla. Only your email domain is sent (for example example.com), never your full address and never your password.
2. https://autoconfig.<your-domain>/mail/config-v1.1.xml?emailaddress=<your address>
3. https://<your-domain>/.well-known/autoconfig/mail/config-v1.1.xml

Steps 2 and 3 go to your own mail domain — the same organisation that runs your mailbox. Step 2 includes your full email address because that is what the autoconfig standard specifies; it is sent to your own provider, not to us.

These requests happen only while you are adding an account, never afterwards. If you type your server settings in by hand, none of them are made.

3.3 The AI features — only if you turn them on

Every AI feature is off by default. There are four of them — signatures, reply drafting, writing new emails, and the writing tools that rewrite what you have already written — and they send different things, so they have separate switches and separate consent. Turning one on never turns another on.

They run on your own API key. MailLoyal has no AI key and no AI service of its own. You enter a key in Settings → AI assistant; it is stored in this device’s keychain, and requests go straight from your device to the provider you chose — Anthropic or OpenAI. They do not pass through any MailLoyal server, because there isn’t one.

That provider is your own account under your own key, and their terms and privacy policy govern the request.

Without a key, signature generation falls back to built-in offline templates and makes no network request at all, and neither reply drafting, writing new emails nor the writing tools are offered — nothing can draft a reply to a message it cannot read, and there is no offline stand-in for writing one, or for rewriting one, either.

Signature generation sends only the fields you typed into the signature form: your name, job title, company, phone number, website, email address, any extra lines and disclaimer you entered, and the tone you picked. If you entered a logo URL, the app downloads that image on your device and sends it along too, so the signature can use your brand’s colours; the download goes only to the address you typed, and an image that is not a PNG, JPEG, GIF or WebP under 3 MB is simply left out.

Update with AI, in the signature editor, sends that signature’s HTML, the change you typed, and the logo image as above — to the vendor of your own key, and only when you press Update. The result comes back into the editor; nothing is saved until you press Save.

Reply drafting writes a first draft of a reply from the conversation and the notes you type. When you press Write the draft, it sends:

• the text of the message you are replying to, its subject and date, and the sender’s display name;
• unless you switch off Use earlier messages for that draft, the text of up to 6 earlier messages in the same conversation, with their authors' display names and dates — or, when those messages are not on this device, the history quoted at the bottom of the message you are replying to, with the email addresses in its attribution and header lines removed;
• the display names of the people the reply is addressed to (for example "Grace Hopper and 2 others");
• your notes, the tone and length you chose, today’s date, and — if you leave Use what you’ve written on — whatever you had already typed in the reply;
• your own display name, only when no signature is attached, so the draft can sign off with it.

This is the one place MailLoyal sends something you did not type yourself, so it is worth being exact about what it does not send and how it decides:

• Quoted history is removed from each message before sending, so every message goes once rather than as copies of copies. Text hidden in a message’s formatting, and invisible characters, are removed too.
• Email addresses are not sent as names: someone without a display name is "a correspondent". We do not send headers, attachments, which account you are using, or anything from other conversations.
• An earlier message goes along only if the person you are replying to took part in it, and never from your Drafts, Spam or Trash. A message counts as yours only if its copy is in your Sent folder.
• The draft comes back into the compose editor for you to read and change. Nothing is ever sent on your behalf, and a gap the draft left for a fact it did not know — shown in [square brackets] — is highlighted, and Send asks before it goes out unfilled.
• The messages were written by other people, who have not agreed to any of this. That is why the feature is off until you turn it on, why its consent is separate from signatures and names where the messages will go, why switching AI provider asks again, and why we send as little as the draft needs. You can turn it off in Settings → AI assistant.

MailLoyal never sends your mailbox password, your contacts, your folder list, or any message outside the conversation you chose to reply to.

Writing new emails turns your notes into a first draft of a new message. It is its own switch, with its own consent screen naming the provider; agreeing to reply drafting does not turn it on, and it does not turn reply drafting on. It needs a key of your own. When you press Write the draft, it sends:

• your notes, the tone and length you chose, and today’s date;
• the subject, if you have written one (otherwise the draft suggests one, and only an empty subject is ever filled in);
• the display names of the people in To and Cc — never their email addresses, never anyone in Bcc, and never your own address;
• if you leave Use what you’ve written on, whatever you had already typed in the message;
• your own display name, only when no signature is attached.

It sends no mail from your mailbox — nothing anyone else wrote. As with replies, the draft comes back into the compose editor for you to read and change, gaps it left for facts it did not know are highlighted, and nothing is ever sent on your behalf. You can turn it off in Settings → AI assistant.

The writing tools — Improve writing, Make it shorter, Fix spelling and grammar, Change tone and Translate, in the editor’s toolbar — take the message you have already written and hand it back rewritten. They are their own switch, with their own consent screen naming the provider; agreeing to any of the other three does not turn them on, and they turn none of the other three on. They need a key of your own. When you choose one of them, they send:

• the text in the editor — the formatted message, or the plain one if you are writing in plain text;
• which tool you chose, and with it the tone you picked for Change tone, the language you picked for Translate, or — for Update — what you typed asking for the change.

That is the whole request. No subject, no recipients, no message you are replying to, no quoted conversation, and nothing else from your mailbox. What you wrote is sent as you wrote it, and it is not shortened first, because the rewrite comes back in place of all of it — so if you have pasted someone else’s words into the message, or had AI draft a reply into it, those words are part of what goes.

Nothing is sent until you choose one of the tools. The rewrite comes back into the editor for you to read and change, a single Undo puts your own words back, and nothing is ever sent on your behalf. You can turn the tools off in Settings → AI assistant.

MailLoyal keeps no copy of any of this, because none of it reaches us.

3.4 Google Mobile Ads — iOS and Android

The iOS and Android versions load an app-open ad during a cold launch, a native ad at the top of the inbox and a banner under the message you are reading. The Android version can also load a rewarded interstitial, shown only after you choose Pause ads in Settings → Privacy. Completing that optional ad hides the banner and native ad for 30 minutes; cancelling it does not restrict any feature. Returning to the app from the background does not request an app-open ad. The Mac version shows no ads and does not contain Google’s ad SDK. If you remove ads (§3.5), none of what this section describes happens: no ad is requested, Google’s privacy message is not shown, and Google’s ad SDK is not started.

Every ad request is explicitly marked non-personalized. On iOS, MailLoyal does not ask for App Tracking Transparency permission. On Android, it removes the permission Google’s ad SDK needs to read your device’s advertising ID, so the SDK receives a string of zeros instead; Google may still receive the app set ID — an identifier Android gives the apps of one developer on one device — and, where applicable, identifiers related to accounts signed in on the device. MailLoyal does not receive your advertising profile or the data Google processes. Google and participating ad providers may process device and advertising identifiers, coarse location inferred from your IP address, ad views and interactions, and diagnostic or performance data for ad delivery, measurement, fraud prevention, frequency capping, and reporting. Google’s privacy policy and the choices presented by its User Messaging Platform govern this processing.

Where required, MailLoyal asks Google’s consent service for the current privacy message before requesting an ad. If consent does not permit an ad request, no ad is requested. When Google requires a persistent privacy-options entry point, it appears under Settings → Privacy → Ad privacy choices.

3.5 Removing ads — iOS and Android

The iOS and Android versions offer two ways to remove their ads, under Settings → Remove ads: a monthly subscription and a one-time lifetime purchase. On iOS they are bought from Apple, on Android from Google Play. The Mac version shows no ads, so nothing is sold there.

On iOS:

• Purchases are made with Apple, through the App Store, with your Apple Account. Your payment details go to Apple, never to MailLoyal, and Apple’s own terms and privacy policy govern the payment.
• MailLoyal receives no purchase information. It has no server, so there is nowhere for your purchase, your Apple Account or your payment method to be sent, and nothing is.
• The app asks StoreKit — Apple’s purchase system, on your device — whether ads have been removed. Apple checks the purchase on the device itself. The app keeps that answer in its local preferences: which plan, when it was bought, when the paid period ends, whether it renews and whether it came from a promo code, and no payment data — only so that the launch ad does not flash on screen before the App Store has answered. It also keeps the time it last offered to remove the ads, so that offer appears at most once every three weeks. Both are removed with the app.
• Restore purchases asks the App Store for purchases already made with your Apple Account — on another iPhone or iPad, or before reinstalling — and may ask you to sign in to that account.
• Promo codes are typed on the App Store’s own code sheet (Enter code on the Remove ads screen) and checked and redeemed by Apple. MailLoyal never sees the code. What a code grants belongs to your Apple Account like a purchase, and the app notes only that it came from a code.
• Subscriptions are managed and cancelled with Apple, in your Apple Account settings (on iPhone: Settings → your name → Subscriptions) or from Manage subscription on the Remove ads screen. Getting the lifetime plan — bought or from a promo code — does not cancel a subscription; cancel it there so you are not charged again. The Remove ads screen keeps showing Manage subscription while it still renews. Refunds are handled by Apple.

On Android:

• Purchases are made with Google Play, with your Google account. Your payment details go to Google, never to MailLoyal, and Google Play’s own terms and Google’s privacy policy govern the payment.
• The app sends no purchase information anywhere. It has no server, so there is nowhere for your purchase, your Google account or your payment method to be sent, and nothing is. As the seller, though, MailLoyal’s developer receives Google Play’s own record of each order in Google Play Console — such as the order number, the product, the price, the date and the country of purchase — as Google provides it to every seller on Google Play, and uses it only to handle refund requests and for accounting. It never includes your payment details.
• The app asks Google Play Billing — Google Play’s purchase system, on your device — whether ads have been removed, and checks Google’s signature on each purchase on the device itself. The app keeps that answer in the same local preferences as on iOS: which plan, when it was bought, whether it renews, whether it came from a promo code and when Google Play last confirmed it, and no payment data. Google Play does not tell the app when a paid period ends, so no end date is kept; instead an answer Google Play has not confirmed for a while stops counting. As on iOS, it is kept only so that the launch ad does not flash on screen before Google Play has answered. It also keeps the time it last offered to remove the ads, so that offer appears at most once every three weeks. Both are removed with the app.
• Purchases are confirmed to Google Play, which refunds one an app has not confirmed within three days. The app does it when it sees a purchase, and also every twelve hours in the background, when there is a network, so that a payment that clears or a promo code redeemed while MailLoyal is closed is not refunded. It only asks Google Play what is owned and tells it which purchases it has honoured; nothing else is sent.
• Restore purchases asks Google Play again for the purchases made with your Google account — on another Android device, or before reinstalling.
• Promo codes are typed on Google Play’s own redeem page (Enter code on the Remove ads screen opens it) and checked and redeemed by Google. MailLoyal never sees the code. What a code grants belongs to your Google account like a purchase, and the app notes only that it came from a code.
• Subscriptions are managed and cancelled with Google Play, in Google Play under Payments & subscriptions → Subscriptions, or from Manage subscription on the Remove ads screen. Getting the lifetime plan — bought or from a promo code — does not cancel a subscription; cancel it there so you are not charged again. The Remove ads screen keeps showing Manage subscription while it still renews. Refunds are requested from Google Play first; after 48 hours Google Play may direct you to the developer, who can refund an order from Google Play Console.

When ads are removed, on either platform, the app requests no ads, does not show Google’s privacy message, and does not start Google’s ad SDK, so none of the processing described in §3.4 takes place. If you remove ads while the app is open, the inbox ad and the banner disappear at once and the rest applies from the next launch: the ad SDK that session already started stays loaded until the app is closed, though nothing more is requested from it.

4. What we never do

• No MailLoyal analytics. No Firebase, Sentry, Crashlytics, or analytics service is integrated by the developer. Google receives the limited ad delivery and measurement data described in §3.4 on iOS and Android.
• No crash reporting to us. If iOS or Android offers to send Apple or Google a crash report, that is the operating system’s own feature and its own policy, not ours; we receive nothing from it. On iOS, automated Google Mobile Ads SDK crash reporting is disabled; on Android the SDK has no setting to turn it off, so it may send Google reports of its own crashes.
• No cross-app tracking permission. The iOS app does not request access to Apple’s IDFA, the Android app removes the permission to read the advertising ID, and all ad requests are non-personalized.
• No MailLoyal account, no cloud sync. Your accounts exist only on the device you set them up on.
• No selling of data. We hold no copy of your data. The ad disclosures in §3.4 describe the data processed by Google to operate advertising.
• No remote images in Spam without asking. In Spam, where a tracking pixel is the likeliest thing in a message, remote images stay blocked until you allow them, so opening it does not silently tell the sender you read it. Elsewhere they load when you open a message, unless you turn on Settings → Privacy → Ask before loading images, which blocks them in every folder. You can allow images per message or per sender.

5. Notifications

Notifications are generated on your device by the app itself, from mail the app fetched. There is no push server, no Firebase Cloud Messaging, no Apple Push Notification payload from us, and therefore no third party that learns when mail arrives for you.

MailLoyal asks before it turns notifications on. If you choose Not now, they stay off — and nothing checks for mail in the background — until you turn them on in Settings → Notifications.

On Android, MailLoyal can hold an open connection to your mail server in the background to notice new mail promptly; Android shows an ongoing notification, "MailLoyal is watching for mail", for as long as it does. It runs only while new-mail notifications are on, you have allowed MailLoyal’s notifications, and at least one account is set to notify you; turning notifications off stops it at once. That connection goes only to your own mail server, the same one the app syncs with. When Android’s daily allowance for it is used up (six hours on Android 15 and later), or after your phone restarts, MailLoyal checks for new mail every 15 minutes instead.

On iOS a connection like that is not possible, so MailLoyal uses the system’s Background App Refresh — which is why the iOS interface says Fetch, never "Push", and why iOS notifications can be delayed by the operating system. On a Mac, MailLoyal checks for mail only while it is open.

6. Children

MailLoyal is a general-purpose mail client and is not directed at children. It has no child-directed features. The advertising described in §3.4 is configured for non-personalized delivery; parents and guardians should review the Google privacy choices available in Settings → Privacy.

7. Your rights, and how to exercise them

Because everything lives on your device, you exercise every right directly:

• See your data — it is all in the app.
• Correct it — Settings → the account, or the message itself.
• Delete one account — Settings → the account → Remove account from this device. This deletes its rows from the local database, its cached bodies and attachments, and its passwords from the system keychain, immediately.
• Delete everything — remove each account, delete your AI key in Settings → AI assistant, then uninstall the app. The system removes the app’s container, its database and its caches with it. It may keep keychain items after an app is deleted, which is why removing the accounts and the key first matters.
• Take it elsewhere — your mail is on your mail server, in a standard format, reachable from any IMAP client.

Deleting data in MailLoyal does not delete mail from your mail server; use your provider’s tools for that. Removing an account from MailLoyal removes only the local copy and the stored credentials.

We cannot action a deletion or access request on your behalf because we hold no copy of anything. If you write to mehmetali@creativetorontonian.ca we will say exactly that.

8. Security

• Passwords and API keys are stored only in the platform keychain (the iOS Keychain, protected until first unlock and not synced off the device; the macOS Keychain; the Android Keystore, with MailLoyal left out of Android’s backups), never in the database or in preferences, never in a log, never in a diagnostic you can copy.
• Every mail connection is TLS-encrypted. There is no "ignore certificate errors" switch anywhere in the app. If a server presents a certificate that cannot be validated, MailLoyal stops, shows you the fingerprint, and asks — and remembers your decision for that one host and port only.
• HTML in messages and signatures is sanitised before it is displayed or sent: scripts, frames and forms are removed, and remote images follow the rule in §4. A signature that arrives in a file or an email is treated as untrusted: it is rebuilt from an allowlist; text hidden by styling — made invisible, transparent, tiny, or coloured like its background — is made visible; and you see it, where its links lead and where its logo loads from before you choose to add it.
• MailLoyal itself uploads no backup of your data anywhere. On Android it opts out of Android’s backup and of device-to-device transfer, so neither a Google backup nor a move to a new phone copies your mail, settings or passwords; on a new phone you add your accounts again. On iPhone, iPad and Mac, your device’s own backup — iCloud Backup, or a backup to your computer — may include the mail and settings MailLoyal keeps on the device, under the terms of whoever stores that backup.

No system is perfect, and MailLoyal cannot protect data once it reaches your mail provider or an AI provider you chose.

9. Changes to this policy

If this policy changes, the date at the top changes with it and the current text is always at https://mailloyal.com/privacy, which the app links to from Settings → Privacy → Privacy Policy. A change that would send anything new off your device will also be announced in the app before it takes effect.

10. Contact

Questions about this policy: mehmetali@creativetorontonian.ca.

11. This website

This website sets no cookies, runs no analytics and loads nothing from any other website: its fonts, styles and scripts are all served from here. If you choose a colour theme, the choice is kept in your browser’s local storage and is never sent to us.

Like any website, the server that hosts it may keep standard request logs — an IP address, the page asked for, the time and the browser — for security and to keep the site running. They are not used to identify or follow anyone.