Email Security Renewal: Prove Every Domain and Mail Path Is Covered

Your email security proposal can cover every licensed user and still miss a working mail path.

That gap sits in a secondary domain, an acquired Microsoft 365 tenant, an application relay, a hybrid connector, or a route that delivers directly to the mailbox platform instead of passing through the gateway.

Before you renew, reconcile the commercial and technical scope. Prove which domains, tenants, connectors, relays, and delivery paths are protected. Then test them.

Start with one domain and tenant register

Most renewal reviews begin with mailbox seats and security tiers. Start one layer earlier.

Build a register of every domain your company owns or operates, including domains without employee mail. CISA’s DNS infrastructure guidance calls for an accurate, current inventory of domains owned or operated on the organization’s behalf. A domain can support customer mail, application notifications, aliases, or redirects without appearing in the primary mailbox count.

For each domain, capture:

Field	What to record
Business use	Employee mail, customer mail, application mail, alias, redirect, defensive registration, or retired
Ownership	Registrar, DNS host, business owner, technical owner, and renewal date
Mail platform	Microsoft 365 tenant, Google Workspace account, on-premises system, hosted service, or no receiving service
Recipient scope	Users, shared mailboxes, groups, contacts, catch-all behavior, and external forwarding
Inbound route	Published MX targets, gateway, downstream platform, and fallback path
Outbound route	Mailbox platform, application service, relay, gateway, and internet egress
Security controls	Filtering service, native controls, SPF, DKIM, DMARC, encryption, journaling, and archiving
Commercial treatment	Licensed, included, excluded, separately billed, or unclear
Test status	Last inbound, outbound, spoofing, quarantine, routing, and recovery test

Keep each domain and tenant distinct enough to expose differences.

After an acquisition, users may move while aliases, application senders, shared mailboxes, or old connectors stay behind. A protected-user count does not prove that every tenant, accepted domain, and residual route is covered.

Reconcile what the mail platform accepts

Your public domain list is not automatically the same as the list configured inside the mailbox platform.

Microsoft documents two accepted-domain types in Exchange Online. An authoritative domain delivers to listed recipients and rejects unknown recipients. An internal relay domain can deliver known recipients in Microsoft 365 and relay unknown recipients elsewhere. Review Microsoft’s accepted domains documentation, then export the actual configuration from every tenant.

Match that export against:

Corporate domain and brand inventory
Current DNS zones and MX records
Email security service domain inventory
Recipient and alias exports
Hybrid and coexistence documentation
Acquisition and divestiture records
Application, device, and platform sender inventory
Renewal proposal and license schedule

Every mismatch needs an owner and a decision. A domain may be intentionally excluded, stale, or missing from the security service. An internal relay domain may still support recipients elsewhere.

“Mail is working” does not close the review. Mail can work through a route you did not intend.

Draw the paths, not just the products

A gateway, mailbox platform, archive, and DMARC service are products. Mail moves through paths.

Draw the actual inbound and outbound flow for each distinct scenario:

Internet sender to employee mailbox
Employee mailbox to an outside recipient
Application or device to an internal recipient
Application or device to an outside recipient
Partner or service provider through a dedicated connector
Hybrid server to cloud mailbox
Cross-tenant or coexistence traffic
External forwarding and redistribution
Phishing simulation traffic
Journal or archive copies

Microsoft’s connector guidance lists hybrid mail, partner restrictions, and relay from devices or applications as connector use cases. That is a useful reminder: connectors are not background plumbing. They define trusted paths and can change how controls apply.

Record the source, destination, connector, authentication method, restriction, inspection points, logs, failure action, and owner for each path.

Do not treat the MX record as an access control

An MX record tells senders where you want mail delivered. It does not prove every sender followed that route.

For Microsoft 365 environments using a third-party cloud filter in front of Exchange Online, Microsoft’s mail-flow guidance says the MX record should point to the third-party service. It also recommends restricting Exchange Online so it accepts mail from that service through a properly configured partner inbound connector using a TLS certificate or approved IP addresses.

Test that distinction. If the contract assumes all inbound internet mail passes through the gateway, check whether mail sent directly to Exchange Online is rejected, quarantined, redirected, or accepted. Printers, scanners, applications, and monitoring systems may use routes your diagram missed, so understand legitimate traffic before changing production.

Run the test with the right messaging, security, and provider owners involved. Preserve headers and message traces. If direct delivery succeeds, decide whether it is required, which controls still inspect it, and whether the contract describes it accurately.

A gateway cannot inspect a message it never receives.

Check how layered filtering really works

Buying a gateway in front of Microsoft 365 does not automatically mean both security layers see the original sender the same way.

Microsoft’s Enhanced Filtering for Connectors documentation explains that a service in front of Microsoft 365 can hide the message’s true source IP behind the last hop. Enhanced Filtering can identify the original source in supported configurations where the MX record points to a non-Microsoft filter before Exchange Online.

Verify the configuration instead of assuming the vendor handled it. Ask:

Which service receives internet mail first for each domain?
Which connector identifies the gateway or hybrid server?
Is that connector restricted by the expected certificate or IP ranges?
Does Microsoft 365 identify the original sender correctly after the gateway hop?
Which native protections remain active?
Which rules, allow lists, or bypasses weaken inspection?
Who owns updates when the provider changes an IP range or certificate?
Can both teams trace one message without losing the chain of custody?

Reconcile licenses with coverage units

The bill may use users, mailboxes, domains, tenants, message volume, storage, API calls, or a combination.

Ask the vendor to define each billable and protected unit in writing. Then reconcile the proposal with your register.

A few questions worth pushing on:

Does a licensed user cover aliases across every accepted domain?
How are shared mailboxes, groups, service accounts, and unlicensed recipients treated?
Are acquired or separate tenants included under the same agreement?
Are application senders and SMTP relays inspected inbound, outbound, both, or neither?
Are dormant and defensive domains monitored even if they receive no normal mail?
Does the quoted tier include the reporting, retention, API, encryption, archive, or incident-response functions you use?
What happens to coverage and pricing when users move between tenants?
Which configuration, migration, and connector changes are included services?
What evidence will the provider deliver before and after a change?

Do not accept “all users are covered” as the answer to a domain-and-path question.

Test a coverage matrix before signing

Select at least one valid recipient and one invalid or retired recipient where safe for every active receiving domain. Include separate tests for any route that differs by tenant, gateway, connector, relay, application, or recipient type.

Your matrix should cover:

External inbound mail through the published MX route
Controlled direct delivery to the downstream platform
Outbound mail from employee mailboxes
Outbound mail from approved applications and devices
Cross-tenant and hybrid delivery
Valid aliases, shared mailboxes, and groups
Unknown-recipient handling
Quarantine, release, and administrator alerting
Message trace in every service that claims to inspect the path
Header evidence showing which systems handled the message
Failure behavior when the gateway or connector is unavailable
Rollback after a controlled configuration change

Use safe test messages and approved test accounts. Do not send live malware or attempt an uncontrolled spoofing exercise. Your security team can choose appropriate simulations and evidence methods for the environment.

The result should show which control inspected the message, which policy applied, where it was logged, who received the alert, and what happens when the path fails.

Make the renewal decision domain by domain

Use the evidence to place each domain and mail path into one of four treatments.

Keep the current design when the path is intentional, tested, logged, supportable, and priced correctly.

Correct it when the architecture is sound but a domain, connector, policy, license, owner, or log source is missing or stale.

Retire it when the domain, relay, forwarding rule, connector, or tenant dependency no longer serves a valid business purpose and can be removed through controlled change.

Compare another service or architecture when the current provider cannot cover required domains or tenants, cannot support the intended mail flow, creates unmanageable exceptions, lacks usable evidence, or prices the real scope poorly.

This review does not replace a broader email security program assessment. It answers a narrower renewal question: does the product you are about to buy cover the environment you actually run?

Put coverage evidence into the renewal record

Before approval, attach:

Domain, tenant, recipient, and sender inventory
Current and target mail-flow diagrams
MX, accepted-domain, connector, relay, and policy exports
License and commercial reconciliation
Controlled test results and message traces
Open gaps with owners and due dates
Provider implementation and support responsibilities
Change, retest, and rollback requirements
Documentation and knowledge-transfer deliverables
Offboarding, export, and configuration-removal obligations

If outside implementation work is required, make the completion evidence explicit in the technology implementation SOW. Do not let “configure email security” stand in for a domain list, path list, test plan, and accepted result.

Email security renewal is a coverage decision. Prove the coverage before you negotiate the rate.

If your secure email gateway, Microsoft 365 security, email archive, or managed security agreement is approaching renewal, request a Contract and Spend Risk Review. Catch Advisors can help you reconcile the proposal with your domains, tenants, licenses, mail paths, implementation scope, and test evidence before you renew or compare providers.