Signal & Syntax · Guide
MX Records, SMTP Codes and Bounces Explained
Every email delivery ends in a three-digit reply from the receiving server. The reply decides whether the address stays on your list.
5 minUpdated ScoreMachine team
How an Email Finds a Mailbox
Four steps take a message from the sending server to the mailbox:
- 01DNS lookup. The sender asks DNS for the recipient domain's MX (mail exchanger) records.
- 02Connection. The sender opens an SMTP connection to the MX host with the lowest priority number.
- 03RCPT TO. The sender names the recipient mailbox with the RCPT TO command.
- 04Reply code. The receiving server answers with a three-digit status code.
Example
acmecorp.com MX 1 aspmx.l.google.com EHLO mail.sender.example MAIL FROM:<news@sender.example> RCPT TO:<sofia.marin@acmecorp.com> 250 2.1.5 OK
Mail providers run more than one MX host for redundancy. The priority number sets the order the sender tries the hosts.
SMTP (Simple Mail Transfer Protocol) is defined in RFC 5321. With no MX record, senders fall back to the domain's A or AAAA record. A domain with neither record accepts no mail.
A typo'd or parked domain fails at the first step, before any mailbox test. The MX target also names the mail provider, such as Google Workspace or Microsoft 365. The reply to RCPT TO carries the verdict a verification check reads.
Reading SMTP Status Codes
The first digit gives the class. 2xx means success, 4xx a temporary failure and 5xx a permanent failure. RFC 3463 adds enhanced codes, such as 5.1.1, for more detail.
Servers word the text after the code freely. Read the code, not the text.
Greylisting servers answer a first attempt from a new sender with 450. The server accepts the retry after a set delay.
Enhanced code 5.7.1 marks a policy block, such as a blocklisted sender. A 5.7.x reply is about the sender, not the address. Keep the address and fix the sending side.
Hard Bounces and Soft Bounces
A hard bounce is a permanent failure, returned with a 5xx code. A soft bounce is a temporary failure, returned with a 4xx code. The sending server retries a soft bounce on a schedule. RFC 5321 sets the give-up point at four to five days.
Example
550 5.1.1 The email account does not exist → hard bounce 452 4.2.2 Mailbox full → soft bounce
Remove a hard-bounced address from the list. Mailbox providers count hard bounces against the sender's reputation. An address soft-bouncing on every send for weeks behaves like a hard bounce. Sending platforms convert repeated soft bounces into suppressions. A hard bounce on a checked list marks an address that died after the check.
Catch-All Domains
A catch-all domain accepts mail for every address at the domain. The server answers 250 to RCPT TO whether the mailbox exists or not.
Example
RCPT TO:<anything@catchall.example> 250 OK
SMTP acceptance on a catch-all domain proves the domain takes mail. The reply says nothing about the mailbox. Mail to a missing mailbox lands in a shared inbox. Other servers discard the mail later. A later bounce, sent after acceptance, arrives as a separate message.
Corporate domains run catch-all setups to catch misspelled staff names. A catch-all setup stops mail from bouncing on a typo. The same setup hides from an SMTP check whether a mailbox exists.
Role-Based, Disposable and Trap Addresses
Three address types need their own handling on a list.
Role-based addresses belong to a function, such as info@, sales@ or support@. Mail reaches a team or a shared inbox. Any reader of the shared inbox can mark a message as spam. B2B lists pick up role-based addresses from website contact pages.
Disposable addresses come from services issuing short-lived inboxes. The inbox expires after minutes or days. The address passes a syntax check and accepts mail while the inbox lives. Mail sent after expiry bounces or goes unread.
Spam traps are addresses that blocklists and mailbox providers run to catch poor list hygiene. Pristine traps were never used by a person. Recycled traps are abandoned addresses a provider reactivated after a dormant period. A hit on either type damages sender reputation.
SPF, DKIM and DMARC
Three DNS records prove a message came from the domain the message names.
SPF checks the envelope sender, not the From address a reader sees. A DKIM signature survives forwarding where SPF fails. DMARC ties both checks to the visible From domain. A DMARC policy reads none, quarantine or reject. RFC 9989 replaced RFC 7489 as the DMARC standard in 2026.
SPF allows ten DNS lookups per check. A record needing more than ten lookups fails with a permerror. DKIM keys rotate by selector, so one domain publishes more than one key. A domain moving to a new sending platform adds the platform to SPF. The domain then publishes the platform's DKIM key.
Since February 2024, Google and Yahoo require SPF, DKIM and DMARC from bulk senders. Gmail treats a sender of 5,000 or more messages a day as a bulk sender.
Authentication and verification answer different questions. Authentication proves who sent the message. Verification checks the address the message goes to.
Checking an Address Before the Send
score.email.validation returns the deliverability verdict and the evidence behind the verdict.
Response, abridged:
JSON
{ "jsonrpc": "2.0", "result": [ { "technical_info": { "domain": "acmecorp.com", "mx_record": "aspmx.l.google.com", "smtp_provider": "Google Workspace", "smtp_status_code": 250 }, "deliverability": { "address": "sofia.marin@acmecorp.com", "status": true, "sub_status": ["corporate"] } } ], "id": 1 }
smtp_status_code carries the raw code, so a 4xx reply stays distinct from a 5xx reply. A check before the send keeps hard bounces out of the campaign. Run the check again before a campaign to an older list. Lead Gen & GTM shows the check inside a sales sequence. score.email.validation takes 2,000 to 10,000 addresses per request.
Terms in this guide