Email stopped working

What you are seeing

When mail fails, the receiving server usually says why in the bounce message. The three-part code (such as 5.7.26) matters more than the wording around it. Codes starting with 5 are permanent failures; codes starting with 4 are temporary, and the sender keeps retrying, usually for a few days.

Bounce text (examples)	What it means
550 5.1.1 The email account that you tried to reach does not exist	Wrong address, or the mailbox was deleted.
552 5.2.2 The email account that you tried to reach is over quota	The recipient’s mailbox is full.
550 5.7.26 ... unauthenticated or DMARC policy	Gmail rejected it because SPF and DKIM failed or did not align with the From domain.
550 5.7.25 ... PTR record	The sending server’s IP has no matching reverse DNS name.
550 5.7.515 ... doesn't meet the required authentication level	Outlook.com consumer mailboxes require SPF, DKIM and DMARC from high-volume senders.
554 5.7.1 ... blocked using followed by a list name	The sending IP is on a blocklist.
421 4.7.0 or 4.7.28 ... rate or unusual	Temporary throttling for volume or reputation.
554 5.7.1 Relay access denied	The server will not send for you: your mail app is not logging in to send.
535 5.7.8 Username and Password not accepted or 535 Authentication failed	Your mail app or website cannot log in to send.
No bounce at all: mail just stopped arriving the day you moved the website or changed nameservers	The new DNS zone is missing your MX and mail records. See email stopped after moving the website.

Since February 2024, Gmail and Yahoo require SPF or DKIM on all mail. Senders of 5,000 or more messages a day to Gmail also need SPF, DKIM and a DMARC record, alignment with the From domain, one-click unsubscribe on marketing mail, and a reported spam rate under 0.3%. Many bounces that "started suddenly" trace back to these rules being enforced.

Confirm it in two minutes

1. Check reverse DNS on the sending server. This matters if your own server or VPS sends mail.

dig +short -x SENDING_IP
dig +short A HOSTNAME_FROM_ABOVE

Run these on your own computer’s terminal. SENDING_IP is the IP in the first Received: from line of a sent message’s headers, or your server’s IP from the hosting panel. HOSTNAME_FROM_ABOVE is the name the first command prints. Good: the first returns a hostname and the second returns the same IP. Bad: no answer, or a generic name that does not resolve back.

2. Check that IP against a major blocklist.

dig +short REVERSED_IP.zen.spamhaus.org

Run it on your own computer. REVERSED_IP is SENDING_IP with its four parts in reverse order: 192.0.2.10 becomes 10.2.0.192. Good: no output. Listed: an answer starting 127.0.0. Spamhaus refuses lookups through large public DNS resolvers and returns an error code in the 127.255.255.x range instead, which does not mean you are listed. Use your provider’s blocklist lookup page if you get that.

3. Test that your mail server accepts secure logins.

openssl s_client -connect MAIL_HOST:587 -starttls smtp -crlf -quiet

Run it on your own computer. MAIL_HOST is the outgoing (SMTP) server in your mail app’s settings. 587 is the standard port for sending from apps; -starttls smtp upgrades the connection to TLS the way mail apps do. Good: certificate details and then a 250 line. Type QUIT to leave. Bad: a timeout (a firewall or your network blocks the port) or a certificate for a different name, which makes mail apps refuse to connect.

4. Test whether WordPress hands mail off at all.

wp eval 'var_dump( wp_mail( "YOUR_OUTSIDE_ADDRESS", "Test from WordPress", "Test body" ) );'

Run it in an SSH terminal inside the site’s folder (the one with wp-config.php). YOUR_OUTSIDE_ADDRESS is a mailbox at a different domain, such as a personal Gmail. bool(true) only means PHP passed the message on, not that it arrived. bool(false) means it never left the site.

Most likely causes, in order

1. A DNS change dropped your mail records. Tell: the problem began the day nameservers moved to a new host or CDN, and MX, SPF or DKIM records were not copied. Fix: re-create every mail record from your email provider’s setup page. The SPF, DKIM and DMARC field guide covers each record.
2. Authentication failing under the big providers' rules. Tell: bounces with 5.7.26 or 5.7.515, and dkim=none or spf=fail in received headers. Fix: turn on DKIM signing, add every sending service to a single SPF record, and publish DMARC.
3. The website delivers mail to itself. Tell: website form mail to an address at your own domain never arrives, but outside senders reach you fine. The web server still thinks it handles mail for your domain, so it drops the message into an unused local mailbox. Fix: set the domain’s mail routing in your hosting panel to remote (often called "Remote Mail Exchanger"), or send through your real mail provider over SMTP.
4. Website mail sent with no authentication. Tell: wp_mail returns true, but messages land in spam or vanish, especially when the form uses the visitor’s address as the From. Fix: send through an authenticated SMTP or API connection, with a From address on your own domain and the visitor in Reply-To.
5. A mailbox or account quota is full. Tell: 552 5.2.2 bounces for your address, or webmail warning about storage. Fix: empty large folders or raise the quota.
6. Password or sign-in method changed. Tell: 535 errors in a mail app, printer or scanner after a password reset, or after a provider stopped allowing plain username and password logins. Fix: update the stored password, or switch the device to an app password or modern sign-in.
7. A compromised mailbox or script is sending spam. Tell: a sudden blocklist listing, a large outgoing queue, or a host notice that outgoing mail is suspended. Fix: change the password, check mail forwarding rules, remove the script, then request delisting.

What it usually is not

• "Propagation takes 48 hours." Most DNS records use TTLs of an hour or less. If records are still wrong after a few hours, they are wrong, not slow.
• A second SPF record. Adding one makes things worse: two v=spf1 records cause a permanent SPF error. Merge them into one, and stay within the limit of 10 DNS lookups.
• A blocklist, when the bounce says DMARC. Read the code. 5.7.26 is authentication, not reputation.
• The recipient’s filter. If several providers reject you, the problem is on the sending side.

What to send your host

• The complete bounce message, including the remote server’s response line.
• The full headers of one affected message, and its Message-ID.
• Sender and recipient addresses, and the time sent, in UTC.
• How it was sent: a mail app, webmail, or the website.
• Any DNS or hosting change in the past week, and its date.
• The output of checks 1 to 3.