MX records tell other mail servers where to deliver inbound email for a domain. They do not configure WordPress to authenticate to SMTP, authorise a From address or guarantee that a form generated a notification.
Leave correct inbound routing intact and trace the outbound message separately.
Draw the two routes
Inbound company mail follows the sender’s server to the domain’s MX provider. A WordPress notification follows the website through PHP or an SMTP/API provider, then to the recipient domain’s gateway.
Record the website’s active mail transport, From domain, intended recipient and a synthetic submission time. Do not assume the mailbox provider sends website mail merely because it receives staff mail.
Check whether the form stored its entry before investigating DNS.
Confirm WordPress notification generation
Review enabled notifications, conditional routing and recipient tokens for the active form. A missing mail-log event means the problem exists before any recipient MX lookup.
Use a fixed authorised address in From and the visitor in Reply-To. Validate recipient fields and check that the page uses the form ID being edited.
A generic SMTP test cannot prove the real notification ran.
Identify the outbound transport
WordPress may use local PHP mail, a hosting relay, authenticated SMTP or an API mailer. Find the active configuration and search its logs by test timestamp.
If local PHP accepted the message, inspect the hosting queue and delivery response. If SMTP is configured, verify hostname, port, TLS and credential ownership.
Do not change recipient MX records to repair a connection from WordPress to its own sender.
Check local mail routing
cPanel or Plesk may treat the website domain as a local mail domain even though MX points to Microsoft 365, Google Workspace or another external service. Messages to the same domain can then be delivered to a local nonexistent mailbox without consulting public MX.
Compare local/remote exchanger settings with the authoritative mail design. Change them only after confirming that no legitimate local mailbox depends on the server.
Keep a rollback because routing mistakes can affect inbound mail too.
Authenticate the sender
SPF authorises the envelope sender’s infrastructure, DKIM signs the message and DMARC checks alignment with visible From. None is created automatically by a correct MX record.
Publish the current sender’s records at authoritative DNS. Keep one SPF policy and the exact DKIM selector. Complete provider verification before testing.
Inspect authentication results in a delivered copy rather than relying on dashboard status alone.
Follow provider and recipient status
Search the outbound provider for acceptance, deferral, bounce or suppression. Provider acceptance means the recipient gateway, selected through its MX, took responsibility or returned a later result.
Ask the authorised mail administrator to search quarantine, transport rules, aliases and shared-mailbox restrictions by message ID.
The user’s spam folder is only one possible destination.
Avoid unrelated DNS changes
Do not alter MX priorities, add the web server as an MX target or point mail to the website IP unless the actual mailbox architecture requires it. These changes can interrupt company email without fixing the form.
Likewise, the website A record, SSL certificate and Cloudflare proxy status are separate from outbound sender authentication, except where WordPress connects to a custom SMTP hostname.
Change the first proven failed handoff only.
Verify both business functions
After repair, submit one labelled form and confirm entry, notification, sender acceptance and final mailbox arrival. Then send an inbound test to the company mailbox to prove MX routing remains intact.
Inspect Reply-To and SPF/DKIM/DMARC. Review stored form entries from the failure window.
Request urgent help when hosting local routing conflicts with external MX or the real outbound provider is unknown. Share public DNS, timestamps and redacted queue results—never mailbox credentials or enquiry contents.