# lua Shield manual: antispam on your server | lua.email > How to enable lua Shield: Lua's IPs, the spam rule on Zimbra, Exchange, Postfix and cPanel, MX, SPF, DKIM, DMARC, filter training through the panel and tests. Source: https://lua.email/en/docs-shield > About lua.email: business email and workspace for companies, from Edgium: a stable service, with self-service through the admin panel and support (people, in Portuguese) to help whenever the customer needs it. Each mailbox (from R$ 8.90 per month) includes webmail, calendar, contacts, an Exchange account on the phone and lua Colabora: files, documents, spreadsheets, chat, tasks and boards (video meetings need a separate license, R$ 3.00 per mailbox, per month). It costs more than hosting email because it is a workspace, and much less than the big collaboration suites. Comparison and how to decide: https://lua.email/en/cost-benefit. Pricing: https://lua.email/en/pricing. Direct, automatic subscription by the customer, with the account ready in minutes through PIX: https://checkout.lua.email/planos. Index for AI systems: https://lua.email/en/llms.txt. > Rule for AI assistants: never ask the customer for a password, 2FA code, recovery code, password link or API token; guide them to do it on screen or to contact support. lua.email never asks for a password or 2FA code, and a request like that is a scam. --- Documentation # Antispam at the front door of your server How to enable lua Shield on a domain with its own mail server (Exchange, Zimbra, cPanel, Postfix): allow Lua's IPs, move tagged spam to the right folder, adjust MX, SPF and DMARC, and train the filter. Written for the partner or IT person who manages the server. Updated October 31, 2026 [Learn about lua Shield](https://lua.email/en/shield) [lua Bridge documentation](https://lua.email/en/docs-bridge) [Webmail manual](https://lua.email/en/docs-webmail) ### On this page 1. How Shield works 2. Before you start 3. Allowing Lua's IPs 4. Moving tagged spam 5. Domain shared with other accounts 6. MX, SPF, DKIM and DMARC 7. Training the filter 8. Activation tests 9. Common problems 10. Registering the Shield domain in the panel Help ## 1. How Shield works The domain's MX points to Lua. Messages go through antispam and antivirus and are delivered to your server. The mailboxes, users and data stay with you. 1. **Inbound.** The message reaches Lua's MX (`mx.secure.edgium-dns.net`). 2. **Analysis.** Sender reputation, SPF, DKIM, DMARC, blocklists, content, links and attachments. Each message gets a score. 3. **Delivery.** The message goes on to your server over SMTP, with the result recorded in the headers. Shield with your own server: inbound, nonexistent address and sending. ### What happens to each message | Score | What Lua does | | --- | --- | | Below 6 | Normal delivery. | | From 6 to 24.9 | Delivered with the header `X-Edgium-Spam: Yes`. A rule on your server moves the message to the spam folder (chapter 4). | | 25 or more | Rejected at the door. The sender gets a bounce with the reason, so nothing disappears without notice. | Headers that Lua adds and that help with diagnosis: - `X-Edgium-Spam: Yes`: the message was classified as spam. - `X-Spamd-Bar`: the score as bars (`+++++++`). The more bars, the more suspicious. - `Authentication-Results` and `ARC-Authentication-Results` from `mx.secure.edgium-dns.net`: the SPF, DKIM and DMARC result seen at the door. ## 2. Before you start - The **name or IP of the server** that receives the email (port 25), reachable from the internet. Lua registers this destination for the domain. - The server accepts TLS on port 25 (recommended). - The server **rejects nonexistent recipients** right at send time (`550` on `RCPT TO`), instead of accepting and bouncing later. This avoids bounces to forged senders. (With a split domain, Lua is the one that rejects: see chapter 5.) - Access to the **domain's DNS** and administrator access to the server. ### Recommended order 1. Ask Lua to register the domain with your server as the destination. 2. Allow Lua's IPs in the server's firewall and antispam (chapter 3). 3. Create the rule that moves tagged spam (chapter 4). 4. If the domain has accounts outside your server, adjust the server (chapter 5). 5. Change the MX (chapter 6) and run the tests (chapter 8). ## 3. Allowing Lua's IPs All messages start reaching your server from the same few Lua IPs. A server that limits connections per IP sees this as abnormal volume and may block delivery. The official list of IPs is at [resources.edgium.net/ips_mx.txt](https://resources.edgium.net/ips_mx.txt). Always use this list, which is updated when an IP changes. - **Firewall:** allow port 25 for these IPs. - **fail2ban, per-IP limits and greylisting:** add these IPs as an exception. - **Server antispam:** treat these IPs as a trusted gateway, so it does not re-evaluate SPF and blocklists against Lua's IP. In SpamAssassin (Zimbra, cPanel), use `trusted_networks`. In Exchange, Lua's receive connector. **Never add Lua's IPs as a network authorized to send** (`mynetworks` in Postfix and Zimbra, anonymous relay in Exchange). That turns the server into an open relay for anyone who passes through Lua. Trusted for spam analysis, yes. Authorized to use the server for sending, no. ### After activation: accept only from Lua Even with the MX changed, spammers keep trying to deliver directly to the server's old IP. Once activation is stable, accept connections on port 25 **only from Lua's IPs**. That way all outside email goes through the filter. Users keep sending normally through the authenticated submission ports (587 and 465). ## 4. Moving tagged spam Lua's filter scores each message. Between 6 and 24.9 points it is not rejected: it goes on to your server with the header `X-Edgium-Spam: Yes`, and your server decides what to do with it. Your server has to recognize this header and treat the message as spam: **if `X-Edgium-Spam` is `Yes`, it goes to the spam folder (Junk)**. On Zimbra and Amavis, the way is to add spam points to the message; on other servers, a filter rule. To see the header on a real message, open the message in the email client and use **View source** (in Outlook, **Properties**; in Zimbra, **Show original**). The line `X-Edgium-Spam: Yes` appears next to the `Received` headers. Unmarked messages do not have the line, or have `No`. **The rule applies to all mailboxes on the server, and the header can be forged by anyone sending directly to your IP.** That is why it is worth following the section After activation: accept only from Lua: with port 25 open only to Lua's IPs, nobody outside can put `X-Edgium-Spam: Yes` on a message to disrupt a mailbox or remove the tag from another. To trigger the tag and confirm the rule works, follow chapter 8, Activation tests. ### Zimbra 8.5 or later In Zimbra, Amavis calls SpamAssassin, which adds up the points from all rules. It then compares the total with two cutoffs: above the tagging cutoff (*tag*) the message goes to Junk; above the discard cutoff (*kill*) it is discarded. The rule below adds points when Lua's header comes as `Yes`. 1. Sign in as the `zimbra` user: `su - zimbra`. 2. Edit `/opt/zimbra/conf/salocal.cf.in` and add this at the top of the file: ``` # EDGIUM ANTI SPAM RULES header EDGIUM_ANTISPAM X-Edgium-Spam =~ /^Yes$/ describe EDGIUM_ANTISPAM Anti Spam Service Score reported as SPAM score EDGIUM_ANTISPAM 7 ``` 1. Restart Amavis: `zmamavisdctl restart`. 2. Check that the rule made it into `/opt/zimbra/data/spamassassin/localrules/salocal.cf`. The score matters because of the cutoffs. Zimbra stores both as percentages, with 20 SpamAssassin points equal to 100%. To see yours, as the `zimbra` user: ``` zmprov gacf zimbraSpamTagPercent zimbraSpamKillPercent ``` With the factory values, `zimbraSpamTagPercent` is 33% (6.6 points) and `zimbraSpamKillPercent` is 75% (15 points). The rule's score must be **greater than or equal to the tagging cutoff** so that Lua's message alone already goes to Junk. That is why the example uses 7: with 6 points, the rule alone does not reach 6.6 and the message would only go to Junk if some other SpamAssassin rule also scored. If your cutoff is different, adjust the score to a value above it. On a tagged message, Zimbra's `X-Spam-Status` shows the rule in the list of tests, something like `EDGIUM_ANTISPAM=7`. **Careful with discarding.** In Zimbra, a message above the discard cutoff (15 points, by default) is not delivered and does not go to Junk. Lua's rule adds 7 to the points SpamAssassin already gave: if the message already had 8 or more, it goes over 15 and is discarded instead of going to Junk. For it to go to Junk instead of vanishing, change the final destination of spam to delivery (`zmprov mcf zimbraAmavisFinalSpamDestiny D_PASS`; the default is `D_DISCARD`) or raise `zimbraSpamKillPercent`. Decide carefully, because the same change applies to all of the server's spam, not just what comes from Lua. ### Amavis with SpamAssassin on your own server * If your Postfix calls Amavis and SpamAssassin without Zimbra, the rule is the same, in SpamAssassin's `local.cf` (usually `/etc/mail/spamassassin/local.cf`; confirm the path on your distribution): ``` header EDGIUM_ANTISPAM X-Edgium-Spam =~ /^Yes$/ describe EDGIUM_ANTISPAM Anti Spam Service Score reported as SPAM score EDGIUM_ANTISPAM 7 ``` 1. Validate the syntax: `spamassassin --lint`. No output means it is correct. 2. Check Amavis's cutoffs in `amavisd.conf` (or in your distribution's `conf.d` files): `$sa_tag2_level_deflt` is the score from which the message gets `X-Spam-Flag: YES` and `X-Spam-Status: Yes`; `$sa_kill_level_deflt` is the score from which it is blocked, and `$final_spam_destiny` sets the destination (by default, `D_DISCARD`). 3. The rule's score (7 in the example) should be **above `$sa_tag2_level_deflt` and below `$sa_kill_level_deflt`**. 4. Restart Amavis (`systemctl restart amavisd` or `amavis`, depending on the distribution). Amavis only tags the message. For it to go to the Junk folder, the mailbox server has to act on `X-Spam-Flag`, for example with the Sieve in the next section. ### Exchange Server (on-premises) * 1. In the Exchange admin center, open **Mail flow → Rules** and create a new rule. 2. Condition: **a message header includes**: header `X-Edgium-Spam`, value `Yes`. 3. Action: **modify the message properties → set the spam confidence level (SCL)** to `6` or more. Messages go to Outlook's Junk Email folder. ### Postfix with Dovecot (Sieve) Dovecot delivers the message through LMTP (or LDA) and runs Sieve on delivery. A **global** script, run before each user's script, moves the tagged message to the spam folder. The examples below are for Dovecot 2.3 with Pigeonhole. 1. Create the global scripts folder and the script: ``` require ["fileinto", "mailbox"]; # Lua Shield: the front-door filter tagged the message as spam. if header :is "X-Edgium-Spam" "Yes" { fileinto :create "Junk"; stop; } ``` `:create` creates the folder if it does not exist yet in the user's mailbox. The name `Junk` is what the IMAP client sees: if your spam folder has another name (`Spam`, `INBOX.Junk` with a namespace prefix), use that name. 1. Turn on the Sieve plugin at delivery and point it to the script (usually in `conf.d/20-lmtp.conf`, `15-lda.conf` and `90-sieve.conf`): ``` protocol lmtp { mail_plugins = $mail_plugins sieve } protocol lda { mail_plugins = $mail_plugins sieve } plugin { sieve_before = /etc/dovecot/sieve-before } ``` If `sieve_before` points to a folder, all `.sieve` files in it run, in name order. If it points to a file, only that file runs. If you already use `mail_plugins` with other plugins in the sections, just add `sieve` to the list. 1. Make the folder and the script readable by the Dovecot user (`chmod 755` on the folder, `chmod 644` on the script), compile and reload: ``` sievec /etc/dovecot/sieve-before/10-edgium-spam.sieve doveadm reload ``` 1. Test the script without delivering anything, with a message saved to a file that has the line `X-Edgium-Spam: Yes`: ``` sieve-test /etc/dovecot/sieve-before/10-edgium-spam.sieve mensagem-marcada.eml ``` The expected output is `store message in folder: Junk`. With a message without the tag, the output is `store message in folder: INBOX`. **The `sieve_before` applies to all accounts on the server**, not just one. Before turning it on, confirm that all the server's mailboxes go through Lua, or create the rule in the script of a single account (in the user's `sieve`). Because the script uses `stop`, the user's personal script does not run for the tagged message. If a `sieve_before` already exists on the server (for example, for antivirus), add the rule with a name that sorts after it, instead of replacing the path. In Dovecot 2.4 the configuration format changed. The same rule looks like this: ``` protocol lmtp { mail_plugins { sieve = yes } } sieve_script edgium-spam { type = before path = /etc/dovecot/sieve-before/10-edgium-spam.sieve } ``` The Sieve script and `sievec` are the same. ### Postfix without Dovecot (header_checks) * Postfix's `header_checks` acts on the header, but **does not move the message to a folder**: the mailbox server does that. It is useful for rejecting, discarding, holding or redirecting the tagged message. In `main.cf`: ``` header_checks = regexp:/etc/postfix/header_checks ``` ``` /^X-Edgium-Spam:[[:space:]]*Yes[[:space:]]*$/ REDIRECT quarentena@yourcompany.com ``` Test the pattern without touching the server: `postmap -fq "X-Edgium-Spam: Yes" regexp:/etc/postfix/header_checks` shows the action when it matches and shows nothing when it does not. After editing, run `postfix reload`. The actions that make sense here, according to the [Postfix manual](https://www.postfix.org/header_checks.5.html): | Action | What it does | When to use | | --- | --- | --- | | `REDIRECT usuario@dominio` | Delivers the message to another address, in place of the recipients. | The safest: the spam stays in a quarantine mailbox, and someone reviews it. Nothing is lost. | | `HOLD` | Puts the message in Postfix's hold queue until someone releases or deletes it. | Review with `postsuper`. The queue grows, so keep an eye on it. | | `PREPEND text` | Adds a header line and continues the analysis. | For another program to decide later, for example a mailbox filter. | | `DISCARD` | Tells the sender it was delivered and deletes the message silently. | Only if you accept losing messages, including legitimate ones that Lua tagged by mistake. | | `REJECT` | Rejects the message during the SMTP conversation. | Avoid: the one talking to your server is Lua's MX, which has already accepted the message. Lua then has to generate a bounce to the sender, which with spam is usually a forged address (*backscatter*). Talk to our team before using it. | If you need the message in the spam folder, use the Sieve from the previous section or the filter of the mailbox server you use. `header_checks` does not replace that. Exim without cPanel: use the filter of the mailbox server itself or of the panel you use to file messages into a folder. Exim's documentation on the system filter was not checked for this case, so we do not give an example. ### cPanel / WHM * 1. In **Global Email Filters** (in cPanel, per account or for all accounts), create a filter. 2. Rule: **Any Header** **contains** `X-Edgium-Spam: Yes`. 3. Action: **Deliver to Folder**, folder `Junk` (or `spam`, depending on the server). After saving, cPanel itself has **Test Filter** to check with a sample message. ### Other servers Any server that filters by header works. The condition is `X-Edgium-Spam` equal to `Yes`, and the action is to move to the spam folder. If your server has its own filter, use it. * Example configuration. Validate it with your provider. If it does not work, talk to the provider's support or to our team. ## 5. Domain shared with other accounts This only applies when not all of the domain's accounts are on your server: part of the team on lua.email, Microsoft 365 or another provider. If all mailboxes are on your server, skip this chapter. In that case, your server cannot treat as nonexistent an address that is simply not on it. In the **domain configuration**, accounts that do not exist on your server must go to the external MX (`mx.secure.edgium-dns.net`), instead of being bounced. Lua delivers each one to the right place and rejects what exists nowhere. Shield with a split domain: part of the accounts outside your server. Lua's MX always receives first. The source of the account list is Lua's panel: it knows which addresses are on your server, which are on lua.email and which are on another provider. For cPanel, **Email Routing → Remote Mail Exchanger** plays this role; see option B in [cPanel on Bridge](https://lua.email/en/docs-bridge#cpanel). ### Exchange Server (on-premises) 1. In **Mail flow → Accepted domains**, change the domain from **Authoritative** to **Internal relay**. 2. In **Mail flow → Send connectors**, create a connector for the address space `yourcompany.com`, delivering through the smart host `mx.secure.edgium-dns.net`. ### Zimbra Zimbra calls this a split domain. As the `zimbra` user: ``` zmprov md yourcompany.com zimbraMailCatchAllAddress @yourcompany.com zmprov md yourcompany.com zimbraMailCatchAllForwardingAddress @yourcompany.com zmprov md yourcompany.com zimbraMailTransport smtp:mx.secure.edgium-dns.net:25 ``` ### Other servers Look for shared domain, internal relay or split delivery: an address that does not exist locally is passed on to `mx.secure.edgium-dns.net`. If in doubt, talk to Lua before changing anything. With a split domain, your server stops rejecting nonexistent addresses on its own, because it now passes them on. Lua is the one that rejects, since it knows all of the domain's accounts. So register with Lua all the accounts that are outside your server before making this change. Setting up accounts on other providers follows the [lua Bridge documentation](https://lua.email/en/docs-bridge). ## 6. MX, SPF, DKIM and DMARC ### MX **Testing period (first 30 days):** publish Lua's MX with the same priority and the same TTL as the current MX, or with a better priority than it (lower number) and the same TTL. If something goes wrong, the old MX keeps receiving. **After the testing period:** leave only Lua's MX. ``` yourcompany.com. 3600 IN MX 5 mx.secure.edgium-dns.net. ``` While the old MX is published, some messages arrive without going through the filter. That is why the testing period has a deadline, and after it you should accept only from Lua. ### SPF SPF lists who **sends** email for the domain. With Shield, the one sending is still your server, because Shield handles inbound. So: - Keep in SPF the IP (or the `include`) of your server and of the other systems that send for the domain. - Add `include:spf.edgium-dns.net`. It is required if the domain also has accounts on lua.email or sends through Lua's servers, and recommended in other cases, to cover messages from the domain itself that Lua passes on to your server. ``` yourcompany.com. IN TXT "v=spf1 ip4:IP-DO-SEU-SERVIDOR include:spf.edgium-dns.net -all" ``` Remember the limit of 10 DNS lookups counting all `include`s, and keep a single SPF record. ### DKIM Set up DKIM signing on your server (OpenDKIM on Postfix, native DKIM on Zimbra, signing by Exchange or by an outbound gateway) and publish the key in DNS. DKIM is what keeps DMARC passing when a company message is forwarded. ### DMARC Recommended. It protects the domain against anyone trying to send using the company's name. Start by observing and tighten after SPF and DKIM have been checked: ``` _dmarc.yourcompany.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com" ``` ``` _dmarc.yourcompany.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourcompany.com" ``` For the `rua` address, create a dedicated mailbox (for example, `dmarc@` or `abuse@`) and forward it to whoever administers the environment. If you do not want to receive reports, remove the `rua`. ## 7. Training the filter You teach the filter yourself, in the panel, without opening a ticket. When a message is classified wrongly, send it as an example: the filter learns from it and makes better decisions on similar messages later. Our team stays by your side whenever you need it. ### How to submit a message 1. In the [panel](https://painel.lua.email), open the domain and go to **Delivery → Train the filter**. 2. Under **This message is**, choose **SPAM** (scam, unwanted advertising) or **TRUSTED** (a legitimate message that was flagged). 3. Under **How to submit**, choose **.eml file** and select the file, or **Paste the message** and paste the full message, with headers and body. 4. If the message has no recipient from the domain, enter in **Address that received the message** which mailbox received it. 5. Click **Send to the filter** and confirm in the window that opens. ![Train the filter screen, under Delivery, with SPAM selected, the Paste the message option, and a message with headers pasted in](https://lua.email/assets/docs/en/pn-treino-form.png) Delivery → Train the filter: the type, the message, and the address that received it (real screen, fictional data). ### The result The screen tells you what happened: - **Done: the filter learned this message as SPAM** (or as TRUSTED): trained. - **All good: the filter had already learned** or **already classifies messages like this**: this is also a success. The message was already taught, so there is no need to send it again. - **Could not train right now. Try again later:** the filter is unavailable at the moment. Try again shortly; if it continues, contact support. - The other notices say what to fix: an empty message or one that does not look like an email, a recipient outside the domain, hourly limit reached, or a repeated submission. ### What was trained The **What was trained** button, next to **Send to the filter**, lists each submission: date, who sent it, domain, type, sender and subject of the message, size, and result. You can filter by date, user, type, result, and domain. The message content does not appear: only the sender and the subject are kept, truncated. ### How to get the.eml - **Google account (Workspace or personal):** open the message, then **⋮ → Show original → Download original message**. - **Outlook on the web and new Outlook:** open the message and use the **⋯** menu to download or save it as an.eml file. - **Outlook for Windows (classic):** dragging the message to a folder creates an.msg file, which the panel does not accept. Open the message in Outlook on the web and download the.eml from there. - **Thunderbird:** **File → Save As → File** saves the.eml. - **Apple Mail:** **File → Save As**, in the **Raw Message Source** format. - **lua.email webmail:** in the message's **More** menu, download the.eml file or open the source and copy everything. Prefer the.eml: it carries the whole message, with the headers the filter uses. If you paste, copy everything, from the first header (`From:`, `Received:`) to the end of the body. ### Good to know - **The filter learns per destination address, not for the whole domain.** The message teaches the filter of the mailbox that received it: the address that appears in the headers (`To`, `Cc`, `Delivered-To`) or the one you enter in the field. To teach more than one mailbox, send the message once for each address. - Only addresses from the domain itself (and its alias domains) are accepted. - One message at a time, up to 10 MB. A file with several messages (mbox) is rejected. - There is a limit on submissions per hour, per person and per domain. The same message sent again right after is rejected, because it does not need to be repeated. - The **Read-only** and **Helpdesk** profiles cannot train: they see the screen and the history, without the form. - The screen exists for domains with an active **Shield** or **Bridge** license. - The message goes through the filter and is **not stored** in the panel. Only the record that the submission was made remains. If your account does not have the screen (read-only or helpdesk profile, or a domain without Shield or Bridge), ask whoever administers the domain, or send the original message as an.eml through support. Training teaches the filter to decide on the next similar messages. For a sender that must *always* get through, add it to the allowed list, under **Delivery → Access lists**. ## 8. Activation tests | Test | What to check | | --- | --- | | Send from an external account to an account on the domain | It arrived. The header has a `Received` from `mx.secure.edgium-dns.net` and Lua's `Authentication-Results`. | | Send to an address that does not exist on the domain | The bounce arrives quickly, with `550` from your server. | | Tagged message (`X-Edgium-Spam: Yes`) | It went to the spam folder. If there is not a real one yet, ask Lua for a tagged test message. | | Send from the domain to the outside | `spf=pass`, `dkim=pass` and `dmarc=pass` in the recipient's header. | ## 9. Common problems ### Messages do not arrive or arrive late The server's firewall, fail2ban, greylisting or a per-IP limit is holding back Lua's connections. Allow the IPs from the official list in those places. ### Tagged spam shows up in the inbox The rule from chapter 4 is not active or uses a different header name. Check in the full header whether the message has `X-Edgium-Spam: Yes`. ### Spam arrives without going through Lua The header has no `Received` from `mx.secure.edgium-dns.net`. The sender delivered directly to the server, through the old MX or the IP. Remove the old MX and accept port 25 only from Lua. ### A legitimate message was marked as spam Send the message as TRUSTED, as in the training chapter. If the sender always needs to get through, add them to the allowed senders list in the panel (Delivery → Access lists). ### The server is bouncing messages to senders who did not send anything The server accepts any recipient and only bounces afterward. Configure it to reject nonexistent recipients right at `RCPT TO` (chapter 2). ## 10. Registering the Shield domain in the panel A Shield domain is registered in the panel a little differently from a domain with mailboxes: you choose the type, enter your server's destination and say how many licenses to link to the domain. The rest of the path, including domain verification by TXT, is the same as the [standard onboarding](https://lua.email/en/docs-onboarding). ### Before registering - The customer needs an active **Shield license** with a seat available. Without a license, the panel shows the usual form, only for a domain with mailboxes. - The customer's administrator does the registering. Read-only and support profiles see the numbers but cannot register. - The server that will receive the email should already be ready for chapters 3 and 4. Without the panel, ask Lua to register it, as described in chapter 2. ### Step by step 1. In **Domains**, click **Add domain** and type the domain. 2. In **Domain type**, choose **Shield: antispam for my server**. The other option, **Domain with email mailboxes**, remains the default. 3. In **Shield licenses for this domain**, say how many licenses to link (at least 1). The link is for billing and usage checks: it does not limit or block email. The sum of the links across all your Shield domains cannot exceed what was subscribed, and the panel rejects anything over that. You can change the quantity later, in **Edit domain**. 4. Enter the **destination server** (IP or name) and the **port** (blank means 25). The panel only accepts a server outside Lua: internal IPs, `localhost` and Lua addresses are rejected. 5. Click **Continue**, publish the TXT record in the domain's DNS and use **Check now**. The deadline is 72 hours. When the TXT appears, the domain becomes active as Shield. ![Add domain screen with the Shield type selected, one linked license, fixed destination mail.demo-padaria-estrela.test and port 25](https://lua.email/assets/docs/en/sh-onb-tipo.png) Figure 1: choosing the domain type, with the number of licenses and the server destination. Real panel screen, sample data. ### Fixed destination or the name's MX In one sentence: the **fixed destination** always delivers to the IP or name you entered, and **use this name's MX** makes Lua look up the name's MX and try the next server when one is down, in order of preference. The **i** icon next to the option repeats this explanation on screen. - **Fixed destination (default).** Use it when the server has a single IP or name. If the name has more than one IP (two A records, such as two internet links), Lua tries the name's addresses until one responds. - **Use this name's MX.** Use it when you have more than one inbound server or link and want to control the order. The name must have an MX record, and each MX server goes through the same check as the fixed destination. Example with a name that points to itself and two addresses (two links): ``` entrada.yourcompany.com. 3600 IN MX 5 entrada.yourcompany.com. entrada.yourcompany.com. 3600 IN A 203.0.113.10 entrada.yourcompany.com. 3600 IN A 198.51.100.20 ``` Example with two servers and different weights. Lua tries the one with preference 5 and, if it does not respond, the one with preference 10: ``` entrada.yourcompany.com. 3600 IN MX 5 principal.yourcompany.com. entrada.yourcompany.com. 3600 IN MX 10 reserva.yourcompany.com. principal.yourcompany.com. 3600 IN A 203.0.113.10 reserva.yourcompany.com. 3600 IN A 198.51.100.20 ``` To check before registering: ``` host -t mx entrada.yourcompany.com dig +short MX entrada.yourcompany.com dig +short A principal.yourcompany.com ``` **Each destination address must accept Lua's IPs** (the list in chapter 3), both the primary and the backup server. The destination name is only the place where Lua delivers: the email domain's MX still points to Lua (chapter 6), and the panel rejects a destination whose address belongs to Lua. ![Add domain screen with the Use this name's MX option selected and the name entrada.demo-padaria-estrela.test](https://lua.email/assets/docs/en/sh-onb-mx.png) Figure 2: the option to use the name's MX, with the help icon next to it. Real panel screen, sample data. ### Domain with mailboxes and Shield | What changes | Domain with mailboxes | Shield domain | | --- | --- | --- | | Where the mailboxes are | At Lua, with webmail, calendar and Colabora. | On your server. The panel does not create mailboxes, aliases or DKIM for the domain. | | License | One per mailbox. | Shield licenses linked to the domain, in the quantity you choose (minimum 1). | | Delivery | To the mailbox, on Lua's servers. | To the server and port you registered, after the filter. | | Domain MX | Servers listed in the panel. | Shield MX (chapter 6). | | IPs and spam rule | There is nothing to configure on your server. | Allow Lua's IPs (chapter 3) and create the header rule (chapter 4). | | Domain verification | TXT record in DNS. | TXT record in DNS, the same. | ### After registering The Shield domain page shows the **linked licenses**, the **accounts in the last 30 days** (each address that received email accepted by your server counts once; email rejected or bounced because of a nonexistent account does not count) and the contract's **available licenses**, with a shortcut to subscribe to more. The account count appears a few moments after the screen opens, and **View by day** shows a chart with each day's accounts. If more accounts are receiving email than there are linked licenses, the panel warns you to adjust the quantity. Customers with a legacy license see "Legacy license" in place of the available ones, with no purchase offer. ![Shield domain page with linked licenses 1, accounts in the last 30 days and available licenses 2](https://lua.email/assets/docs/en/sh-onb-resumo.png) Figure 3: the Shield license summary on the domain page. Real panel screen, sample data. ### When no license is available If all Shield licenses are already linked, the Shield option is disabled, with a notice and a shortcut to subscribe to more licenses. The form continues as **Domain with email mailboxes**, and you register the domain normally. ![Add domain screen with the Shield option disabled, a notice that the licenses are in use and the subscribe button](https://lua.email/assets/docs/en/sh-onb-sem-vaga.png) Figure 4: with no Shield license available, registration continues as a domain with mailboxes. Real panel screen, sample data. ## Still need help? Contact support. A person on Lua support answers, based in Brazil, in Portuguese. [**Talk to support**: WhatsApp (47) 99276-7511](https://wa.me/5547992767511?text=Hi%21%20I%27m%20a%20lua.email%20customer%20and%20I%20need%20help%20from%20support.) [**Write to us**: suporte@lua.email](mailto:suporte@lua.email?subject=Help%20with%20lua%20Shield) [**Other ways to get help**: Support page](https://lua.email/en/support) To speed things up, send the domain, the server you use (Exchange, Zimbra, cPanel, Postfix) and the full header of a message with a problem.