Email delivery is a sequence of handoffs: your app submits a message to an outgoing mail service, DNS helps that service find the recipient domain’s mail server, and SMTP transfers the message between systems. The receiving provider then decides whether to accept it and where to store it. An SMTP handoff is not a guarantee that the message will appear in the recipient’s primary inbox.
How does email get delivered?
For a message addressed to [email protected], the sender’s mail system uses example.com to find where incoming mail for that domain should go. The mail application’s outgoing service and the recipient domain’s routing records serve different purposes: the first accepts the sender’s message; the second helps route it toward the destination.
- The sender prepares and submits the message. A mail application or service creates the message’s headers—such as
From,To, andSubject—and body, then submits it to an outgoing mail service, commonly using SMTP submission. - The sending system looks up the destination. It queries DNS for the recipient domain’s MX records, which name mail exchangers and include preference values. A lower preference value means that exchanger is preferred. The sending system resolves the selected exchanger’s hostname to an IP address before connecting.
- SMTP transfers the message. The sending system acts as an SMTP client and exchanges commands and replies with a receiving server. That server might be the final destination or a relay; a message can pass through multiple mail systems.
- The destination provider processes the message. It may accept the message into a mailbox, reject it, or defer it. If accepted, it may still classify the message as spam or place it in another folder.
- The recipient accesses the stored message. A mail application typically uses a separate mailbox-access protocol or the provider’s interface to show the message. SMTP covers transport to the message store, not every part of the inbox experience.
As RFC 5321 puts it, “The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.” That describes SMTP’s transport role; it does not mean every transferred message reaches the inbox.
What does an MX record do?
An MX (mail exchanger) record tells sending mail systems which host to try when delivering mail to a domain. If there are multiple exchangers, their preference values establish which is preferred and which can serve as an alternative. Those values are routing preferences—not a priority for the recipient’s inbox.
#1 Best Overall
The exchanger hostname must ultimately resolve to an address so the sender can connect. If a domain has no MX record, RFC 5321 defines an implicit-MX fallback: the domain itself is treated as the mail host, subject to address resolution.
MX records route incoming mail. They do not authenticate the sender, guarantee delivery, choose the destination folder, or by themselves configure outbound sending. The correct MX values depend on the email host; use the records specified by the provider that will receive the domain’s mail. Cloudflare’s MX record guide also describes MX records as the way to identify a domain’s mail server.
SMTP transport is different from message format
SMTP governs how mail systems exchange and relay a message. The format of the message carried by SMTP is defined separately: RFC 5322 specifies Internet message headers and body, while MIME provides common structures for content such as multipart messages and attachments.
There are also two sender identities worth distinguishing. The visible From: header is part of the message format. The SMTP envelope sender is supplied separately in the MAIL FROM command. They can be related, but they are not the same field or necessarily the same identity.
What’s the difference between MX, SPF, DKIM, and DMARC?
| Mechanism | Main role | What it answers |
|---|---|---|
| MX | Routing | Which mail exchanger should receive mail for this domain? |
| SPF | Authorization | Is this sending host authorized to use the domain in the SMTP HELO/EHLO or MAIL FROM identity? |
| DKIM | Cryptographic authentication | Does the message have a valid domain-associated signature, and has signed content remained intact? |
| DMARC | Alignment, policy, and reporting | Do SPF and/or DKIM authenticate in alignment with the visible From domain, and what policy and reporting instructions has the domain owner published? |
These mechanisms do different jobs. SPF checks SMTP identities such as HELO/EHLO and MAIL FROM; it does not simply verify the visible From: address. RFC 7208 describes SPF’s authorization checks. DKIM uses a cryptographic signature associated with a domain and a public key published through DNS. DMARC connects SPF and DKIM results to the visible From domain through alignment, and lets a domain owner publish policy and reporting instructions. See RFC 7489 for DMARC.
Authentication results can inform a receiving provider’s decision, but passing one or more checks does not guarantee inbox placement. The provider can still reject, defer, or filter a message.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why did my email go to spam instead of the inbox?
SMTP acceptance means a receiving system accepted the message at that point in its route. It does not promise delivery to the primary inbox: the destination provider may filter accepted mail into spam or another folder. Likewise, successful SPF, DKIM, or DMARC results are not an inbox-placement guarantee.
To narrow down a delivery problem, inspect the actual DNS answers, SMTP response codes, delivery logs, authentication results, and any bounce or deferral notice. A relay may accept a message that a later system rejects or filters, so an acceptance response from one server does not prove the whole route succeeded.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsQuick Recap
Best Value
How to configure and troubleshoot domain email
- Use provider-issued DNS values. Get MX records from the email provider that will host or route the domain’s mail. Generic example values are not a substitute for that provider’s settings.
- Keep SPF in one TXT record per name. SPF is published as a DNS TXT record. RFC 7208 does not permit multiple SPF records at the same owner name; multiple records can cause configuration errors.
- Copy DKIM settings exactly. The selector and public-key value are specific to the provider. Confirm both in its dashboard or documentation.
- Publish DMARC at the correct name. DMARC is a DNS TXT record at
_dmarc. Policy options include monitoring, quarantine, or rejection. Validate legitimate sending services before enforcing a restrictive policy. - Allow for DNS caching. Cloudflare says changes made through its DNS service usually propagate in 5–15 minutes, while allowing up to 24 hours. This is Cloudflare guidance for its service, not a universal timing guarantee. See its email-record setup documentation.
- Follow the evidence in the failure response. Check DNS records and SMTP replies alongside provider logs, authentication results, and bounce or deferral messages. A DNS change alone will not explain every rejection or spam classification.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
