Help — Domain management

Adding a domain to MxGuard takes three things: tell the system about the domain, prove you control it via DNS, and point your MX records at us. Customer-admins can do the first two themselves; the third is at your DNS provider.

Who can add domains

Only customer-admins (users with admin privileges on their company account) can add domains. Regular users see their own mail but don't manage the company's domain list.

Adding a domain

On the dashboard, find the Domains section and click + add domain.
Fill in the form:
- Domain — bare hostname, like example.com, no www, no trailing slash
- Real mail server — hostname or IPv4 of your existing mail server (where MxGuard forwards clean mail)
- Port — one of 25 (default SMTP), 465 (SMTPS), 587 (submission), 2525 (alt SMTP)
- Accept all recipients — leave checked unless you want MxGuard to verify each recipient with your backend before accepting
Click add domain. The system validates and creates the domain in pending_verification status.

Domain validation rules

A domain is refused if:

The format is invalid (no dots, illegal characters, too long)
It's on the blocklist of high-value targets (gmail.com, microsoft.com, banks, gov.uk, etc.)
Another customer is already managing it

If you genuinely control a blocklisted domain (you work at one of those companies), contact your MxGuard operator. They can add it manually.

DNS verification

After adding, you're sent to the verify page. It shows a TXT record to add at your DNS provider:

Type:  TXT
Name:  _mxguard-verify.example.com
Value: mxg-XzimddVPfUBt0c1RF3vVzJPhaIHP28y8
TTL:   300

Add this at your DNS provider's control panel. Most providers want you to enter just _mxguard-verify as the name (without the domain part) because they auto-append the zone. After saving, wait 1–2 minutes for propagation.

You can test propagation yourself:

dig +short TXT _mxguard-verify.example.com @8.8.8.8

If that returns the token in quotes, propagation is done. Click Verify now on the verify page. MxGuard performs the DNS lookup and, on success, flips the domain to active.

Pointing your MX

Once verified, point your domain's MX records at MxGuard. Add two records so mail still flows when mx1 is unreachable:

Type:     MX        Type:     MX
Name:     @         Name:     @
Priority: 10        Priority: 20
Value:    mx1.mxguard.uk    Value:    mx2.mxguard.uk

Remove any other MX records to avoid mail going around MxGuard. DNS propagation can take a few minutes to a few hours depending on your previous TTL.

Recipient validation modes

The Accept all recipients checkbox controls whether MxGuard checks each recipient address with your backend before accepting the mail:

Mode	Behaviour	Best for
Accept all	Every recipient accepted at SMTP. Backend bounces unknown addresses later (back-scatter risk).	Catch-all domains, situations where MxGuard can't talk to the backend directly
Validated	MxGuard asks your backend "do you know this address?" before accepting. Unknown addresses get a 550 reject at SMTP time, before the message body is sent.	Most production setups — cleaner reject, no backscatter, lower spam intake

How your mail server trusts MxGuard

When MxGuard forwards clean mail to your real mail server, that server has to recognise the connection as legitimate — otherwise it'll refuse the relay or classify the message as untrusted. Two ways to handle this, selectable when adding or editing a domain:

Mode	How it works	Best for
Trust by IP default	You add MxGuard's outbound IP (`194.26.222.170`) to your mail server's trusted-relays list, `permit_mynetworks`, or firewall allowlist. Connections from that IP are accepted without credentials.	Self-managed Postfix, Exim, Exchange Server, or any backend where you control the relay/allow-list configuration.
SMTP AUTH	MxGuard authenticates with a username and password on every delivery (over TLS). You create a dedicated relay user on your backend and give us the credentials in the domain form.	Microsoft 365, Google Workspace, cPanel hosts, or any provider where IP allowlisting isn't easily available.

Choosing between them:

If your backend is on a server you administer directly, Trust by IP is simpler and faster — no credentials to manage, no risk of password rotation breaking delivery.
If your backend is hosted with a third-party provider that doesn't expose firewall or relay-trust settings, SMTP AUTH is what you need. Create a dedicated relay user (don't reuse a real mailbox's password).

Credentials are stored in MxGuard's database and read by Postfix at relay time. The connection to your backend is opportunistic-TLS (will negotiate STARTTLS if your server offers it). Don't reuse production user passwords — create a dedicated relay-only user with relay permissions and nothing else, and rotate it on a schedule.

You can switch between modes at any time from the domain settings — the change takes effect on the next message after Postfix re-reads its lookup tables (within seconds). When updating an SMTP AUTH password, leave the password field blank to keep the existing one; enter a new value to replace it.

After mail starts flowing

Open the live feed and watch. You'll see every scan with its score and the reasons. For the first few days, keep an eye on quarantine — release anything legitimate (this trains the system) and delete anything that's actually unwanted.