Changed your DNS? Check your email

The same zone

SPF, MX, and the servers that send form mail often live next to the A record you came to change. A “website-only” edit that retargets nameservers, or that copies an incomplete zone to a new DNS host, takes mail with it. The homepage looks fine. The inbox is quiet.

We treat a form send as part of every DNS change, not as a courtesy. If you want the printable sequence, use the DNS, SSL, and email check.

HTTPS is not only a certificate

We have restored embedded registration listings that disappeared after a site moved to encrypted connections. The certificate was fine. An integration plugin still requested an insecure script address. Mixed content and vanished widgets after TLS are usually hard-coded http:// URLs, not a mysterious “SSL is broken” event.

Certificate work has its own failure modes: an issuer problem that needs a rekey, an admin-only warning because the application pool cannot read the new cert, a nameserver reversion at the registrar that no CMS setting will override. We have confirmed a rekey and still asked for an independent check rather than declaring victory from the installer log.

TTLs and Friday afternoons

Lower time-to-live the day before you need to move, not the hour you need to move. A 24-hour TTL you forgot to touch is why “we flipped DNS” still shows the old site for a branch office. Do not stack a certificate renewal, a nameserver move, and a mail-host migration on the same Friday. Each one is a testable change. Together they are an incident with three owners.

If nameservers keep reverting, stop editing the CMS. The registrar is the incident. We have watched obsolete nameservers come back after someone “fixed” the website. The storefront was down. Admin still loaded. That is the split that wastes a day if you start in the theme customizer.

When the form stored the row

If submissions exist and mail does not, the form works. The mail account, SMTP, or DNS authentication does not. We have fixed a live form whose mail-service account had been deleted, a staging form that needed authentication and a recipient allowlist, a notification template that printed the wrong variables, and a multilingual form that failed because two challenge plugins overlapped — with page cache still serving the broken markup after the “fix.”

A green thank-you page is not proof of delivery. See the form and email delivery checklist and the older guide to WordPress emails that never arrive.

A form incident that looks like a DNS incident

Submissions are in the plugin inbox. Confirmations are not in anyone’s mailbox. The last change was “just the website A record.” The SMTP user still exists, but SPF no longer includes the box that sends. Or the SMTP user was deleted when someone cleaned up “old mail accounts” the same week. Or a staging allowlist still blocks the owner’s Gmail. Or the notification template prints empty variables. Or two captcha plugins overlap on the French version only, and cache is still serving last Thursday’s markup.

We have handled each of those as separate jobs. They feel like one job to the person who is not receiving quotes. The split — stored versus sent — is how you stop rebuilding a form that already works.

If the message is leaving the server and dying at Gmail, you need headers, not another form plugin. If the message is not leaving the server, you need the mail account, the password, and the hostname. If only one language fails, you need to stop blaming DNS for a captcha stack.

Cloudflare is not a free pass

Proxy status, SSL mode, and cached redirects will make a correct certificate look broken and a broken certificate look fine, depending on which box you asked. If orange-cloud is on, the browser is talking to Cloudflare, not your origin. An origin cert and a Universal SSL setting are different jobs. Mixed content after “we turned on HTTPS in Cloudflare” is still often a hard-coded http script in a plugin.

We help with DNS, proxy status, SSL mode, cache rules, WAF basics, and redirect issues. We will not pretend a five-minute orange-cloud toggle replaces a zone export. Export the zone. Change one class of records. Test a form. Then decide whether to proxy.

The same caution applies to registrars that offer “email forwarding” as a substitute for MX records you actually understand. Forwarding that depends on a nameserver you are about to leave is how a partner mailbox dies in the same hour the website comes up. Write down every record that is not a website record before you touch nameservers.

If you already changed something and mail stopped, do not change it again until you have a sent-message header or a clear “it never left the server” result. Two consecutive DNS edits without a test is how the incident grows a second owner.

SPF, DKIM, and the hostname that actually sends

Authentication records have to name the servers that send, not the servers you used last year. After a host move, after a Microsoft 365 cutover, after someone “helped” by adding a second SPF record — look at the headers of a real message. Two SPF records is a failure. A DKIM selector that points at a host you decommissioned is a failure. DMARC that says reject while you still send from a forgotten marketing tool is how you discover the tool on a Monday.

Website forms that use the host’s mail() function without SMTP inherit whatever reputation that box has. If the box is new, the first fifty messages may land in spam even when the records are perfect. That is not a form plugin bug. It is why we look at the received headers instead of the success banner.

When you want this diagnosed rather than described, use contact form and email delivery fixes. Bring a sample of a message that arrived and a timestamp of one that did not.