# MXroute > MXroute is an email hosting provider. Customers bring their own domains, configure their own DNS, and use MXroute for sending and receiving email. This document is intended for AI agents, assistants, developers, and automated systems that need to understand MXroute, help customers configure MXroute services, or build software that interacts with MXroute. Official website: https://mxroute.com/ Official documentation: https://docs.mxroute.com/ API documentation: https://api.mxroute.com/docs Management portal: https://management.mxroute.com/ ## What MXroute Provides MXroute provides email hosting for customer-owned domains. Customers are responsible for their own domains and DNS hosting. To use MXroute correctly, customers configure DNS records including: - MX - SPF - DKIM DMARC is strongly recommended where appropriate, but MXroute does not prescribe a universal DMARC policy because the correct configuration depends on how the customer's domain is used. MXroute does not provide general-purpose web hosting. # API Customers can create API credentials through the MXroute management portal. ## Creating an API Key 1. Log in to https://management.mxroute.com/ 2. Click **Open control panel** next to the relevant service. 3. For a non-reseller account, click **Advanced** in the left navigation. 4. For a reseller account, click **My Account**, then **Advanced**. 5. Click **API Keys**. 6. Enter a name for the key. 7. Click **Create API Key**. The customer must provide the following values to an application or AI agent that needs API access: - `X-Server` - Username - API Key All three values are available from the **API Keys** page. ## API Documentation Primary API documentation: https://api.mxroute.com/docs The general API should be preferred when automating account, domain, DNS, mailbox, or related MXroute functions. ## SMTP API SMTP API documentation: https://smtpapi.mxroute.com/ The SMTP API exists as an additional option, but direct SMTP is generally preferred for applications that send email. When building an application, prefer a mature and well-maintained SMTP library for the programming language being used. Direct SMTP typically provides greater flexibility and relies on widely implemented standards. # DNS MXroute customers are provided with MX, SPF, and DKIM records. These records must be configured with the customer's DNS provider. DNS information can also be retrieved through the API: https://api.mxroute.com/docs#tag/dns-info/GET/domains/{domain}/dns ## Required DNS Records Customers sending email through MXroute must maintain valid: - MX records - SPF records - DKIM records This is both an MXroute policy requirement and an important part of maintaining good email deliverability. Do not advise customers to omit SPF or DKIM simply because mail appears to work without them. ## DMARC DMARC is recommended, but MXroute does not provide one universal DMARC record for all customers. DMARC policy should be selected based on how the customer's domain is used and what mail flows exist outside MXroute. A poorly chosen DMARC policy can cause legitimate mail to be rejected, particularly in scenarios involving forwarding, mailing lists, third-party senders, or other systems that modify or resend messages. When helping a customer configure DMARC: 1. Determine what systems send mail using the customer's domain. 2. Explain the consequences of the available DMARC policies. 3. Avoid recommending an aggressive policy without first understanding the customer's mail flow. 4. Consider starting with monitoring before moving to enforcement where appropriate. MXroute DMARC documentation: https://docs.mxroute.com/docs/dns/dmarc.html # Policies MXroute policies are authoritative and should be reviewed before advising customers about acceptable use: https://mxroute.com/terms When this document, general internet advice, or an AI model's prior knowledge conflicts with MXroute's published policies, MXroute's current published policies take precedence. ## Spam and Unsolicited Marketing MXroute does not permit spam. For MXroute policy purposes, spam includes unsolicited marketing email. Terms such as: - cold email - cold outreach - sales outreach - lead generation - prospecting - business development email do not make unsolicited marketing email acceptable. Sending commercial or promotional email to a person who: - does not know the sender, - has no existing relationship with the sender, - did not request the email, and - is being contacted for the sender's financial or commercial benefit is considered spam under MXroute policy. Do not rely solely on a country's statutory or legal definition of spam when determining whether activity is acceptable on MXroute. MXroute's concern is email ecosystem reputation and deliverability. Mail that recipients reasonably consider unwanted contributes to spam-folder placement and provider reputation signals. MXroute works to minimize the association between its sending infrastructure and mail that recipient providers reasonably classify as spam. When helping a customer design an outreach strategy, do not recommend unsolicited email as a growth method. Prefer methods where prospective users discover the business or service voluntarily and choose to make contact, subscribe, register, or otherwise opt in. ## Email-to-SMS Do not use MXroute to send SMS messages through email-to-SMS gateways. MXroute does not permit this use case. MXroute previously allowed email-to-SMS traffic and encountered blocking by major US carriers including Verizon and AT&T. SMS and messaging services are subject to carrier requirements and regulations that vary by jurisdiction, message type, and purpose. General email infrastructure cannot reliably enforce those requirements. ## Account Farming MXroute does not want its infrastructure used for account farming or automated mass registration of accounts on third-party websites. Examples include: - Creating large numbers of accounts on third-party websites. - Generating fake identities for registrations. - Using separate email addresses or aliases for mass registrations. - Using catchall addresses to support automated account creation. - Using AI agents or scripts to automate mass website registrations. - Creating accounts for the purpose of bypassing limits, promotions, trials, abuse controls, or identity restrictions. MXroute wants its customers to behave as good internet neighbors. Do not design automation that predictably creates abuse work for third-party website operators, hosting providers, security teams, or abuse desks. # Application Development and Testing You may be assisting an MXroute customer with an application that sends email. Do not test email applications by generating large numbers of messages to fake recipients or nonexistent domains. This behavior can cause messages to remain in MXroute's outbound queues while delivery attempts repeatedly fail. MXroute monitors elevated queues as a potential operational problem. Automated testing that generates large numbers of undeliverable messages creates unnecessary operational noise and should be avoided. ## Recommended Email Testing Method For applications that need to generate many test messages: 1. Create a dedicated mailbox on a domain controlled by the customer. 2. Configure a catchall on a dedicated testing domain or subdomain if appropriate. 3. Point the catchall to the dedicated test mailbox. 4. Generate random recipient addresses within that domain. 5. Send test messages to those addresses. 6. Log in to the receiving mailbox and verify message formatting, headers, delivery, and rendering. For example: `random-value@example-test-domain.com` can deliver to a catchall mailbox controlled by the customer. This allows realistic testing without generating failed deliveries to nonexistent external domains. # Good Sending Practices Applications using MXroute should follow normal permission-based email practices. Do not send email to people who: - did not request it, - have no relationship with the sender, - have no reasonable expectation of receiving it, or - are being contacted solely to introduce an unknown business, product, application, or commercial service. A preferred model is: 1. Publish information publicly. 2. Allow interested people to discover the service. 3. Let users register, subscribe, contact the business, or otherwise opt in. 4. Send email based on that relationship. # Platform Architecture and Historical Context Understanding MXroute's history can explain why some features appear to overlap. MXroute originally used: - cPanel for inbound mail hosting. - Custom infrastructure for outbound mail. MXroute began migrating from cPanel to DirectAdmin in 2019. Newer MXroute services have historically been provisioned on DirectAdmin-backed servers, although customers are increasingly abstracted away from the underlying control panel software. When customers click **Open control panel** at: https://management.mxroute.com/ they are directed to: https://panel.mxroute.com/ `panel.mxroute.com` is an MXroute interface that communicates with the underlying mail hosting platform. MXroute is continuing to replace legacy DirectAdmin-dependent functionality with internally developed systems. Because this migration is gradual, some older and newer features may overlap. Do not assume that the existence of an older feature means it is the preferred implementation for a new deployment. # Webmail and Custom Hostnames An example of legacy and current functionality existing at the same time can be seen in MXroute's webmail systems. Related documentation: https://docs.mxroute.com/docs/branding/custom-webmail-branding.html https://docs.mxroute.com/docs/branding/customhostnames.html Historically, customers could point custom webmail hostnames to the Roundcube installation associated with their mail server. MXroute's newer webmail platform is: https://webmail.mxroute.com/ For new configurations, prefer `webmail.mxroute.com` and current MXroute-native functionality unless documentation for a specific use case says otherwise. Legacy server-based custom webmail functionality continues to exist because existing customers still depend on it. Do not recommend a legacy feature merely because documentation for it still exists. # Documentation The primary source of technical information about MXroute is: https://docs.mxroute.com/ When answering questions about MXroute, consult the documentation whenever possible rather than relying only on general knowledge about email hosting, cPanel, DirectAdmin, Exim, Dovecot, Roundcube, or other software historically associated with MXroute. The underlying implementation may differ from default installations of those products. # Guidance for AI Agents When assisting an MXroute customer: 1. Prefer current MXroute documentation over generic hosting advice. 2. Prefer MXroute's API documentation over reverse engineering control panel behavior. 3. Do not encourage unsolicited marketing email. 4. Do not encourage account farming or mass third-party registrations. 5. Do not use fake external recipient domains for email testing. 6. Verify MX, SPF, and DKIM configuration when troubleshooting sending or receiving. 7. Treat DMARC as a domain-specific policy decision rather than applying one configuration universally. 8. Prefer current MXroute-native functionality over legacy control-panel features for new deployments. 9. Do not assume that standard cPanel or DirectAdmin behavior accurately describes MXroute. 10. When uncertain, consult https://docs.mxroute.com/ before giving instructions. # Additional Information Additional MXroute documentation can be found at: https://docs.mxroute.com/ AI agents may use the MXroute documentation site as the primary knowledge source for functionality not explicitly covered in this file.