SMTP "553 5.1.8 Domain of sender address does not exist"

What’s actually happening

Outbound mail is rejected at the MAIL FROM stage with 553 5.1.8 (some servers phrase it 5.5.2 or "Sender address rejected: Domain not found"). It fails for every recipient, not just one, because the problem is your domain, not theirs. The reject usually quotes the exact sender domain — and squinting at it you spot a typo, or it's a real domain whose DNS just broke.

Common causes

• The envelope-sender (MAIL FROM / Return-Path) domain is misspelled in the app, script, or mail-merge config — e.g. yourdoman.com instead of yourdomain.com.
• The sending domain genuinely has no DNS records: no A and no MX, so a recipient doing a sender-domain check gets NXDOMAIN.
• The domain expired or was just registered and hasn't propagated, so the authoritative servers return nothing yet.
• An app sends from a made-up or internal-only domain (localhost.localdomain, [email protected]) that doesn't resolve on the public internet.
• A broken or removed MX record where the receiver requires the sender domain to have one, leaving no mail-routable target.

How to fix it

1. Verify the domain actually resolvesFrom any shell run `dig MX yourdomain.com +short` and `dig A yourdomain.com +short`. Empty output for both is the smoking gun. Also `whois yourdomain.com` to confirm it isn't expired or recently registered and still propagating.
2. Fix the typo at the sourceCheck the From / Return-Path in whatever sends the mail — sendmail/Postfix config, the app's SMTP settings, the SaaS sender profile, or the mail-merge column. A single transposed letter in the envelope sender is the most common cause. Correct it and resend.
3. Publish the missing DNS recordsIf the domain is yours and simply lacks records, add a valid A record and an MX record at your DNS provider pointing at your real mail host. Allow for TTL/propagation (minutes to a couple of hours) before retesting with the dig commands above.
4. Stop sending from non-resolvable domainsIf an app defaults to a host-internal sender like [email protected], override it with a real, registered domain you control. Set a proper envelope-from / Return-Path so the receiver's sender-verify check finds live DNS.
5. Confirm with a test sendAfter DNS resolves or the typo is fixed, send to an external mailbox (Gmail works well) and check the headers for the corrected Return-Path and an SPF result other than permerror/none.