Read the bounce message first: what each part of an email failure tells you

A bounce is a diagnosis in disguise

When mail cannot be delivered, a server sends the sender a message explaining why. Most people read only the friendly first line. The useful part is lower down: a three-part status code and a line of text from the server that refused the message. Together they say whether the fault is the address, the destination domain or a policy, and that decides which fix is even worth trying. Collect two or three bounces before you change anything.

How to read the code

RFC 3463 defines the format: class, subject and detail, such as 5.1.1. The first number says what happened. Class 2 is success. Class 4 is a persistent transient failure, meaning the sender tried and may try again later. Class 5 is a permanent failure, where resending the same message is unlikely to help. The second number says where the trouble lies. Subject 1 is addressing: 5.1.1 means the destination mailbox address is bad, and 5.1.2 means the destination system address is bad, so the part after the @ cannot be used for mail. Subject 7 is security or policy.

• 5.1.1: the mailbox is not known to the system that answered.
• 5.1.2: the domain cannot receive mail, for example no usable mail server.
• 5.7.x: a policy refused the message.

Common policy codes in the real world

Providers add their own wording. Google says unauthenticated mail may be marked as spam or rejected with a 5.7.26 error. Microsoft 365 returns 5.7.520 with an access-denied message when an automatic forward to an outside address is blocked by policy, and its DMARC documentation shows a sender's reject policy producing a 550 5.7.1 rejection when the receiving organisation honours it. Each tells you to look at authentication or forwarding policy, not at the mailbox or the MX record.

• 5.7.26 from Google: look at authentication of the sending domain.
• 5.7.520 from Microsoft 365: external forwarding is blocked by policy.
• 550 5.7.1 at Microsoft 365: a sender's DMARC policy was applied.

Which server produced the bounce

A bounce from the receiving server says what it saw. A bounce from your own server, or from a mail system you thought you had left, says something different: the message never reached the system you meant. Look at the name of the reporting server in the bounce. If it belongs to the old provider or the website's host, mail is going to the wrong place and the MX records or the host's mail routing setting are the first things to check.

What to do next, and where the paid outcomes fit

Match the code to the right check. A domain or no-mail-server fault leads to the MX records and, on cPanel-style hosting, the routing setting. A mailbox that does not exist leads to the mailbox at the provider. A policy code leads to authentication or forwarding. Do not change the DNS until you know which it is.

The linked jobs are published test prices that have not been tested with buyers and are payable after sign-off: the mail routing repair at £175, the forwarding repair at £165 and the authentication job at £195. Each needs the bounce text and the date to confirm fit. None promises that mail will never be junked.