Start by separating incoming and outgoing failures
When business email stops working, the first question is whether messages fail on the way in, on the way out, or only for certain recipients. Incoming delivery depends heavily on MX routing and the receiving mail service. Outgoing delivery involves the sending platform, authentication, recipient policies and sometimes the user's client configuration. DNS can affect both, but a missing message does not prove DNS is the cause. Collect a precise example with the sender, recipient, approximate time and any bounce error, protecting private customer content. A clear symptom prevents random DNS changes that may make a small outage much worse.
Find the authoritative DNS zone before editing
A business may register its domain with one company, host its website elsewhere and receive email through a third provider. The DNS dashboard that looks familiar is not necessarily authoritative. Public resolvers follow the domain's delegated nameservers, so editing a disconnected copy of the zone may have no effect. Identify the current authoritative nameservers and compare their published answers with the intended provider records. Preserve the existing zone and change history before any approved modification. Do not switch nameservers merely to fix one mail record; such a change can affect website routing, verification records and unrelated services at the same time.
Understand what MX records actually control
Mail exchanger records identify where other mail systems should attempt to deliver incoming mail for a domain. They do not by themselves create user mailboxes or authorise outgoing senders. An MX record typically names a mail host and has a preference number; lower numbers are preferred when multiple valid destinations exist. Copying a host name from an unrelated account can direct messages to the wrong infrastructure. Compare the public MX answer with the actual mail provider's current setup instructions for the specific domain. Also verify that the named destination resolves appropriately and the receiving service recognises the domain and intended mailboxes.
Avoid mixing unrelated MX providers
A common migration mistake is leaving old MX records beside new provider records without a deliberate routing design. Some senders may try the preferred destination first and others may use a fallback when it is unavailable. If the fallback points to a retired provider that no longer has current mailboxes, messages can bounce, queue unexpectedly or be delivered to the wrong place. Multiple MX records are not automatically an error; the issue is whether the complete set implements the intended receiving architecture. Ask the mail provider which destinations and priorities are valid for the account and remove obsolete entries only under an approved cutover plan.
Check mail hostnames and address records
An MX destination must lead to a usable mail server name. A typo in the hostname, missing address record or mistaken delegated subdomain can break the route even when the MX line looks plausible. Cloudflare documents cases where the MX points to a delegated subdomain whose address records are managed by another DNS provider. Check the entire resolution chain, not only the first answer. A website's A record and the mail server's A or AAAA record may be different and should not be changed together without evidence. The relevant test is whether the named receiving service can actually accept messages for the domain.
Do not proxy normal mail protocols through an HTTP proxy
Cloudflare's standard orange-cloud HTTP proxy does not carry ordinary SMTP, IMAP or POP3 traffic. If a mail hostname resolves to a proxy address instead of the provider's real mail endpoint, mail clients or sending systems may fail to connect. An MX record is not itself orange-cloud proxied, but the address record for the hostname it targets can be configured incorrectly. Confirm whether a mail-related host must be DNS-only under the provider's architecture. Do not turn off proxying for unrelated website records merely because email fails. Cloudflare's own email troubleshooting documentation explains this distinction and its exceptions for specialised services.
Understand cPanel local and remote mail routing
A hosting control panel can have a mail-routing setting independent of public MX records. cPanel distinguishes Local Mail Exchanger, Backup Mail Exchanger and Remote Mail Exchanger behaviour. If the website is hosted on one server but mailboxes live with an external provider, an incorrect local routing setting may cause applications on the web server to attempt local delivery instead of sending to the external service. cPanel notes that its automatic detection uses the local zone and does not perform a live public DNS lookup. Verify both public DNS and the actual server routing configuration with the authorised host; do not assume one proves the other.
Distinguish SPF from receiving mail routes
SPF is an outgoing sender-authorisation policy, not the address of the incoming mailbox server. A domain can receive mail through one provider while several approved services send mail on its behalf. Copying an SPF record that lists only the mailbox host may exclude invoice notifications or support applications. Conversely, adding an incoming MX destination to SPF without checking whether it sends outbound mail can authorise unnecessary infrastructure. Inventory each genuine sending source and follow the provider's official SPF instructions. A valid-looking TXT value is not enough: the effective SPF policy must remain syntactically correct, within lookup limits and consistent with actual sending behaviour.
Watch for duplicate SPF TXT policies
During a provider change, an administrator may add a second v=spf1 TXT record instead of updating the existing policy. RFC 7208 does not permit multiple SPF records for the same domain name, and receivers can return permerror. A domain may legitimately have several TXT records for unrelated purposes, so the solution is not to delete every TXT entry. Identify the SPF-specific values and reconcile all authorised sending sources into a single coherent record. Test the effective public answer after any approved change. Do not combine records blindly; nested include statements can exceed the specification's DNS lookup budget even when the final text appears short.
Check DKIM selectors and record targets
DKIM verifies a cryptographic signature using a public key published under the signing domain and selector. A missing selector record, incorrect TXT value or broken CNAME target can cause messages to fail DKIM checks even when the sender is legitimate. Some providers require TXT keys, while others instruct customers to publish CNAME records pointing to provider-managed keys. Use the method documented for the actual account. Cloudflare warns that CNAME flattening can interfere with certain provider-required DKIM or autodiscover CNAME answers. Review the public DNS response and a real signed message header rather than assuming the control panel's saved value is sufficient.
Do not confuse DMARC policy with mailbox delivery
DMARC publishes a requested handling policy for messages that fail aligned SPF or DKIM checks. It is not an MX record and does not create mailboxes. A business can have correct incoming MX routing while its outgoing messages fail DMARC because a third-party sender uses an unrelated signing domain. Equally, publishing an aggressive reject policy before testing approved senders may disrupt legitimate notifications. Inspect the visible From domain, envelope domain and DKIM signing domain, then review actual authentication results. Report destinations and policy changes need ownership and a staged plan. Do not use DMARC as a substitute for investigating a missing incoming mailbox.
Beware of wrong record names and DNS panel formatting
DNS interfaces differ in how they interpret the host-name field. Some expect only a relative label such as _dmarc or a DKIM selector, while others accept a fully qualified name. Entering the complete domain into a field that automatically appends the zone can create an unintended doubled name. Extra quotation marks, missing separators or copied whitespace can also change a TXT record's effective value. Before saving, inspect the provider's instructions and the preview of the full resulting DNS name. After an approved edit, query the public record at the intended exact name. A screenshot of the form before saving is not proof of publication.
Account for DNS caching and TTL
DNS answers are cached by resolvers according to time-to-live values and other caching behaviour. After a change, one resolver may show the new MX or TXT answer while another still shows an earlier value. This is not always evidence that the provider ignored the edit. Record the change time, previous values, expected TTL and which authoritative nameservers answer the new record. Avoid repeated unplanned edits while waiting for caches to expire, because each new change complicates diagnosis. A safe migration schedule includes overlap, monitoring and an agreed rollback window. DNS propagation is not a promise that every mail system will switch at the same instant.
Separate website changes from email changes
Moving a website does not necessarily require moving business email. A records or CNAMEs used for the website can change while the MX, mail-related address records and authentication TXT records remain with the existing provider. Conversely, changing authoritative nameservers for a website migration can affect email if the new zone does not reproduce required records. Prepare an inventory that distinguishes web routing, incoming mail, outgoing authentication and third-party verification entries. Compare the old and proposed zone before a nameserver cutover. Do not treat a website hosting quotation as authorisation to replace mailbox services or change live DNS. These are separate owner decisions.
A hypothetical outage after a website move
Imagine a small supplier whose new website loads successfully after a hosting change, but customers report that quotations sent by email bounce. The team discovers that the new DNS zone contains the website's A record but not the old mail provider's MX and authentication records. The right investigation starts with the authoritative zone and a saved record inventory, not a guess that the mailbox passwords are wrong. A controlled restoration plan would require approval, provider confirmation and inbound and outbound testing. This scenario is hypothetical; it illustrates why a visually successful website migration cannot establish that all business communication still works.
Test both delivery directions with real evidence
After a proposed DNS correction is approved and implemented by the authorised operator, test receiving from an external mailbox and sending to more than one relevant destination. Check the message headers, authentication results and any bounce details. A successful self-to-self message inside the same provider may bypass public routing and therefore prove very little about internet delivery. Test the actual third-party sender paths used for invoices, website enquiries and notifications where those are in scope. Keep test messages free of customer secrets and record the timestamp and result. A green DNS checker is useful evidence but cannot replace a complete mail-flow test.
Know when the problem is not DNS
Correct public MX and authentication records do not guarantee that an individual mailbox exists, has storage available or is allowed to send. A provider may reject a message because the address is unknown, a quota is exceeded, an account is suspended or the receiving server applies a security policy. A local email client may fail authentication even though the domain's DNS is healthy. Read the exact error code and consult the responsible mail administrator before editing records. Distinguish a DNS lookup failure from a transport rejection and from a client login problem. Each has a different owner and corrective path.
Keep a change log and rollback plan
Before any live DNS modification, record the exact owner name, type, previous value, proposed value, affected service and authorised approver. Preserve a complete zone snapshot and identify how the original state can be restored. Schedule changes when a responsible person can monitor inbound and outbound mail, and avoid overlapping unrelated migrations. If a vendor recommends replacing every record, ask for a written explanation of which entries are obsolete and which must remain. A change log helps distinguish a new incident from a pre-existing failure. This educational checklist does not grant permission to access or modify OnHypp or customer production systems.
A concise troubleshooting decision sequence
Begin with the failed direction, an example message and its error. Identify the authoritative DNS service, then compare public MX, mail-host addresses, SPF, DKIM and DMARC with the actual providers' instructions. Check whether web-host local routing, proxy status or a delegated subdomain affects the path. Review recent changes and wait appropriately for DNS caching before drawing conclusions. If public records are correct, investigate mailbox existence, account status, transport rules and client authentication with the provider. Only an authorised operator should make a scoped change, preserve rollback evidence and verify both directions afterward. Avoid broad fixes based on a single screenshot.