Email that actually arrives

Email fails in two ways. Loudly, which is annoying and easy. And quietly, where your provider accepts the message, reports it delivered, and nobody receives anything. The second kind is where the damage is.

Suppression lists are the first thing to check. Once an address is on one, sends to it are accepted by the API and discarded. The nasty case is your own addresses: one bounce during an outage can permanently silence every alert you rely on, while everything continues reporting success.

Configuration decays. Sending domains fall out of verification when DNS is tidied, a registrar migration runs, or a provider changes requirements. Nothing announces it. Receiving is separate from sending, so an address can be set up and never able to receive anything, with no error anywhere, because no message ever arrives to be errored on.

SPF has two rules that bite as you add services. Exactly one record per domain, and ten DNS lookups total. Each provider tells you to add a record, and adding a record is what you do, and now you have two and neither works.

New domains have no reputation. The mail people put on a fresh domain first is the mail they can least afford to have filtered. Borrowing an established sender is less elegant and works immediately.

All of it argues for the same habit: monitor the configuration on a schedule, because anything that fails by doing nothing needs someone to go looking.

The 8 notes in this area

Do not send important mail from a domain nobody has heard of

A brand new sending domain has no reputation, and the mail that matters most is exactly the mail you cannot afford to have filtered.

Moving a domain between Microsoft 365 tenants: the outage is not where you expect

Removing a custom domain from one tenant and adding it to another tears down the mail routing host behind the MX record. Until it is rebuilt nothing delivers, and the dangerous moment is when it comes back.

"Your domain cannot be added to Microsoft 365 at this time"

Error 715 when adding a custom domain, and the stale verification record that usually causes it.

How to tell whether a mail domain is really live, without sending anything

Sending test emails to check mail flow gives you one data point and a bounce. An SMTP recipient probe asks the same question repeatedly, costs nothing, and reveals when the answer is inconsistent.

Moving a domain between Microsoft 365 tenants without losing mail

The domain move is the hard part of a tenant migration, not the mailboxes. The teardown window, the two rejection codes, and how to tell when it is genuinely ready.

When Set-Mailbox has no PrimarySmtpAddress in Exchange Online

The parameter every guide tells you to use is sometimes missing entirely, failing as "parameter cannot be found". It is there for some connections and not others, and the difference is your roles.

SPF: one record, ten lookups, and no second chances

Two SPF records is a hard failure. So is exceeding the lookup limit. Both happen naturally as you add services.

A mail rule that never fires because something above it stops processing

Adding a transport rule and finding it does nothing is usually not a problem with the rule. It is a rule above it with stop processing enabled.

Other guides

• Running n8n in production
• Running an AI support desk
• Automating orders, payments and returns
• Knowing where your traffic actually comes from
• Being cited by AI search
• Self-hosting it reliably