Premium Business Email Hosting Support & SLAs Explained

Priority Support Tiers That Actually Change Outcomes

Support tiering determines how quickly a qualified engineer is assigned to a mailbox outage, rather than a chatbot script reading back a knowledge base article. For premium business email hosting, the tier structure is the single clearest signal of what a provider will do when something goes wrong at 11 p.m. on a Friday.

How Provider Support Tiers Are Actually Structured

A genuine priority support tier separates customers by contract value and business impact, not just by how much they’re willing to pay for a badge on their invoice. Tier one typically covers general account questions, password resets, and client configuration, routed through a shared queue with response windows measured in hours. Tier two handles service-affecting issues such as delayed mail delivery, DNS misconfiguration, or authentication failures, and is staffed by engineers who can access mail server logs directly rather than escalating internally. Tier three is reserved for infrastructure-level incidents: routing failures, data center connectivity loss, or security events touching multiple domains at once, and is staffed around the clock rather than during business hours only.

The distinguishing detail for premium plans is not the existence of three tiers, as most providers claim, but whether a domain administrator can reach tier two directly rather than being routed through a generic front-line queue first. Reseller-managed accounts under an Authorized Partner and Trusted Reseller arrangement often have this direct routing built into the account configuration, since the reseller has already flagged the account as a business-critical domain rather than a single consumer mailbox. That single routing decision, made once at provisioning, quietly determines how every future ticket gets handled.

What “Premium” Should Mean Beyond a Marketing Label

Premium support should be verifiable in the contract, not just implied by the price point. Look for a named response-time figure associated with a specific severity level, not a vague promise of “priority handling.” A support agreement that says “critical issues receive expedited attention” without defining “critical,” without a time figure, and without naming who determines severity is not a premium SLA, regardless of what the sales page calls it. The absence of specificity is itself useful information about how disputes will be handled later.

Business owners evaluating two similarly priced plans should ask for the actual severity-level table before signing, not after the first outage. Renewal reviews often reveal a business email account that was sold as “premium support” but whose contract never defined a single measurable commitment, which only becomes apparent once a real incident forces someone to check. A provider willing to put response windows in writing, tied to severity levels a customer can self-classify by, signals that the support tier is a real operational structure rather than a pricing-tier name.

Free/Low-Cost Webmail vs. Premium Business Email Hosting

Response Time Commitments and How They’re Measured

Response time is the number most business buyers fixate on, and it’s also the number most frequently defined loosely enough to be meaningless in practice. Understanding how a provider measures the clock, not just what number they quote, determines whether the commitment holds up during an actual incident.

The Difference Between Acknowledgment and Resolution

A response time commitment almost always refers to acknowledgment, not resolution, and conflating the two is the most common misunderstanding in email hosting contracts. Acknowledgment means a human or automated system confirms receipt of a ticket and assigns a severity level, typically within 15 minutes to 4 hours, depending on the tier. Resolution, the point at which the actual mail flow, authentication, or delivery issue is fixed, carries a separate, usually longer, target that reputable providers state independently rather than bundling into a single ambiguous figure. A contract that cites only one number is worth questioning as to which of the two it actually describes.

Reseller-managed provisioning speed plays a direct role here: when a business email account is provisioned and managed through an Authorized Partner rather than self-serve signup, initial ticket routing already carries account context, domain history, prior incidents, and DNS records on file that a self-serve support queue has to reconstruct from scratch on every new ticket. That saved reconstruction time often accounts for the gap between a stated 1-hour acknowledgment window and the 15-minute window some reseller-routed accounts actually experience in practice. It is a provisioning-model effect, not a marketing claim.

Severity Classification and Why the Provider, Not the Customer, Owns It

Severity classification determines which response clock starts, and most contracts reserve the right to reclassify a customer-reported “critical” issue down to “high” or “standard” after initial triage, which is a legitimate operational safeguard but also a common source of dispute. A well-written SLA defines each severity level by observable symptom, “complete inability to send or receive mail across the domain” for critical, versus “delayed delivery affecting a subset of recipients” for high, rather than leaving classification to subjective judgment on either side.

Heading into a renewal cycle, it’s worth checking whether the severity definitions in a current contract still match what actually happened during the last reported incident, since providers periodically revise these tables and customers rarely reread them until something goes wrong again. A renewal review is a reasonable time to request the current severity table in writing and compare it line by line with the originally signed version, since language quietly narrows over multiple renewal cycles more often than it broadens.

Uptime Guarantees and What Counts as Downtime

An uptime percentage on a sales page means little without knowing what counts as downtime, how it’s measured, and what remedy, if any, follows a breach. This section covers the mechanics behind the number, not just the number itself.

Reading an Uptime SLA Past the Headline Percentage

A stated uptime figure such as 99.9% translates to roughly 43 minutes of allowable monthly downtime, and the gap between 99.9% and 99.99% is the difference between 43 minutes and about 4 minutes a month. This distinction matters enormously for a business that runs time-sensitive communications. What the headline percentage doesn’t show is the measurement scope: whether it covers only the mail transfer layer, or also webmail access, mobile sync, and the admin console, since a provider can technically hit 99.9% on core mail delivery while webmail access sits well below that figure during the same period.

Redundant data center architecture is the infrastructure detail that actually produces a defensible uptime figure rather than a marketing one. Mail servers distributed across geographically separate facilities, with automatic failover that doesn’t require manual intervention to reroute traffic, are what keep a single hardware failure or regional connectivity loss from becoming a customer-facing outage. A provider running from a single data center can still advertise a high uptime number based on historical averages. Still, that number carries materially more risk going forward than one backed by architectural redundancy, and the distinction rarely appears anywhere in the marketing copy.

Downtime Exclusions and Remedy Mechanics

Nearly every uptime SLA carries exclusions for scheduled maintenance, force majeure events, and issues originating from the customer’s own DNS or network configuration, and these exclusions are legitimate but need to be checked against how generously “scheduled maintenance” is defined. A provider that reserves an unbounded right to schedule maintenance windows without minimum advance notice has effectively built an escape hatch into the uptime number, regardless of how strict the stated percentage looks.

Remedy for an uptime breach is typically a service credit calculated as a percentage of the monthly fee, not a cash refund. The credit tiers usually step up only after a breach crosses a threshold, meaning a provider that dips to 99.85% in a 99.9%-guaranteed month may owe nothing at all if the contract’s remedy table starts at 99.0%. Reading the remedy table, not just the guarantee line, is the only way to know what an uptime commitment is actually worth if it’s ever tested.

Support Channels Available to Business Email Customers

Not every support channel has the same response commitment, and knowing which channel to use for each issue severity helps avoid losing time to the wrong queue during an actual incident.

Matching the Channel to the Issue

Dedicated mailbox infrastructure for business accounts typically comes with a dedicated support channel, a named account contact, or a business-tier phone line separate from the general email or ticket queue used for individual consumer mailboxes. This separation exists because a business account issue often affects an entire domain’s worth of users simultaneously. In contrast, a consumer mailbox issue affects one inbox, and routing both through the same undifferentiated queue would mean that business-critical tickets would wait behind low-urgency individual requests.

Live chat and phone channels generally carry faster acknowledgment than ticket-based email support. Still, only for issues that don’t require deep log access, a locked account, or a basic configuration question, a chat resolution is faster than for a DNS propagation issue, which requires an engineer to pull actual server-side records regardless of which channel initiated the ticket. Business customers get the most value from knowing in advance which channel matches which issue type rather than defaulting to whichever channel feels fastest to open.

Self-Service Resources and Their Actual Limits

Knowledge-base articles and automated diagnostic tools handle a meaningful share of routine issues, password resets, basic client setup, and DNS record templates without requiring a live agent at all, and a provider investing in genuinely up-to-date self-service documentation often signals operational maturity rather than trying to deflect support volume. The test is whether the documentation matches the current product interface; outdated screenshots and deprecated setup steps are reliable signs that the self-service layer is under-maintained compared to the live support team.

Where self-service resources reliably fall short is in anything related to authentication records, mail routing, or account-level security settings, since a wrong DNS edit made independently based on a generic article can cause the exact outage a customer was trying to prevent. Providers that gate DNS-level or security-setting changes behind a support ticket rather than a fully self-service toggle usually do so because those changes carry an outsized risk of misconfiguration, not because the interface couldn’t technically expose the option.

Priority Escalation Paths When First-Line Support Stalls

Escalation paths matter most exactly when they’re hardest to invoke, during an active outage when a first-line agent has run out of standard troubleshooting steps. A defined, known-in-advance escalation path prevents that moment from becoming a stalled ticket.

What a Real Escalation Path Looks Like on Paper

A documented escalation path names the trigger condition, typically “no meaningful progress within X hours of acknowledgment”, and specifies who the ticket moves to next, rather than leaving escalation to the discretion of whichever agent currently holds the ticket. Priority support tiers built around this structure give business account administrators a defined path to request escalation directly, rather than waiting for the assigned agent to decide independently whether the issue warrants escalation.

The detail worth checking before signing is whether escalation is customer-initiated or provider-initiated only. A contract that gives the customer no formal right to request escalation, only a provider’s internal discretion to escalate when it judges appropriate, puts the business in a weaker position during exactly the incidents where speed matters most. Premium contracts distinguish themselves by naming both the trigger and the customer’s right to invoke it.

Communication Cadence During an Active Escalation

Once a ticket escalates, the update cadence matters as much as the escalation itself. A business waiting on a domain-wide mail outage needs status updates at a defined interval, not silence until the fix ships. Reputable providers commit to update intervals scaled to severity: continuous or near-continuous updates for critical, domain-wide incidents versus periodic updates for lower-severity issues still working through standard troubleshooting.

A pattern worth watching for during any live incident is whether status updates contain new information each time or restate “still investigating” on a timer to satisfy a contractual update requirement without substance. The latter technically satisfies a communication SLA while providing no operational value to the customer trying to plan around the outage, and it’s a meaningful distinction between providers who treat the update commitment as a genuine operational discipline and those who treat it as a compliance checkbox.

Migration Support and Onboarding Assistance

Migrating an existing domain’s mail to a new host is where support quality gets tested earliest, often before the first invoice is even due, and it’s a distinct discipline from ongoing account support.

What a Migration Concierge Process Actually Involves

A genuine migration concierge service assigns a specific engineer or small team to a business account for the migration window, rather than routing each step through the general support queue as a fresh, unconnected ticket. That continuity matters because a mail migration touches DNS records, historical mailbox data, calendar and contact syncing, and client-side reconfiguration across every user on the domain, steps that depend on each other in sequence, and a general queue handling them as disconnected tickets loses the context between steps.

The migration window is also when DNS propagation delay is the most common source of business disruption, since MX record changes can take anywhere from a few hours to 48 hours to fully propagate, depending on the previous record’s time-to-live setting. A concierge-managed migration typically checks the existing TTL value in days in advance and, where possible, lowers it ahead of the cutover to shrink the propagation window, a step that’s easy to skip in a self-service migration and difficult to fix retroactively once the cutover has already started.

Onboarding Support Beyond the Initial Cutover

Onboarding support that ends the day mail starts flowing leaves a gap exactly where new problems tend to surface: client-side sync issues on individual devices, calendar permission errors, or shared mailbox access that wasn’t configured correctly during the bulk migration. A stronger onboarding commitment extends dedicated support access for a defined period past cutover, commonly 30 to 90 days, rather than immediately returning the account to the standard support queue.

Migration support quality also shows up in how much manual configuration is left to the customer’s own IT staff versus handled by the provider’s migration team. A domain with 200 mailboxes, migrating individual client configurations by hand, is a materially different support burden from one where bulk configuration profiles are pushed automatically. This difference is rarely quoted as a specific number in marketing materials; it only becomes apparent when comparing actual project plans across providers during the sales process.

Security Incident Response and SLA Coverage

Security incidents have their own response track, distinct from general service issues, because the cost of delay compounds differently: a phishing campaign or a compromised account left unaddressed for hours can spread across an entire domain’s contact graph.

How Security-Specific SLAs Differ From General Support SLAs

Layered anti-spam and anti-virus filtering forms the first line of defense before a security incident ever reaches a support ticket, screening inbound mail through multiple detection passes, reputation scoring, content analysis, and attachment sandboxing, rather than a single spam-score threshold. When that filtering layer catches something significant, such as a coordinated phishing campaign targeting a specific domain, the provider’s security-incident SLA typically activates independently from the standard support-ticket clock, often with acknowledgment windows measured in minutes rather than hours.

A security incident SLA generally specifies a containment step distinct from resolution: locking a compromised account, forcing a password reset across affected mailboxes, or temporarily quarantining inbound mail from a flagged source, all of which can happen before the underlying cause is fully diagnosed. Contracts that don’t distinguish between containment and full resolution tend to understate how quickly a provider can limit damage, since containment is usually the faster and more urgent of the two steps.

What Gets Disclosed and When

Breach notification timing is a detail business buyers frequently overlook until it matters. Most jurisdictions and industry frameworks governing business communication require timely disclosure once a security incident affecting customer data is confirmed, and a provider’s contract should specify its own internal notification target rather than merely reference “applicable law” without a number. A provider unwilling to commit to a specific notification window, even a conservative one, is signaling something worth asking about directly before a domain moves any sensitive correspondence onto the platform.

Renewal reviews often reveal a stale SPF that nobody remembers adding, and a genuinely security-conscious support process treats such a legacy misconfiguration as worth flagging proactively during a security review rather than waiting for it to be exploited. A provider that only reacts to reported incidents, without any proactive audit component built into the premium support tier, is offering a materially thinner security commitment than the marketing language around “advanced security” might suggest.

Data Backup, Recovery, and Retention Commitments

Backup and recovery terms determine what happens after data loss, whether from accidental deletion, a failed migration, or a security incident, and the specifics here vary more between providers than almost any other SLA component.

Backup Frequency, Retention Windows, and Recovery Point Objectives

Storage pooling across a provider’s infrastructure allows backup snapshots to be taken and retained more efficiently than isolated per-mailbox backups. Still, the customer-facing number that actually matters is the recovery point objective, how much data could be lost between the last backup and the moment of failure. A provider running backups every 24 hours has a recovery point objective of up to 24 hours, meaning a mailbox restored after a midday failure could lose most of that day’s mail, while more frequent incremental backups substantially reduce that exposure window.

Retention windows for deleted or archived mail vary widely, commonly ranging from 30 days for standard consumer plans to a year or longer for business-tier accounts, and the distinction matters for compliance-driven industries where email retention isn’t optional. A contract should state retention duration explicitly per mailbox type rather than as a single blanket figure, since shared mailboxes, individual accounts, and archived former-employee accounts often carry different default retention periods that a business needs to know before an audit forces the question.

Recovery Time and What a Restore Actually Requires

Recovery time objective, how long an actual restore takes once initiated, is a separate figure from recovery point objective, and providers rarely quote both clearly in the same place. A single mailbox restore from a recent backup typically completes faster than a domain-wide restore following a broader incident, and a premium support tier should specify both scenarios rather than a single generic restore time that only applies to the simpler case.

Whether a restore requires a support ticket and manual engineer involvement, or can be self-initiated through an admin console, is itself a meaningful SLA detail, since self-service restore removes the acknowledgment-time delay entirely for straightforward cases. A business evaluating two providers with similar stated recovery point objectives should ask specifically whether restores are self-service or ticket-gated, since that operational detail often matters more in practice than the underlying backup frequency number.

Mobile and Multi-Device Support Expectations

Business email is increasingly read and managed on phones and tablets as much as on desktop clients, and support coverage for mobile access carries its own set of expectations distinct from desktop troubleshooting.

Native Client Behavior Versus Third-Party App Support

Mobile vs. native client behavior is a genuine support-scoping distinction: a provider’s support team can generally diagnose and fix issues within its own native mobile app or webmail interface with full log access, but troubleshooting a third-party client, a general-purpose mail app configured via IMAP or Exchange ActiveSync, is limited to server-side checks, since the provider has no visibility into that third-party app’s internal behavior. Support contracts should be explicit about this boundary rather than implying blanket “mobile support” that quietly narrows once a ticket involves an app outside the provider’s own ecosystem.

Push notification reliability, calendar sync accuracy, and contact synchronization behave differently between native apps and generic IMAP configurations, and a premium support tier that actually tests and documents behavior across common client combinations, rather than only supporting its own branded app, gives business users meaningfully more coverage. This is worth confirming directly, since sales material rarely distinguishes between “we support mobile access” and “we support your specific combination of device and mail app.”

Two-Factor Authentication and Device-Level Lockouts

Two-factor authentication enforcement, while primarily a security feature, creates a common support scenario: a user locked out of a device after losing access to their second factor, whether due to a lost phone or a deactivated authenticator app. Premium support tiers typically define a faster path for this exact scenario, often a phone-verified identity check rather than the standard password-reset flow, because a locked-out executive during a time-sensitive period is a materially higher-urgency case than a routine password reset.

The support burden here scales with how strictly 2FA is enforced across a domain; an administrator who has enabled mandatory 2FA for all users takes on responsibility for a predictable trickle of lockout tickets, and a provider’s stated turnaround time for identity-verified device recovery is worth checking before mandating 2FA domain-wide, since a slow recovery process can turn a security improvement into a productivity cost during onboarding of new hardware.

Compliance, Documentation, and SLA Reporting

Beyond day-to-day support, a premium contract should provide a business administrator with ongoing visibility into whether SLA commitments are actually being met, not just a promise made at signing.

SLA Reporting and What to Ask a Provider to Show

Per-domain key provisioning, the practice of issuing distinct authentication keys and configuration per domain rather than sharing infrastructure credentials across unrelated customer accounts, supports cleaner SLA reporting, since incident logs and uptime records can be pulled per domain rather than requiring the provider to separate one customer’s data from a shared infrastructure log. Business administrators evaluating a provider’s transparency should ask whether uptime and incident history are available on request, and whether that history is domain-specific or only available as an aggregate platform-wide figure that says little about their own account’s experience.

A provider willing to share historical incident reports and resolution times for past tickets on request is demonstrating a level of accountability that a provider offering only forward-looking promises is not, and this distinction is one of the more reliable ways to differentiate genuine premium support from support that’s premium in name only.

Category-Standard Providers

Documentation for Audits and Internal Compliance Reviews

Businesses in regulated industries, financial services, healthcare-adjacent sectors, and legal often need to provide evidence of email service continuity and data-handling practices during internal or external audits. A provider’s willingness to supply standard documentation templates covering uptime history, backup retention policy, and security incident response procedure removes a meaningful amount of manual work from that process. This documentation should be available as a standing request rather than something assembled ad hoc only when a specific audit forces the question.

Heading into any compliance review cycle, it’s worth confirming in advance which documentation a provider can produce on short notice versus which reports take days to compile, since audit timelines rarely accommodate a multi-day wait for basic service records. A provider that maintains this documentation continuously, rather than reconstructing it after the fact, is operationally better positioned to support a business through a real audit.

Frequently Asked Questions

What counts as a “critical” issue under a business email SLA?

A critical issue is typically defined as a complete inability to send or receive mail across the entire domain, not just for one user, and this distinction determines which response clock applies. A single employee unable to log in is usually classified as high or standard severity. At the same time, a domain-wide outage affecting all mailboxes qualifies as critical and triggers the fastest contracted response window, often under one hour for acknowledgment. Providers reserve the right to reclassify a reported issue after initial triage if the actual symptoms don’t match the customer’s initial severity label, which is worth knowing before submitting a ticket, since the classification determines everything that follows, including escalation eligibility and any service-credit calculation if the issue later becomes a documented SLA breach.

How is downtime actually calculated for an uptime SLA?

Downtime is generally measured from the moment a monitoring system detects that the mail transfer layer is unreachable until the service is confirmed restored. This measurement typically excludes scheduled maintenance windows disclosed in advance under the contract’s maintenance notice terms. Some providers measure only core mail delivery, while others include webmail access and mobile sync in the same calculation, so two providers advertising the same 99.9% figure may be measuring materially different scopes of service. It’s worth requesting the specific monitoring methodology in writing, including how frequently uptime checks run, since a provider checking every five minutes catches shorter outages than one checking hourly, which affects the accuracy of the reported percentage over a billing period.

Does premium support include help with DNS record configuration?

Yes, premium business email support typically includes direct assistance with MX, SPF, DKIM, and DMARC record configuration, since these records are foundational to mail delivery and deliverability, not optional add-ons. A support engineer with domain-level access can review existing DNS records for errors, a common source of delivery problems that a customer configuring records independently might not catch, and provide the exact record values needed rather than generic templates. This assistance usually extends through the initial setup and any subsequent domain changes, such as adding a new subdomain for a specific department. However, ongoing DNS management for unrelated services outside the email hosting relationship is generally outside the scope of support.

What happens if a provider misses its stated response time?

Most SLA contracts specify a service credit as the remedy for a missed response or resolution time, calculated as a percentage of the affected billing period’s fee rather than a fixed cash amount. The credit is typically applied automatically to the next invoice rather than requiring a separate refund request. Some contracts require the customer to formally request the credit within a defined window after the breach, so it’s worth confirming whether credits apply automatically or need to be claimed. A pattern of repeated missed response times, even when each instance earns only a small credit, is generally a more reliable signal to evaluate than any single missed SLA, since it points to a structural support capacity issue rather than an isolated incident.

Is 24/7 support the same as a 24/7 response guarantee?

Not necessarily. 24/7 support availability describes when a customer can reach a support channel, while a response guarantee describes how quickly that channel commits to acknowledging and acting on a ticket. A provider can offer round-the-clock availability without a fast, guaranteed response outside business hours. It’s worth checking whether the contracted response windows apply uniformly around the clock or only during a defined business-hours period, since some providers quietly widen response targets overnight and on weekends even while keeping a support line technically staffed at all times. A domain running mission-critical communication across multiple time zones should confirm this distinction specifically rather than assuming 24/7 availability implies 24/7 response speed.

How long does a business email migration typically take?

A straightforward migration for a small business domain, with proper DNS preparation in advance, typically completes the mail cutover within a single business day. However, a full historical data migration for existing mailboxes can take considerably longer, depending on the total mailbox size and the number of users involved. Larger domains with hundreds of mailboxes or substantial historical archives typically require a phased migration plan spanning several days to weeks to avoid disrupting active business communication during the transition. The DNS propagation window, separate from the actual data transfer, typically adds 4-48 hours before all recipients’ mail servers consistently route to the new host, which is why lowering the existing DNS record’s time-to-live value in advance meaningfully shortens the overall cutover window.

What backup retention period is appropriate for a small business?

There’s no universal answer, since appropriate retention depends on industry-specific compliance requirements and how the business itself uses email for record-keeping. Still, a common baseline for standard business use is 90 days of accessible backup, with longer archival retention available for compliance-driven accounts. A business in a regulated industry, legal, financial, or healthcare-adjacent, often needs retention measured in years rather than months to satisfy audit or litigation-hold requirements, and this should be confirmed against the specific regulatory framework that applies rather than assumed from a general business plan’s default settings. It’s worth reviewing retention terms specifically for shared mailboxes and former-employee accounts, since these categories sometimes default to shorter retention windows than active individual mailboxes under the same contract.

Can support help recover a single accidentally deleted email versus a full mailbox?

Yes, most premium business email plans support granular recovery of individual deleted items within a defined recovery window, often 30 days for standard deletion, separate from a full mailbox restore, which is a more involved process typically reserved for broader data loss scenarios like account compromise or accidental bulk deletion. Single-item recovery is frequently handled via an admin console or a user-facing “recover deleted items” function, avoiding the need for a support ticket entirely in straightforward cases. A full mailbox restore from an earlier backup point, by contrast, usually requires support team involvement and takes longer to complete, since it involves reconstructing the entire mailbox state rather than retrieving a single flagged item.

How does two-factor authentication affect support response for locked-out users?

When mandatory two-factor authentication locks a user out after losing access to their second factor, a lost phone or uninstalled authenticator app being the most common cause, premium support typically offers an expedited identity-verification path distinct from a standard password reset, since the standard flow alone can’t restore 2FA access. This usually involves a phone-verified identity check or a documented manager approval process to re-provision the second factor without compromising the account’s security posture. Domain administrators enabling mandatory 2FA domain-wide should confirm the turnaround time for this recovery path in advance, since it directly affects how much of a productivity delay a lost device or phone upgrade creates for an employee mid-workday.

Does the support SLA cover third-party apps connected to a business mailbox via IMAP or API?

Support scope for third-party apps connected through IMAP, POP3, or an API integration is generally limited to server-side verification, confirming the mail server itself is functioning correctly and issuing appropriate authentication, rather than troubleshooting the internal behavior of the third-party application itself. If a CRM or marketing tool connected via API stops syncing correctly, a provider’s support team can confirm whether the mail server side of that connection is healthy, but resolving an issue specific to the third-party tool’s configuration typically falls to that tool’s own support channel. This division of responsibility is worth clarifying before relying heavily on a specific third-party integration for business-critical workflows, since it determines which support team to contact first when something breaks.

Glossary

Acknowledgment window: The contracted time within which a provider confirms receipt and severity classification of a support ticket, distinct from the time actually required to resolve the issue.

DKIM (DomainKeys Identified Mail): An email authentication method that attaches a digital signature to outgoing mail, allowing receiving servers to verify the message wasn’t altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy layer built on SPF and DKIM that tells receiving mail servers how to handle messages that fail authentication checks.

MX record (Mail Exchanger record): A DNS record specifying which mail servers are responsible for receiving email on behalf of a domain.

Recovery point objective (RPO): The maximum amount of data, measured in time, that could be lost between the last backup and a failure event.

Recovery time objective (RTO): The targeted duration for restoring service or data after a failure or data-loss event.

Service credit: A partial refund or account credit, usually calculated as a percentage of the billing period fee, issued when a provider fails to meet a contracted SLA metric.

Severity classification: The categorization of a reported issue by business impact, which determines which response and resolution time targets apply.

SPF (Sender Policy Framework): A DNS record listing which mail servers are authorized to send email on behalf of a domain, used to reduce spoofing.

TTL (Time to Live): A DNS record setting that determines how long other servers cache that record before checking for updates, directly affecting how fast DNS changes propagate.