Skip to main content
MyShield
Get started free
Technical Docs

How MyShield works

A complete technical reference covering the email aliasing pipeline, DNS configuration, security model, header handling, and infrastructure behind myshield.world.

Last updated: 6 May 2026 Questions? Contact us →

1. System overview

MyShield is an email aliasing and forwarding service. When you create an alias such as [email protected], any email sent to that address is received by MyShield's mail infrastructure, processed through a filtering and rewriting pipeline, and forwarded on to your real email address, without the original sender ever learning what that address is.

The system is intentionally stateless with respect to message content: MyShield does not store the body or attachments of any email. The pipeline is designed for low latency, high deliverability, and sender privacy.

2. Alias architecture

Every alias is a valid RFC 5321 mailbox address of the form <local-part>@myshield.world. The local-part is a randomly generated or user-chosen string of 6–30 characters, constrained to lowercase letters, digits, dots, hyphens, and underscores.

Aliases are stored in a database keyed by their full address. Each alias record holds:

  • Destination address: the real inbox to forward to (encrypted at rest)
  • Status: active, paused, or deleted
  • Label: an optional user-supplied human-readable name
  • Created at timestamp
  • Message count: a running count of forwarded messages (no message content is stored)

Note: Alias local-parts are not case-sensitive at the SMTP level. All inbound addresses are normalised to lowercase before lookup.

3. DNS configuration

MyShield operates two separate mail paths — one for @myshield.world aliases (managed entirely through Cloudflare) and one for custom domain aliases (routed to a self-hosted SMTP server).

myshield.world — built-in aliases

Inbound mail for @myshield.world aliases is handled by Cloudflare Email Routing. No traditional MX server is involved for these addresses. Email authentication records for outbound forwarded mail are:

SPF

myshield.world.   IN  TXT  "v=spf1 include:_spf.mx.cloudflare.net ip4:145.241.186.212 ~all"

DMARC

_dmarc.myshield.world.   IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"

Custom domains — user-supplied domains

When a user adds a custom domain (e.g. yourdomain.com), inbound mail is routed to MyShield's dedicated SMTP server at mail.myshield.world (A record: 145.241.186.212). Three DNS records must be added to the custom domain:

Required DNS records — custom domain

; Route inbound mail to MyShield
yourdomain.com.               IN  MX   10  mail.myshield.world.

; Domain ownership verification
_myshield.yourdomain.com.     IN  TXT  "myshield-verify=<token>"

; DKIM public key (auto-generated per domain)
myshield._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=<public-key>"

DKIM keypair: A unique RSA-2048 DKIM keypair is automatically generated when a custom domain is added. The public key is shown in the dashboard for copy-paste into DNS. The selector is always myshield. The domain must be verified before aliases can be created on it.

4. Inbound mail pipeline

MyShield operates two entirely separate inbound paths depending on the alias domain. Both paths converge on the same processing webhook after initial reception.

Path A — @myshield.world aliases (Cloudflare)

Mail addressed to [email protected] is received by Cloudflare's Email Routing infrastructure. A Cloudflare Worker validates the recipient and posts the raw message to POST /api/webhooks/email-forward on the MyShield application server.

Path B — Custom domain aliases (self-hosted SMTP)

Mail addressed to [email protected] is routed via the domain's MX record to mail.myshield.world (port 25). A lightweight Node.js SMTP server handles the connection with STARTTLS. During the RCPT TO phase it calls GET /api/alias-lookup/:address to validate the recipient — unknown or paused aliases are rejected at the protocol level with 550 No such recipient, preventing the message body from being transferred. Accepted messages are collected and posted as raw RFC 5322 bytes to the same POST /api/webhooks/email-forward webhook used by Path A.

Common processing (both paths)

Once the webhook receives the raw message it applies the same pipeline regardless of source:

  • Alias lookup: the recipient address is resolved to the user's real inbox. Paused aliases result in the message being silently dropped.
  • Header rewriting: headers are modified before forwarding (see Section 5).
  • Forward dispatch: the rewritten message is delivered to the destination inbox via the outbound relay.

5. Header handling

Preserving end-to-end deliverability while hiding the destination address requires careful header management. The following transformations are applied:

Before forwarding (original headers)

From:    [email protected]
To:      [email protected]
Subject: Your order is ready
...

After rewriting — Free plan

From:             [email protected]
To:               [email protected]
Reply-To:         [email protected]
X-Forwarded-To:   [email protected]
X-MyShield-Alias: [email protected]
Subject:          [[email protected]] Your order is ready
...

After rewriting — Pro / Business plan (reply-from-alias enabled)

From:             [email protected]
To:               [email protected]
Reply-To:         [email protected]
X-Forwarded-To:   [email protected]
X-MyShield-Alias: [email protected]
Subject:          [[email protected]] Your order is ready
...

Reply behaviour: For Free accounts, your real address is exposed if you reply directly to a forwarded email. For Pro and Business accounts, MyShield automatically generates a stable Reply Route (Reverse Alias) for every new sender. When you receive a forwarded email, the Reply-To address is set to a unique address like [email protected]. Hitting Reply sends your message to this stable route, which MyShield intercepts and re-sends from your alias. Your real email address is never revealed, and the route remains the same for that specific alias-sender pair forever.

The envelope sender (MAIL FROM) is rewritten to a bounce address on the myshield.world domain using Sender Rewriting Scheme (SRS). This ensures that DKIM and SPF checks on the forwarded message pass at the receiving mail server, substantially improving deliverability.

6. Spam and threat filtering

MyShield applies a multi-layer filtering approach to protect both the forwarding infrastructure and the destination inboxes of users:

  • IP reputation checks: the connecting SMTP server's IP is validated against real-time blacklists (RBLs) before the message body is accepted.
  • SPF / DKIM / DMARC validation: inbound messages are authenticated against the originating domain's published records. Failures do not automatically reject the message but contribute to the composite spam score.
  • Content heuristics: header structure, link density, and known spam fingerprints are evaluated.
  • Attachment scanning: attachments are scanned for known malware signatures. Infected attachments are stripped and replaced with a plain-text notice before forwarding.

MyShield does not provide per-alias spam configuration beyond the ability to pause or delete an alias. If an alias is receiving unwanted mail, pausing it immediately stops all further forwarding.

7. Security and encryption

Security is applied at multiple layers across the pipeline:

Transport encryption

All SMTP connections, both inbound and outbound, require TLS 1.2 or higher. Opportunistic TLS is attempted for all outbound connections; if the destination server does not support TLS, the message is delivered over a plaintext connection (this is standard SMTP behaviour and cannot be avoided without breaking deliverability to legacy servers).

Stored data encryption

The destination email address associated with each alias is encrypted at rest using AES-256. The encryption key is not stored in the same system as the alias database.

Authentication

MyShield supports two sign-in methods: email + password and Google OAuth 2.0. Email/password accounts use bcrypt-hashed passwords (cost factor 12). Password reset tokens are single-use, time-limited (1 hour), and stored as SHA-256 hashes — the raw token is never persisted. Google OAuth accounts are linked by verified Google account ID; no password is stored for these accounts. All authenticated sessions are issued as short-lived JWT Bearer tokens stored in HttpOnly cookies for enhanced security.

Web application

The myshield.world web application enforces HTTPS-only via HSTS, sets Secure and HttpOnly flags on session cookies, and applies a strict Content-Security-Policy header to mitigate XSS.

8. Alias lifecycle

An alias moves through a defined set of states:

  • active, forwarding is enabled; inbound messages are processed normally.
  • paused, the alias exists in the database and DNS continues to resolve, but inbound messages are silently dropped at Stage 1 of the pipeline (no bounce is sent to the sender). Useful for temporarily stopping mail without losing the alias address.
  • deleted, the alias record is soft-deleted. The address is reserved for 30 days to prevent accidental re-registration by the same account, then permanently removed. After permanent removal the address becomes available again.

Plan downgrade behaviour: If a paid account downgrades to Free and holds more than 3 aliases, aliases above the limit enter a 48-hour grace period in paused state. After 48 hours they transition to deleted unless the account is upgraded again. Downgrading from Business to Pro reduces the alias limit from 50 to 20; aliases above 20 follow the same grace-period process.

9. Account features

Beyond basic forwarding, all plan tiers include a set of alias management tools accessible from the account dashboard at /account.html.

Custom labels

Every alias can be assigned a human-readable label (e.g. "Shopping", "Newsletter"). Labels are stored server-side and displayed in the dashboard to help you identify where mail is coming from at a glance. Adding and editing labels is a Pro and Business feature.

Pause & resume

Any alias can be paused from the dashboard. When paused, inbound messages are silently dropped at Stage 1 of the pipeline — no bounce is sent to the sender and the alias address remains reserved. Resuming the alias instantly restores forwarding. Pause & resume is a Pro and Business feature.

Custom domain support

Pro and Business subscribers can associate a custom domain with their account, enabling aliases of the form [email protected] instead of @myshield.world. Custom domains require a Pro or Business plan.

When a domain is added, MyShield automatically generates a unique RSA-2048 DKIM keypair for it. Three DNS records must then be added to the domain before it can be verified and used:

  • MX record pointing to mail.myshield.world (priority 10) — routes inbound mail to MyShield's SMTP server.
  • TXT record at _myshield with a unique verification token — proves domain ownership.
  • TXT record at myshield._domainkey with the DKIM public key — enables DKIM signing of outbound replies.

All three records are shown in the account dashboard with copy-paste values. The domain can be verified once DNS has propagated. Any existing MX records for the domain (e.g. from a prior email hosting provider) must be removed — conflicting MX records at the same priority cause sending servers to deliver to the wrong destination.

Reply from alias

Pro and Business subscribers can reply to any forwarded email directly from their email client without exposing their real address or revealing that they use an aliasing service. The mechanism uses stable Reply Routes (Reverse Aliases):

  1. When a message is forwarded to the user, the server checks for an existing Reply Route for that specific pair of alias address and original sender. If one doesn't exist, it generates a unique Reverse Alias (e.g., [email protected]) and stores it in the reverse_aliases table.
  2. The forwarded email's Reply-To header is set to this stable Reverse Alias.
  3. The user hits Reply in their email client. The client addresses the reply to the Reverse Alias address — no special steps required.
  4. Cloudflare's email worker receives the reply, calls GET /api/alias-lookup/[email protected], which identifies the route and returns the user's real email so the worker accepts the message.
  5. The worker posts the raw reply body to POST /api/webhooks/[email protected]. The server detects the ra. prefix and performs a reverse lookup.
  6. The server extracts only the user's actual reply text from the email body, discarding all quoted content the email client appended. It then reconstructs a clean, standard-format quoted section from the stored original message data — no MyShield branding, no forwarding metadata, no service reveal. The real email address is also scanned for and redacted from both the reply text and the reconstructed quote as a final safety gate.
  7. The reply is sent from the alias address to the original sender. The outbound path differs by alias type:
    • @myshield.world aliases: sent via Resend SMTP. From: [email protected].
    • Custom domain aliases: sent via a local Postfix instance on 127.0.0.1:587, DKIM-signed using the domain's auto-generated private key (selector myshield). The envelope sender (MAIL FROM) is set to [email protected] so SPF passes, while the From header shows [email protected]. DMARC passes via DKIM alignment — the original sender sees a reply from your custom domain with no indication that a forwarding service is involved.

Unlike legacy tokens, Reply Routes are stable and linked to your account. You can manage and revoke active routes from your account dashboard if you want to stop a specific sender from reaching you through that route.

Message counter

Each alias displays a running count of forwarded messages. This counter is incremented server-side on each successful forward and is visible in the dashboard. No sender, subject, or body information is stored — only the integer count.

Alias creation cooldown

Free plan accounts have a short cooldown between alias creations to prevent abuse. Pro and Business accounts have no cooldown.

10. Payments & billing

MyShield uses PayFast as its payment gateway — South Africa's leading online payment processor. All card details are entered directly on PayFast's PCI-DSS compliant hosted pages; MyShield never sees or stores card information.

Subscription model

Pro and Business plans are billed as monthly recurring subscriptions. On checkout, a PayFast recurring billing agreement is created. The first payment is taken immediately; subsequent payments are collected monthly on the same calendar date.

Checkout flow

Clicking an upgrade button redirects to /checkout.html?plan=pro or /checkout.html?plan=business, where the plan details and amount are reviewed. Clicking Pay calls POST /api/create-checkout, which generates a signed PayFast form and redirects the browser to PayFast's secure hosted payment page. On successful payment, PayFast sends an Instant Transaction Notification (ITN) to /api/payfast/itn and the user's account is upgraded immediately.

Pricing

  • Pro: R75.00 / month — 20 aliases, labels, pause/resume, reply from alias, custom domains, priority support
  • Business: R149.00 / month — 50 aliases, all Pro features

Cancellation

Subscriptions can be cancelled at any time from the account dashboard. On cancellation, the recurring billing agreement is terminated at PayFast and the account reverts to the Free plan at the end of the current billing period. No refunds are issued for partial months.

11. Data retention

MyShield is designed to hold as little data as possible:

  • Email content: never stored. Messages are processed in-memory through the pipeline and dispatched. No body, subject, attachment, or header beyond the routing metadata is written to disk.
  • Message counts: a per-alias integer counter is incremented on each forward. No timestamps or sender information accompany this count.
  • Account data: email address, hashed password, plan status, and alias records are retained for as long as the account is active. On account deletion, all records are permanently purged within 14 days.
  • SMTP logs: connection-level logs (IP, timestamp, envelope addresses) are retained for 14 days for abuse investigation, then deleted.

12. Plan limits and rate limits

The following hard limits apply per account:

Plan comparison

Plan        Price      Aliases   Labels   Pause/Resume   Reply from Alias   Custom Domain   Priority Support
────────────────────────────────────────────────────────────────────────────────────────────────────────────
Free        Free           3       No          No                No                No               No
Pro         R75/mo        20      Yes         Yes               Yes               Yes              Yes
Business    R149/mo       50      Yes         Yes               Yes               Yes              Yes

Rate limits are applied at the alias level to protect destination inboxes and the forwarding infrastructure:

  • Inbound rate limit: 200 messages per alias per hour. Messages exceeding this limit are deferred (4xx) at the SMTP level, causing the sending server to retry.
  • Burst limit: 30 messages per alias per minute. Sustained bursts above this threshold trigger automatic temporary alias suspension.
  • Account-level limit: 2 000 messages per account per day across all aliases.

13. Support

For technical questions not covered in this documentation, contact the MyShield team at [email protected] or via the contact page. Include your alias address (not your real email) and a description of the issue when reporting a deliverability problem.

Abuse reports, including spam originating from forwarded MyShield addresses, should be sent to [email protected] with the full message headers attached.