# Multi-tenant email authentication monitoring > Multi-tenant email authentication monitoring needs tenant-level evidence, ownership, triage, verification, and client reporting for each sending domain. Multi-tenant email authentication monitoring is an operating discipline for keeping each client's email evidence, ownership, exceptions, and follow-up work separate while reviewing portfolio risk as a whole. An MSP should use one repeatable tenant record, investigate anomalies at the tenant level, assign remediation to the party that controls the affected system, and report decisions with the evidence behind them. ## Quick takeaways - A portfolio view should identify where to investigate, but the investigation record belongs to the affected tenant. - A compromised customer, tenant, or agent can put other senders' mail at risk when they share sending reputation. - Every open item needs a tenant, domain, evidence source, owner, next action, and review date. - The MSP can coordinate evidence and recommendations, while clients and service providers retain control over their own systems. - A report should distinguish observed evidence, unresolved questions, accepted exceptions, and completed verification. - This workflow is a Palisade operating framework, not a protocol requirement or service-level commitment. ## Operating context and ownership Multi-client monitoring becomes difficult when a portfolio queue hides the difference between a tenant with a routine DNS question and a tenant with an active sending problem. The MSP needs a portfolio-level way to prioritize work, but each investigation needs its own tenant boundary, evidence record, owner, and approval path. MailChannels warns that "[a] compromised customer, tenant, or agent can damage your sending reputation and put every other sender's mail at risk." Its guidance also recommends tracking behavior at the individual sender level and isolating problems before they spread across a platform. [MailChannels describes sender-level tracking and isolation](https://mailchannels.com/) as a control for organizations that send on behalf of customers, tenants, or agents. For an MSP, that premise supports a practical separation of responsibilities: - The MSP owns the operating process, evidence collection, triage queue, client communication, and escalation record. - The client owns business decisions, approval for material changes, and confirmation of legitimate sending activity. - The DNS host controls publication of DNS changes when the MSP does not have delegated access. - The sender or sending-platform owner controls its authentication configuration and message path. - The receiving mailbox provider controls its own acceptance, filtering, and reputation decisions. The workflow does not assume that a single status, dashboard, or public lookup proves production behavior. Keep public DNS results separate from evidence from the configured sender, client confirmation, or delivered-message review. The [Palisade MSP page](/for-managed-service-providers) is the relevant internal starting point for teams building a repeatable managed-email workflow. ![Portfolio workflow showing separate tenant investigation records feeding a shared MSP review queue](/images/editorial/multi-tenant-email-authentication-monitoring/multi-tenant-email-authentication-monitoring-portfolio-workflow.webp "1200x829") *Source: Palisade.* ## Evidence to collect Use one working record for each tenant-domain combination. This prevents a portfolio summary from collapsing different kinds of evidence into one unsupported status. ![Tenant evidence record showing client, domain, evidence, owner, next action, and review date](/images/editorial/multi-tenant-email-authentication-monitoring/multi-tenant-email-authentication-monitoring-portfolio-workflow.webp "1200x630") *Source: Palisade.* A useful record includes: - The client organization and the domain under review. - The specific evidence being reviewed, such as a client report, sender record, DNS response, support case, or redacted message evidence. - The owner who can answer the next question or make the next approved change. - A precise next action, rather than a broad instruction such as "fix authentication." - A dated review point so blocked issues do not disappear from the service queue. - The distinction between a client-confirmed sender, an observed sender, an unknown item, and a retired path. Use a portable format that can move between an MSP ticketing system, client report, and internal operating queue: ```yaml client: example-client domain: yourdomain.com evidence: client-confirmed sending path needs tenant-level review owner: client-email-owner next_action: confirm the sender and provide redacted verification evidence review_on: 2026-08-27 ``` This record is a Palisade operating framework. It does not establish whether a sender is authorized, whether a message will reach a recipient, or whether a provider will make a particular delivery decision. For foundational context on the subject, link client stakeholders to [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter). Keep the operational record focused on what the MSP can show, who must respond, and what remains unknown. ## How to run the workflow ### 1. Establish the tenant boundary Owner: MSP service owner. Input: client scope, domain list, contacts, and service agreement. Output: one tenant record for each in-scope domain. Start by confirming which legal or operational client owns each domain and who can approve investigation and changes. Do not place domains from different clients in one remediation ticket merely because they appear in the same portfolio queue. Record the client approver, technical contact, DNS change owner, and sender owner where known. If those roles are missing, mark the tenant as blocked and request the missing ownership decision before treating the item as ready for remediation. ### 2. Collect evidence without merging tenant records Owner: assigned MSP analyst. Input: tenant record and available evidence. Output: dated evidence entries with a stated confidence level. Collect evidence under the relevant tenant-domain record. Note whether the item comes from a client statement, a public lookup, a support report, or an observed sending event. A public result may help identify a question, but it does not prove the production sending path or a mailbox provider's private decision. Do not copy a finding from one tenant into another tenant's record unless the shared system and scope have been confirmed. Shared vendors can create similar symptoms, but similar symptoms do not prove a shared cause. ### 3. Triage by spread and business impact Owner: MSP service owner with client input. Input: open tenant records and dated evidence. Output: prioritized queue and escalation decision. Prioritize issues that may affect more than one sender or that involve a potentially compromised tenant. The sender-isolation principle described by [MailChannels](https://mailchannels.com/) supports investigating the affected sender before a problem spreads across a shared sending environment. Keep triage language observable: - "Tenant has an unconfirmed sender and needs client confirmation." - "Tenant evidence conflicts with the current sender inventory." - "Tenant has a business-critical sending path without a named owner." - "Tenant needs a post-change verification record." Avoid labels such as "secure," "fixed," or "compliant" when the record only shows a partial check. ### 4. Assign remediation to the controlling party Owner: MSP service owner. Input: narrowed tenant issue and ownership record. Output: an owner-specific action with approval boundary. The MSP may coordinate the action, but the party that controls the sender, DNS host, or client approval must own the applicable change. Write the action so the completion evidence is clear. For example, ask the client to confirm whether a sending path is legitimate, ask the DNS owner to review an approved change request, or ask the sender owner for redacted evidence from the exact production path. Do not ask a client to "fix email authentication" without identifying the tenant, domain, evidence gap, and responsible party. The [Palisade inbound-email-authentication article](/learning/how-does-palisade-handle-dmarc-for-inbound-emails) can help frame internal discussion about published product documentation. It does not replace tenant-specific evidence or client approval. ### 5. Verify the same tenant and path Owner: MSP analyst and the responsible client or sender owner. Input: completed action and new evidence. Output: verified, unresolved, or escalated status. Verification must return to the same client, domain, and stated issue. A change reported by a vendor or a public check can be useful evidence, but it does not establish that every future message will authenticate or receive a particular delivery outcome. Record what was checked, when it was checked, who supplied the evidence, and what question remains open. If the original evidence cannot be reproduced, keep the item open or classify it as an accepted exception. Do not close it because a separate tenant has a similar successful result. ### 6. Publish a client-readable report Owner: MSP account or service owner. Input: tenant records, completed actions, blocked items, and review dates. Output: tenant report and portfolio summary. The tenant report should separate four states: - Evidence observed. - Action assigned or completed. - Exception accepted by the client. - Decision or evidence still needed. The portfolio summary can show queue age, blocked ownership, unresolved sender questions, and completed reviews. It should not present one score as proof that every message path is monitored, authenticated, or accepted by every receiver. ## Exceptions and escalation Use a decision tree that keeps client boundaries intact: - If the tenant has evidence but no confirmed owner, request a client ownership decision and set a review date. - If the tenant has a known sender but the sender owner cannot provide verification evidence, keep the item open and escalate through the client contact. - If the issue may affect shared sending reputation, isolate investigation to the implicated tenant or sender first, then assess whether other tenant records show independently supported evidence. - If a client requests a change, confirm the approving authority and the rollback or incident contact before any production action. - If the evidence points to a receiving mailbox provider's private decision, route the issue to the relevant provider process or client account owner. The MSP cannot infer that decision from a general portfolio status. - If an active incident, credentials, private customer data, or production access is required, pause the workflow until the authorized party provides the required direction. A client can accept an exception, but the report should retain the evidence, decision owner, date, and next review point. Accepted risk is a service decision, not a technical verification result. ## Reporting and success measures Use a regular cadence that matches the service agreement and the client's business calendar. The report artifact should make accountability visible without claiming an unsupported SLA or security outcome. Track operational measures such as: - In-scope tenant domains with a named owner. - Open records without a next action. - Items past their review date. - Exceptions awaiting client acceptance. - Completed verification records with dated tenant evidence. - Portfolio items that may need sender-level investigation. These measures describe the health of the operating process. They do not prove inbox placement, protection against every compromise, or continuous monitoring of every message path. For clients that need a wider email-security discussion, [Sublime email security](/learning/sublime-email-security) offers related reading. Keep the managed-service report specific to the tenant evidence and service decisions at hand. ## Build a portfolio queue that preserves tenant evidence A recurring portfolio workflow needs more than a one-time public check. Start with separate tenant records, assign each unresolved item to the party that controls the next step, and preserve the evidence needed for a client decision. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=multi-tenant-email-authentication-monitoring) Palisade does not replace client approval, change a client's DNS without authorized access, determine a mailbox provider's private decision, or guarantee delivery for every future message. ## Sources and further reading - [MailChannels](https://mailchannels.com/) - [Palisade for managed service providers](/for-managed-service-providers) - [What is email authentication and why does it matter?](/learning/what-is-email-authentication-and-why-does-it-matter) - [What Palisade's published documentation covers about inbound email authentication](/learning/how-does-palisade-handle-dmarc-for-inbound-emails) ## Frequently asked questions ### What is multi-tenant authentication? In an MSP setting, multi-tenant authentication means running email authentication for many client organizations at once, where each client owns its own domains, evidence, and approvals. The technical work is the same SPF, DKIM, and DMARC as for a single company, and what changes is the ownership boundary between them. Keep one record per client and domain so a portfolio view never merges two clients' evidence. ### How can I tell if my email is being monitored? Ask whoever runs the monitoring, because nothing in your mailbox shows it. If an MSP or service provider watches your domains, ask which domains are in scope, what evidence they collect, who receives the alerts, and how they verify a problem on a specific sending path. If nobody can answer those questions, your domains are probably not being monitored at all. ### What are the three pillars of email authentication? People using that phrase almost always mean SPF, DKIM, and DMARC. SPF lists which servers may send for your domain, DKIM signs each message so a receiver can confirm it was not altered, and DMARC checks whether either result aligns with your visible From domain and says what receivers should do when neither does. It is a handy label rather than a formal standard, so do not let it stand in for a real inventory of each client's senders. ### Can an MSP use one portfolio report for every client? No, because each client needs its own record of domains, evidence, approvals, exceptions, and owners. A portfolio view is useful for deciding what to work on next, and that is all it should carry. Merging the underlying records hides which tenant actually needs action. ### Does a public check prove that a client's email is monitored? No, because a public check only reads what DNS publishes at that moment. It cannot show the production sending path, a receiver's private decision, whether anyone is watching the domain continuously, or how future mail will be delivered. Monitoring is proved by the reports someone collects over time, not by a single lookup.