SMTP error 5.7.27 Sender address has null MX

What SMTP error 5.7.27 means

Your own sending domain publishes a null MX, the record that formally states the domain accepts no email. The receiver checked whether it would be able to return a bounce to the address in your MAIL FROM, found it could not, and refused the message with 550 5.7.27 rather than accept something it can never answer. This one is self-inflicted and is fixed in your DNS, not theirs.

Security or policy status
Sent by The receiving mail server, having checked whether it could ever reply to your sender address
Rare

What SMTP error 5.7.27 Sender address has null MX actually means

RFC 7505 gives a domain a way to state that it receives no mail, which is genuinely useful for a web-only or parked name because senders stop retrying for days before giving up. The side effect is that anything claiming to come from that domain cannot be replied to and cannot be bounced, so a careful receiver declines it at the door. The usual scenario in a UK business is an application sending notifications from a no-reply address on a domain that was only ever set up to host a website, or a campaign domain given DNS for the web and nothing for mail. When it is the recipient domain in that position rather than yours, the equivalent report is 5.1.10. Permanent form only, so there is no retry to wait out.

This status code is returned when the associated sender address has a null MX, and the SMTP receiver is configured to reject mail from such sender (e.g., because it could not return a DSN).
— RFC 7505

How 5.7.27 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 550 5.7.27 as the pairing for this status.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.7.27 on a business phone system

A no-reply address on a web-only domainOrder confirmations, form submissions and system alerts sent from noreply at a domain that hosts the marketing site. It looks tidy in the code and it is unanswerable in every sense the standard cares about.
A domain deliberately closed off against spoofingPublishing a null MX on unused domains is sound advice, and it becomes a problem the moment somebody starts sending from one. The security measure and the new use case were decided by different people months apart.
A campaign or brand domain never given mail recordsMarketing registers a domain for a launch, DNS is set up for the website, and later a mail platform is pointed at the same name because it matches the branding. Nothing was ever configured to receive on it.
A null MX applied by a DNS template during a changeSome hosting control panels write a null MX when a domain is created without an email plan. If mail from a working domain suddenly starts failing this way, ask what changed at the DNS host.
An application putting the wrong domain in MAIL FROMThe envelope sender and the visible From are separate values and software often gets the first from a configuration file nobody has read in years. The From line can look correct while the envelope names a bare domain that accepts nothing.

How to fix SMTP error 5.7.27

Decide whether the domain is supposed to send mailYou cannot have it both ways. If mail should leave from this name, remove the null MX and publish real MX records; if it should not, the fix is to stop sending from it rather than to change DNS.
Move the envelope sender to a domain that receivesThe address in MAIL FROM is what is being judged here, and it does not have to match the From line. Point it at a subdomain or a domain with working mail records and the rejection stops.
Give no-reply somewhere to landEven if nobody reads it, the address should accept mail so bounces and out-of-office replies have a destination. A shared mailbox with a retention rule costs nothing and makes delivery problems visible.
Find out what the application actually sendsRead the envelope sender from the headers of a real message rather than from the application settings screen. The two disagree more often than anyone expects, particularly where a relay rewrites on the way out.
Keep null MX where it belongsOn domains that genuinely never send or receive, leave the record in place. It is a good anti-spoofing measure, and the discipline required is simply that nothing is ever configured to send from those names.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.27

Should we publish a null MX at all?

On domains that never send or receive email, yes. It stops other people's servers queueing mail for you for days and it removes an easy avenue for spoofing. The rule is simply that a domain with a null MX must not be used as a sending identity.

Can we keep the record and still send from the domain?

Not in any way that works reliably. Some receivers will accept it, and any receiver that follows the specification properly will refuse you exactly as this code describes. Treat the two as mutually exclusive.

How do we tell whether we have one?

Query the MX records for the domain and look for a single entry with preference 0 whose target is a lone full stop. If that is what comes back, the domain is publicly declaring it accepts no mail.

Related SMTP status codes

Source. SMTP error 5.7.27 Sender address has null MX is defined in RFC 7505 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes