How to Set Up SpamExperts Email Security for Your Domain

What Happens Before You Touch DNS

A SpamExperts setup begins well before any DNS record changes, because the account must be provisioned and the domain added to the filtering platform first. Getting this sequence wrong is the single most common cause of dropped mail during a switch, so it’s worth treating as its own stage rather than skipping to the MX records.

Provisioning the Domain Inside the SpamExperts Control Panel

Before a domain can receive filtered mail, it must exist as a domain object in the SpamExperts admin panel, with its destination route pointing to the real mail server that currently handles delivery. This destination route tells the filtering layer where to forward clean mail after scanning; get this wrong, and every message either bounces or loops. Most control panels attempt to auto-detect the destination from the domain’s current MX records, but that auto-detected value should always be checked manually rather than trusted outright, especially on domains that have been migrated between hosts before and may still carry a stale record somewhere in the chain.

The domain also needs its inbound and outbound filtering policies set at this stage, even though they won’t take effect until MX records change. Leaving default policy settings in place is usually fine for a first pass, since fine-tuning quarantine thresholds is a job for after cutover, not before it. What matters now is confirming that the mailbox count and domain aliases are accurate, because SpamExperts licensing and reporting are typically tied to the domains and mailboxes registered against the account. An incorrectly added domain can silently cause filtering to apply to the wrong destination.

Auditing Your Current Mail Setup First

Before changing anything, document the domain’s existing MX records, the mail server’s actual IP address, and any existing SPF include statements, since all three get referenced repeatedly during setup and are easy to lose track of once DNS starts changing. A simple text file with the current state, old MX hosts and priorities, the current SPF record, and the current DKIM selector, if one exists, turns a stressful rollback into a five-minute fix if something goes wrong later.

This is also the point to check whether the domain uses any third-party outbound relay, marketing platform, or transactional email service that sends mail “as” the domain, because each of those requires its own SPF record and will need to continue working after the switch to SpamExperts filtering. Missing one of these is a common reason legitimate marketing or transactional mail starts failing SPF checks right after a filtering change, even though the change itself had nothing to do with that specific sending service.

Preparing Your Domain and Mailbox Inventory

Once the domain exists within the platform, the next step is to ensure every mailbox and alias that should receive mail is accounted for, since SpamExperts filters mail per domain. However, delivery still depends on the destination server recognizing each address. A domain added correctly but with an incomplete mailbox list will filter mail that then bounces at the final hop.

Confirming Every Active Mailbox and Alias

Pull a full list of active mailboxes, forwarding addresses, and catch-all rules from the current mail server before setup goes further, because this list is what determines whether “unknown user” bounces after cutover come from a genuine typo or from a mailbox that wasn’t accounted for. Shared mailboxes, distribution lists, and old aliases kept alive for a departed employee are the ones most often missed, since they don’t show up at a glance in the primary admin’s inbox.

If the destination mail server uses a catch-all address, confirm whether that catch-all should stay active after the SpamExperts switch, since catch-all addresses receive a disproportionate share of spam and are often the reason a domain needed dedicated filtering in the first place. Leaving a catch-all in place without adjusting its own spam-handling can undercut the value of the filtering layer sitting in front of it, because mail addressed to nonexistent local parts still lands somewhere.

Setting Destination Routing Correctly

The destination route is the address SpamExperts forwards clean mail to after filtering, and it needs to point to a real, reachable mail server rather than to another layer of filtering or to the domain’s own MX record, which would create a routing loop. For most single-server setups, this is simply the mail server’s IP address; for domains behind a load balancer or a cluster, it should be the address that reliably accepts SMTP connections.

It’s worth testing this destination route directly with a manual SMTP connection before relying on the platform’s own connectivity check, since a route that responds to a ping but refuses SMTP traffic on port 25 can still appear reachable in some basic checks. A domain with firewall rules that only allow specific IP ranges to connect on port 25 will also need those rules updated to allow the SpamExperts filtering IPs through, or every message will be rejected at the destination even though the filtering step itself worked correctly.

Changing MX Records to Point to SpamExperts

MX record changes are the step that actually redirects inbound mail through the filtering layer, and they need to be made precisely, using the exact hostnames and priorities SpamExperts publishes, rather than approximated or partially applied. Getting the priority order wrong is a common way for spammers’ mail to bypass the filter entirely.

The Exact MX Records and Priority Order to Use

SpamExperts filtering is enabled by pointing a domain’s MX records to mx.spamexperts.com (priority 10), fallbackmx.spamexperts.eu (priority 20), and lastmx.spamexperts.net (priority 30). The lowest-priority number is attempted first for delivery, so this order routes mail through the primary filtering server, with the other two serving as fallbacks if the primary is briefly unreachable. All three should be added together, not just the first one, since the fallback records are what keep mail flowing during any brief outage on the primary filtering node.

Every existing MX record pointing to the old mail server must be removed, not just deprioritized, because spammers routinely try higher-numbered MX records specifically to bypass filtering. A domain that leaves its old MX record in place alongside the SpamExperts records, even at a lower priority, is still exposed, since a sending server that gets a timeout or rejection from the filtering MX will often retry against whichever record is next in line. Region-specific MX record sets exist for organizations with a private-label license and a genuine requirement to route mail through a specific geographic territory. Still, the global records are recommended for standard setups since uptime guarantees are tied to them.

Setting the Right TTL Before You Cut Over

DNS changes take time to propagate globally, and mail can continue to route directly to the old MX records without any filtering during that window, depending on the TTL of the MX record. Lowering the MX record TTL to something short, commonly 300 to 900 seconds, a day or two before the actual cutover gives much tighter control over exactly when the new records take effect everywhere, rather than leaving it to whatever TTL was previously set, which is sometimes 24 hours or longer on records that haven’t been touched in years.

Once cutover is confirmed stable, the TTL can be raised back to a more standard value, since a permanently short TTL adds unnecessary DNS query load without an ongoing benefit. Some DNS control panels require a trailing dot after each MX hostname to indicate it’s a fully qualified domain name, and forgetting that trailing dot is a common reason a correctly typed MX record fails to resolve as expected. It’s worth checking the specific DNS provider’s formatting convention before saving the records.

SpamExperts MX Records to Configure

Configuring Inbound Mail Routing Through the Filtering Gateway

With MX records pointed to SpamExperts, the inbound routing configuration determines what the filtering layer does with mail once it arrives, where it forwards clean messages, how it treats messages it can’t confidently classify, and what happens to a message that the destination server itself rejects.

How Inbound Filtering Decisions Get Applied

Inbound mail arriving at the SpamExperts servers is scanned against spam, phishing, and malware signatures before a decision is made to deliver, quarantine, or reject it. Only mail that passes this scan is forwarded to the destination route configured earlier. This scan occurs at the SMTP session level for a meaningful share of unwanted mail, so connections identified as spam sources can be rejected before the message body is fully transmitted, considerably reducing the processing load on the destination mail server compared to filtering after full delivery.

Messages that fall into a genuine gray area, not confidently spam, not confidently legitimate, are typically quarantined rather than delivered or dropped outright, giving the recipient or admin a chance to review and release anything misclassified. How aggressively that gray area is defined is a policy setting, and the specific quarantine thresholds and review workflow are a separate, ongoing configuration task rather than part of this initial setup. That tuning work belongs to the domain’s regular filter and quarantine management, not the first-time cutover covered here.

Handling Bounces and Rejections From Your Own Server

If the destination mail server rejects a message after SpamExperts has already accepted and forwarded it, because a mailbox doesn’t exist, for instance, that rejection needs to travel back through the chain correctly rather than generating a misleading bounce from the filtering layer itself. This is why the mailbox inventory audit from the previous section matters so directly here: a destination server that accepts all mail for a domain regardless of the local-part, rather than rejecting unknown addresses at the SMTP level, will cause SpamExperts to accept mail for addresses that don’t actually exist, creating downstream problems that only surface once someone notices deliveries with no matching mailbox.

Getting recipient verification working correctly, so the filtering layer knows in real time which addresses are valid for the domain, avoids this problem and is one of the more overlooked pieces of a clean setup. Where the destination platform supports it, enabling recipient validation against the live mailbox list, rather than accepting everything and sorting it out afterward, keeps the bounce behavior a sender sees consistent with reality, which matters for the domain’s own sending reputation as much as for basic housekeeping.

Setting Up Outbound Email Filtering and Relay

Outbound filtering routes a domain’s own sent mail through SpamExperts before it reaches the public internet, which protects the domain’s sending reputation by catching compromised-account spam or malware-laden attachments before they go out under the domain’s name.

Routing Outbound Mail Through the Relay

To filter outbound mail, the sending mail server needs to be configured to relay through the SpamExperts outbound servers rather than deliver directly to recipient mail servers, which usually means changing the smart host or relay setting in the mail server’s configuration rather than making a DNS change. This is a materially different configuration step from the inbound MX change, and it’s easy to assume that inbound filtering alone provides full protection, when in fact outbound relay is a separate setup that requires its own configuration on the sending server.

Authentication for the outbound relay typically ties to the sending server’s IP address or to per-domain credentials, and either approach must be configured correctly before outbound mail will flow through the relay rather than being rejected as unauthorized. A sending server with a dynamic or frequently changing IP address will need credential-based authentication rather than IP-based authentication, since an IP allowlist entry that goes stale silently blocks all outbound mail until someone notices that deliveries have stopped.

Why Outbound Filtering Protects Deliverability, Not Just Security

A single compromised mailbox sending spam through a domain’s own outbound path can damage that domain’s sender reputation with major inbox providers within hours, and reputation damage of that kind takes considerably longer to repair than it takes to cause, since blocklisting and reputation scoring systems tend to be quick to flag but slow to restore trust fully. Outbound filtering catches this kind of abuse at the relay before it reaches recipient servers, which is a meaningfully different form of protection than inbound filtering provides and is often the piece that domains that set up SpamExperts primarily to stop incoming spam skip.

In practice, a pattern worth flagging from setups handled over time is that businesses that skip outbound filtering during initial setup and add it later usually do so only after a reputation problem has already occurred. At this point, the fix is reactive rather than preventive. Setting up both inbound and outbound filtering in the same initial pass avoids that gap entirely. It protects the domain’s reputation from day one rather than only after a first incident forces the issue.

Verifying SPF, DKIM, and DMARC Alignment After the Switch

Changing MX records affects inbound routing, but SPF, DKIM, and DMARC govern how a domain’s outbound mail authenticates itself to receiving servers, and a filtering switch can quietly break authentication alignment if these records aren’t checked against the new mail flow.

Updating SPF to Include the Right Sending Sources

SPF (Sender Policy Framework) is a DNS TXT record listing which servers are authorized to send mail on a domain’s behalf. It needs to include every legitimate sending source, the primary mail server, any marketing platform, any transactional email service, or receiving servers that may treat genuine mail as spoofed. A SpamExperts setup doesn’t require adding SpamExperts itself to the SPF record for inbound filtering, since SPF governs outbound sending authorization rather than inbound receipt, which is a distinction that trips up admins who assume every DNS change during setup needs a matching SPF update.

When outbound relay through SpamExperts is configured per the previous section, the SPF record needs updating to authorize that outbound relay path as a legitimate sender, since recipient servers checking SPF alignment need to see the relay’s sending IP or hostname included. Skipping this step after enabling outbound relay is one of the more common reasons a domain’s own outgoing mail starts failing SPF checks immediately after a SpamExperts setup, even though inbound filtering is working exactly as intended.

Confirming DKIM Signing Still Works and DMARC Still Aligns

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outbound mail, which is verified against a public key published in DNS. This signing occurs on the sending mail server rather than at the SpamExperts layer, so it generally continues working unchanged through an inbound MX switch. It’s still worth confirming with a live test message after cutover, since a mail server reconfiguration done at the same time as the SpamExperts setup, which happens often, since admins tend to bundle changes into one maintenance window, can accidentally disable DKIM signing without anyone noticing until a receiving server starts flagging mail.

DMARC (Domain-based Message Authentication, Reporting and Conformance) requires that both SPF and DKIM pass and align with the domain in the From address. If outbound relay changes alter the sending path without a corresponding SPF update, DMARC alignment can fail even when DKIM alone still passes. Checking DNS record propagation with a dedicated verification tool after any MX or related record change, rather than relying on assumptions, catches misconfigurations before they affect real mail delivery. Running the same verification approach against SPF and DMARC records after a SpamExperts cutover is worth the extra few minutes.

Testing Inbound and Outbound Flow Before Going Live

A setup that looks correct in the control panel still needs live testing with real messages before the old MX records or fallback path are removed entirely, since DNS propagation delays and configuration edge cases only reliably surface once mail actually moves through the new path.

Sending Test Messages From Outside Your Own Network

Testing inbound flow from an external mail account, sent from a network unrelated to the domain’s infrastructure, confirms the full path works exactly as an ordinary sender’s mail would, rather than testing from inside a network that may have its own routing shortcuts. Sending from a webmail account on a different provider, checking that the message arrives in the destination mailbox, and confirming the message headers show it passed through the SpamExperts filtering servers is the most reliable first check.

Testing should include at least one message deliberately designed to trip spam detection, something with spam-typical language or a suspicious-looking link, to confirm the filtering layer is actually classifying and quarantining as expected, rather than passing everything through untouched. A setup that delivers clean test mail successfully but has never been tested against something the filter should flag hasn’t actually confirmed the filtering itself is active, only that the routing path is open.

Confirming Outbound Mail Authenticates and Delivers Cleanly

For outbound testing, send a message from the domain to an external address at a major provider and check the full message headers on the receiving end for SPF, DKIM, and DMARC results, since a pass on all three confirms the relay and authentication configuration from the earlier sections is working together correctly rather than just individually. A message that passes DKIM but fails SPF alignment, for example, points specifically at an incomplete SPF update rather than a DKIM problem, which narrows down where to look.

It’s also worth sending a test message large enough to include a typical attachment, since some outbound relay configurations apply different size limits or scanning behavior to messages with attachments than to plain text mail, and a setup only tested with short plain messages can miss a size-limit misconfiguration that only affects real-world mail. Confirming the delivery times for both plain and attachment-carrying test messages provides a baseline to compare against if performance concerns arise later.

Connecting SpamExperts With Microsoft 365 and Google Workspace

Many domains running SpamExperts route mail to a mailbox platform such as Microsoft 365 or Google Workspace rather than to a self-hosted mail server, and the destination routing and authentication setup varies slightly depending on which platform sits behind the filtering layer.

Routing SpamExperts to Microsoft 365 Correctly

Configuring inbound filtering with Microsoft 365 as the destination involves setting the destination route to the tenant’s Exchange Online mail routing endpoint rather than a standalone server IP, since Microsoft 365 mailboxes don’t sit behind a single fixed IP address the way a traditional on-premises mail server does. Getting this destination route right is the main setup difference compared to a standalone mail server, and it’s worth double-checking it against the tenant’s accepted domains configuration in the Microsoft 365 admin center rather than assuming the auto-detected route is correct.

Microsoft 365 also expects inbound connectors configured to trust mail arriving from the SpamExperts filtering IPs, since Exchange Online applies its own additional spam scoring by default and can otherwise re-flag already-filtered mail or apply duplicate processing. Setting up a proper inbound connector that recognizes SpamExperts as a trusted upstream filter avoids duplicate scanning and keeps the two layers working together rather than at cross-purposes.

Routing SpamExperts to Google Workspace Correctly

Google Workspace domains route filtered mail to Google’s own MX endpoints as the destination, and Google Workspace’s own admin console needs an inbound gateway setting configured to recognize SpamExperts as the upstream filter, so Workspace doesn’t apply conflicting spam classification on mail that’s already been filtered. Without this gateway setting, Workspace’s own spam scoring can override or duplicate decisions SpamExperts already made, which undermines the value of running dedicated filtering in front of it.

For a full side-by-side comparison of Workspace’s built-in spam protection against a dedicated filtering layer like SpamExperts, see our guide to Google Workspace email security. This section covers only where SpamExperts setup intersects with a Workspace destination, not the broader question of whether Workspace’s native filtering alone is sufficient for a given domain. Both Microsoft 365 and Google Workspace destinations are fully compatible with a standard SpamExperts setup; the difference is entirely in how the destination route and inbound trust settings are configured, not in whether filtering itself works.

Avoiding Common Setup Mistakes That Cause Mail Delays

Most SpamExperts setup problems trace back to a handful of recurring mistakes rather than genuinely unusual configurations, and knowing what they are in advance is faster than diagnosing them after mail has already started bouncing.

Leaving Old MX Records or a Short TTL Unmanaged

The single most common mistake is leaving an old MX record in the zone file at a lower priority instead of deleting it outright, which reintroduces exactly the bypass risk the whole setup was meant to close. A close second is forgetting to lower the TTL in advance, which turns what should be a controlled, fast cutover into an unpredictable multi-hour window in which some senders’ mail is filtered and others’ isn’t, depending purely on when their resolver last cached the old record.

A related mistake is changing MX records and then immediately decommissioning the old mail server’s inbound access on the same day, before propagation has fully completed worldwide. Keeping the old server reachable, even briefly, for a day or two after the DNS change provides a safety margin for any resolver still working from a cached record, without which a percentage of inbound mail can fail rather than arrive late.

Skipping Outbound Setup or the SPF Update It Requires

The other recurring mistake, covered in earlier sections but worth restating here, is treating inbound MX changes as the entire setup and skipping the outbound relay configuration and its corresponding SPF update. This leaves a domain’s own reputation unprotected on the outbound side even though inbound filtering is fully working, and it’s a gap that often goes unnoticed until a reputation or deliverability problem forces someone to look at what was actually configured months earlier.

A smaller but frequent mistake is testing only with a single internal test message rather than an external one, which can pass even when the real-world configuration has a problem, since internal mail sometimes takes a shortcut path that doesn’t reflect how an outside sender’s mail actually travels. Testing exactly as described in the earlier testing section, from outside the network, including a message designed to trigger spam detection, catches this category of mistake before it affects real correspondents rather than after.

Confirming Full Cutover and Monitoring the First 48 Hours

Once testing confirms that both inbound and outbound flows are working correctly, the final stage of setup is to monitor the domain closely during the first two days of live traffic, since this is when propagation-related edge cases and any missed configuration details are most likely to surface.

What to Watch in the First 48 Hours

Mail server logs and the SpamExperts admin panel’s delivery logs should both be checked at least twice daily during the initial window, looking specifically for delivery failures, unexpected spikes in quarantine volume, or bounce patterns that weren’t present before cutover. A sudden jump in quarantined mail immediately after cutover isn’t necessarily a problem; it often simply reflects the spam volume the domain was previously receiving, with no filtering in place to catch it. Still, it’s worth a quick manual review to confirm that nothing legitimate is caught in that first spike.

Keeping a close eye on any automated system that sends transactional mail on the domain’s behalf, password resets, order confirmations, appointment reminders, matters more than general correspondence during this window, since these are exactly the messages a business notices missing fastest, and they’re also the ones most likely to break if an SPF include was missed during the outbound setup steps.

Setup Verification Checklist by Stage

Confirming Full Cutover Before Standing Down

Full cutover can reasonably be considered complete once 48 hours have passed, with clean inbound and outbound test results, no unexpected bounce patterns in the logs, and confirmation that DNS has fully propagated by checking MX records from a handful of public resolvers rather than just one. At that point, the MX record TTL can be raised back to a standard value, and the old mail server’s previous MX priority slot can be safely removed from any remaining fallback configuration.

From this point forward, the setup is complete, and the domain moves into ongoing filter tuning, quarantine review, and reporting configuration, a distinct, continuing task rather than part of this initial cutover. Treating that ongoing tuning as ordinary maintenance rather than an emergency response, since the setup itself was carefully done the first time, is the actual payoff of getting these ten steps right from the start.

Frequently Asked Questions

Is SpamExperts compatible with Microsoft 365?

Yes. SpamExperts filters inbound mail before it reaches an Exchange Online mailbox by routing it to the tenant’s Microsoft 365 mail routing endpoint rather than to a standalone server IP. The one setup detail specific to Microsoft 365 is configuring an inbound connector that trusts mail arriving from the SpamExperts filtering IP ranges, since Exchange Online applies its own spam scoring by default and can otherwise re-flag or duplicate-process mail that SpamExperts has already filtered. Once that connector is in place, inbound filtering, quarantine, and outbound relay all work the same way they would with any other mail platform behind the filter. A full, standalone comparison of Microsoft 365’s native filtering against a dedicated SpamExperts layer falls outside the scope of this setup guide.

Does SpamExperts work with Google Workspace?

Yes. A Google Workspace destination requires an inbound gateway setting in the Workspace admin console that recognizes SpamExperts as the upstream filter, preventing Workspace’s native spam scoring from overriding or duplicating a filtering decision SpamExperts has already made. Without that gateway setting configured, mail that SpamExperts has already cleared can still get re-flagged by Workspace’s own classification, undermining the point of running a dedicated filtering layer in front of it. Beyond that one gateway configuration step, MX records, destination routing, and outbound relay setup are identical to any other destination platform. A deeper comparison of Workspace’s built-in protection versus dedicated filtering is covered in our Google Workspace email security content, not here.

How long does it take for a SpamExperts MX record change to propagate fully?

Propagation speed depends entirely on the TTL value set in the domain’s MX records before the change, since DNS resolvers around the world cache records for the duration specified by that TTL and won’t request an updated value until it expires. A domain with a 24-hour TTL left unchanged before cutover can see some senders still routing directly to the old mail server for up to a full day, bypassing filtering entirely during that window. Lowering the TTL to somewhere between 300 and 900 seconds a day or two ahead of the actual cutover is standard practice, specifically to shrink this window down to minutes rather than hours, after which the TTL can be raised back to a normal value once cutover is confirmed stable.

Do I need to change my SPF record when setting up SpamExperts?

Not for inbound filtering itself, since SPF governs which servers are authorized to send mail on a domain’s behalf, and SpamExperts inbound filtering doesn’t require the domain to authorize SpamExperts as a sender. An SPF update is only needed if outbound relay through SpamExperts is also configured, in which case the relay’s sending path must be included in the SPF record so that receiving servers recognize it as an authorized source. Skipping this update after enabling outbound relay, while leaving inbound-only filtering’s SPF record untouched, is one of the more common reasons a domain’s own outgoing mail starts failing authentication checks right after setup.

Can I set up inbound filtering without outbound filtering?

Yes, inbound and outbound filtering are configured as genuinely separate steps, and a domain can run inbound-only filtering indefinitely if that’s the deliberate choice. Doing so leaves the domain’s own outbound reputation unprotected against a compromised mailbox sending spam under the domain’s name, which is a materially different risk than inbound spam reaching a mailbox, since reputation damage from outbound abuse affects deliverability for every recipient in the future, not just a single mailbox. Most setups handled as a coordinated first pass configure both together specifically to avoid this gap, rather than treating outbound as an optional add-on for later.

What happens to mail sent during the DNS propagation window?

Mail sent by a server whose DNS resolver still has the old MX record cached will continue to be routed directly to the old mail server, unfiltered, until that resolver’s cache expires and it looks up the new MX records. This isn’t typically a delivery failure; the old server, if still reachable, generally still accepts and delivers mail normally. However, it does mean that some portion of mail during the propagation window bypasses filtering entirely. This is exactly why lowering the MX TTL ahead of time and keeping the old server reachable for a short buffer period afterward, rather than decommissioning it immediately, are both standard parts of a clean cutover.

How do I verify that SpamExperts is actually filtering my inbound mail?

The most reliable check is to send a test message from an external account on a network unrelated to the domain’s infrastructure, then inspect the delivered message’s full headers to confirm it passed through the SpamExperts filtering servers rather than arriving via a direct path. A second, equally important check is to send or receive a message specifically designed to trigger spam detection, to confirm the filter is actively classifying mail rather than simply passing everything through untouched. Testing only with ordinary, clearly legitimate mail confirms that the routing path is open but doesn’t confirm that filtering is working.

Why is my mail bouncing right after I changed my MX records?

A sudden bounce increase right after an MX change most often traces back to one of a few causes: the destination route inside the SpamExperts control panel pointing at the wrong server, a firewall on the destination server blocking the SpamExperts filtering IPs from connecting on port 25, or an incomplete mailbox inventory causing the destination server to reject addresses that SpamExperts has already accepted as valid. Checking the specific bounce message text usually narrows this down quickly, since a bounce generated by the destination server itself reads differently from one generated at the SpamExperts filtering layer.

Do I need to remove my old MX records, or can I lower their priority?

They need to be removed entirely, not just deprioritized, because leaving an old MX record in the zone file at any priority still gives spammers a path to attempt delivery directly to the old server, bypassing SpamExperts filtering altogether, a tactic that actively gets used against domains that leave a lower-priority record in place rather than deleting it. The only records that should remain in the MX set after cutover are the SpamExperts primary and fallback records themselves.

Can I test my SpamExperts setup before going fully live?

Yes, and doing so is a core part of a correct setup rather than an optional extra step. Testing both inbound and outbound flow with real test messages, sent from and to external addresses outside the domain’s own network. At the same time, the old mail server remains reachable as a fallback, confirming that the new configuration works before the old path is removed entirely. This staged approach, configure, test externally, confirm clean for 48 hours, then fully decommission the old fallback, is what keeps a SpamExperts setup from turning into a live troubleshooting exercise on production mail.

Glossary

MX record: A DNS record that tells the internet which mail server(s) accept incoming mail for a domain, and in what priority order.

SPF (Sender Policy Framework): A DNS TXT record listing which servers are authorized to send mail on a domain’s behalf, used by receiving servers to detect spoofed sending sources.

DKIM (DomainKeys Identified Mail): A cryptographic signature attached to outbound mail and verified against a public key published in DNS, confirming the message wasn’t altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance): A policy record that requires SPF or DKIM to pass and align with the domain in the visible From address, and defines what receiving servers should do with mail that fails.

Destination route: The address SpamExperts forwards filtered mail to after scanning, typically the domain’s real mail server or mailbox platform endpoint.

Outbound relay: The configuration that routes a domain’s own sent mail through SpamExperts for scanning before it reaches the public internet.

Quarantine: A holding area for messages the filter can’t confidently classify as clean or spam, pending manual review.

TTL (Time to Live): The duration for which resolvers cache a DNS record before they check for an updated value, directly controlling how quickly a DNS change takes effect globally.