You sent an email. A minute later, this came back:

550 5.7.1 [CS] Message blocked.

Or one of these:

550 5.7.9 This mail has been blocked because the sender is unauthenticated.
Yahoo requires all senders to authenticate with either SPF or DKIM.

550-5.7.26 ... Gmail requires all senders to authenticate with either SPF or DKIM

550 5.7.1 [CSR] Account blocked.

550 5.7.1 [ESA] Sender blocked.

Warning: message 1abcDE-000XYZ-1a delayed

These arrive at our support desk daily, one string pasted at the top of the ticket. They look interchangeable. They are not. Two mean the receiving provider refused your message because your DNS does not prove you are who you say you are. Three mean the message never left your own hosting platform. One is not a bounce at all.

Opposite problems, opposite fixes. The most common way this goes wrong is rewriting SPF records to fix a message that was stopped on the way out, before SPF was ever consulted.

Step one: bounce, warning, or block?

If your mail is on cPanel, start at Email > Track Delivery. It lists each recipient, the delivery result and the exact rejection string from the log, so you read the answer off your own server rather than a forwarded bounce. Otherwise, three things in the bounce tell you almost everything.

The first digit. A code starting with 5 (550, 554, 5.7.x) is permanent: the sending server has given up. A code starting with 4 (421, 451) is temporary and the message is still queued. A “Warning: message … delayed” notice is not a bounce at all; it is your own server saying it is still trying. The number of hours such a warning quotes, and how long the server keeps retrying before it gives up and generates a real bounce, are both configuration values on the sending server, so read nothing into the figure.

The hostname. A real bounce names the server that issued the refusal. If that host belongs to the recipient or their mail provider, your message got out and the far end refused it. If it names your own provider’s infrastructure, the message never left. This test is worth more than any lookup table, because it survives changes in wording.

The bracketed tag. Some outbound filters stamp a short tag into the refusal. [CS], [CSR] and [ESA] come from the filtering layer shared hosting mail commonly passes through on its way out. They are not standard SMTP, but if you see one you already know whose side the problem is on.

What you received Who issued it What it means Fixable in DNS?
550 5.7.1 [CS] Message blocked. Sending-side outbound filter This message’s content scored as spam on the way out No
550 5.7.1 [CSR] Account blocked. Sending-side outbound filter The sending account itself is blocked, not just this message No
550 5.7.1 [ESA] Sender blocked. Sending-side outbound filter The sending address or domain is blocked at the relay No
550 5.7.9 … sender is unauthenticated The recipient’s provider Your mail arrived without authentication they accept Yes
550-5.7.26 … SPF or DKIM The recipient’s provider Your mail arrived unauthenticated Yes
Warning: message … delayed Your own mail server Not a bounce. Still retrying. No, and nothing to fix yet

If an outbound filter blocked it

The recipient never saw the message, never evaluated your SPF, and has no opinion about you. Publishing perfect DNS changes nothing. Three things are usually behind it.

The content scored as spam. Classically, forwarding a newsletter-style message from someone else: tracking pixels, a wall of images, marketing subject lines, shortened links, now appearing to come from a mailbox that never sends anything like it. Attaching the message rather than forwarding it inline will often get it through, because the filter then scores your covering text instead of the marketing content.

It was a bulk send from a normal mailbox. A large BCC blast to a customer list looks like a spam run to an outbound filter, because mechanically it is one. A list send belongs on a dedicated sending service; check your host’s policy before retrying.

The mailbox password has been stolen. Somebody else is sending spam through the server, the filter has blocked the account, and the owner discovers it as “I can’t send email.” If your bounce says the account is blocked rather than the message, treat compromise as the leading theory until you rule it out.

The compromised mailbox, from the outside

The clearest symptom is not the block, it is the flood: hundreds of undeliverable notices for messages you never wrote, because the spam run targeted dead addresses. People read this as spoofing. Sometimes it is. But if your own outbound mail stops working at the same time, it is your account.

  1. Change the password first, and anywhere you reused it. Cleaning up before you lock the door lets the attacker walk back in.
  2. Check for persistence in your mail settings. Everyone skips this. In cPanel, open Email > Forwarders and Email > Email Filters and delete anything you did not create. Attackers leave a quiet forward, or a filter that deletes bounce notifications so the compromise stays invisible to you.
  3. Check your Sent folder for mail you did not send.
  4. If a website is involved, it is a bigger job. A compromised site sends through its own code, not through any mailbox login, which is why “I changed my email password and it is still happening” is a normal outcome. The usual entry point is an out-of-date or pirated plugin or theme, though stolen admin credentials are common too. Back up, remove what you do not recognize, update the rest, and expect that not to be enough on its own: backdoors get left in core files, the uploads directory, mu-plugins and scheduled tasks. A malware scan or a restore from a known-clean backup is the reliable fix.
  5. Do not request blocklist delisting until the source is fixed. Delisting a still-infected server gets you relisted within hours.

If the recipient refused it: the DNS side

5.7.9 and 5.7.26 come from the receiving provider and mean your mail arrived without authentication they accept. Gmail and Yahoo both tightened this in 2024: every sender needs at least SPF or DKIM, and high-volume senders (5,000 or more messages a day to that provider) need SPF and DKIM plus an aligned DMARC record. Microsoft applied a comparable bar to Outlook.com, Hotmail and Live in May 2025, rejecting non-compliant bulk mail with 550 5.7.15. If you are seeing these on ordinary business mail, you are failing the basic bar, not the bulk one.

  • SPF lists the machines allowed to send for your domain. One TXT record on the domain.
  • DKIM is a signature added by your mail server. The server holds a private key; the public half is published at a selector subdomain. On cPanel the selector is normally default, so the record is at default._domainkey.yourdomain.com. Look it up at any other selector and you get nothing, which reads as “DKIM is missing” when it is fine.
  • DMARC checks alignment: that the domain in your From address matches the domain SPF or DKIM authenticated, and tells receivers what to do when it does not. Mail can pass SPF and pass DKIM and still fail DMARC if neither is aligned with your From domain.

DKIM has two halves that drift apart: the key can be on the server with the DNS record stale or missing, or the record can be published with the key gone. Either way signing fails. A DKIM record existing in your DNS is not proof DKIM works.

The misconfigurations we actually find

SPF that authorizes the wrong infrastructure. On many shared hosts, outbound mail does not leave from the server you are hosted on. It leaves through an outbound relay, and the receiving provider evaluates the last hop. Check with your host whether yours relays before assuming your server’s IP is the sending address. Where it does, an SPF record listing that IP and nothing else can look correct and still fail at Gmail, and the host will have an include: value to publish instead.

This is why a Repair button can mislead you. cPanel’s SPF logic builds a record from what cPanel knows: the server’s own IP, plus a/mx. If mail leaves through an upstream relay cPanel has no knowledge of, the generated record looks green in the interface and still fails in the wild. Same after a migration, where a record naming your old host authorizes a machine that no longer sends your mail.

Two SPF records. A domain may have exactly one v=spf1 record. Two is a permanent error, so mail that would have passed now fails. It usually happens because a third-party sender said “add this record” when they meant “merge this into your existing record.”

An SPF record with nothing in it. v=spf1 -all on a domain that sends mail is an instruction to reject all your own email. v=spf1 ~all with no mechanisms is softer: receivers usually accept and mark. A bare v=spf1 is Neutral, treated as though no record existed. All three leave your legitimate senders unlisted; only the first actively causes rejections.

Too many lookups. SPF allows a maximum of 10 DNS lookups and every include: costs at least one. Stack a marketing platform, a workspace provider and a host include and you blow the ceiling, at which point SPF errors out for every message you send.

Records that exist but are invisible. Two causes of “I added the record and nothing changed.” First, the trailing-dot trap: entering a name as _dmarc.example.com in a zone editor that expects a bare label appends the zone origin and creates _dmarc.example.com.example.com, which nobody queries. Enter the bare label _dmarc, or the full name with a trailing dot as _dmarc.example.com. The dot is what stops the origin being appended. Second, a zone serial that was never advanced, so the nameservers consider themselves current and never load the change. Verify new records with an external lookup, never with the panel that created them.

Half-migrated mail. MX pointing at an external provider while SPF and DKIM are still set up for your host, or the reverse, means nothing agrees with anything. Decide where mail lives, then make MX, SPF and DKIM tell the same story. If you use both your host and a third-party sender, each has its own DKIM selector, and overwriting one to fix the other breaks the other.

Sender identity that does not match. Contact forms sending from the bare server hostname instead of your domain cannot be authenticated by any domain-level DNS. And with Gmail “Send mail as” on a custom domain: if you have not set up DKIM for that domain in Google Workspace, Google signs with its own domain’s key. The signature is valid, but its domain does not match your From address, so DMARC alignment fails. Generate and publish that domain’s DKIM key in the Workspace admin console.

What you can check yourself in ten minutes

No SSH needed. Query an external resolver so you see what the world sees. On macOS or Linux:

dig +short TXT example.com @1.1.1.1
dig +short TXT default._domainkey.example.com @1.1.1.1
dig +short TXT _dmarc.example.com @1.1.1.1
dig +short MX example.com @1.1.1.1

On Windows:

nslookup -type=TXT example.com 1.1.1.1
nslookup -type=TXT default._domainkey.example.com 1.1.1.1
nslookup -type=TXT _dmarc.example.com 1.1.1.1
nslookup -type=MX example.com 1.1.1.1

You are checking four things: exactly one v=spf1 record naming the infrastructure that actually sends your mail; a DKIM record returning something at default._domainkey; a _dmarc record; and MX pointing where you think it does.

Then do the fifth check, the one DNS cannot show you. Send a message to any Gmail or Outlook address you control and open Show original (Gmail) or View message source (Outlook). Confirm DKIM shows PASS, and that the signing domain (d=) matches the domain in your From address. That step tests signing and alignment together, and it is the only one here that catches a published DKIM record whose key is no longer on the server.

In cPanel, Email > Email Deliverability shows SPF and DKIM status per domain and, on newer versions (since v124), can create and manage a DMARC record too. Domains > Zone Editor is where you add TXT records by hand when DNS is hosted with your provider. Email > Spam Filters controls your own inbound filtering: leave Auto-Delete off, because it destroys false positives with no way to recover them, while Spam Box gives the same protection plus a folder you can check. The ***SPAM*** subject tag is often a server-wide setting your host controls, not a per-account one; your levers are whitelisting senders and raising your threshold score.

If a bounce cites a blocklist, the code decodes. In the Spamhaus scheme 127.0.0.2 is SBL (a direct spam source or spam-support service), 127.0.0.3 is CSS (low-reputation or confirmed-abusive senders), 127.0.0.4 to 127.0.0.7 an exploited or compromised host, 127.0.0.10 or 127.0.0.11 a residential or dynamic address that should not send mail directly. Anything in 127.255.255.x is not a listing: usually you queried through a public resolver such as 1.1.1.1 or 8.8.8.8, which Spamhaus refuses to answer (127.255.255.254). Fix first, delist second.

When you actually need to buy something

Rarely. In the overwhelming majority of cases we investigate, the fix is a DNS record, not infrastructure.

Be careful with the obvious-looking purchase. Where outbound mail leaves through a shared relay, a dedicated IP on your hosting account does not change the address receiving servers evaluate, because the relay is the last hop and its reputation gets scored. The question to ask your host is not “can I have a dedicated IP” but “what is the final hop my mail leaves from, and is that address shared?”

The one case where a purchase is genuinely the answer is bulk or marketing mail: use a dedicated sending service, because you need per-campaign analytics, bounce and complaint handling, and suppression lists, none of which is a web host’s job. One case that looks like it needs infrastructure and does not: if another account on your server is compromised, shared sending reputation degrades until the source is cleaned, so if delivery drops with nothing changed on your side, ask your host whether that is what is happening.

Before buying anything, publish DMARC in monitoring mode (p=none) and read the reports for a couple of weeks. You will find out exactly who is sending as your domain, including systems you forgot about. Tighten to quarantine or reject only once SPF and DKIM pass and align for every legitimate source, because tightening early rejects your own mail.

What to send your host

If you open a ticket, send the entire bounce message, headers included, not a screenshot of the first line. The bracketed tag, the rejecting hostname and the timestamp are what let a technician find your specific message in the logs. Add one recipient address that failed and roughly when you sent it.