Table of Contents
- iCloud IMAP and SMTP Settings at a Glance
- What do these fields actually control?
- Username Format for Your iCloud Address
- Could an alias be causing the rejection?
- How to Create an App-Specific Password for iCloud Mail
- What must be enabled before generating the password?
- How to verify it
- How to Enter iCloud Settings in a Mail App
- Which fields need to be filled in?
- Check the outgoing server before sending
- Custom Domain DNS Records for iCloud Mail
- Which records belong at the DNS host?
- How to verify it
- Connection Errors and Common Mistakes
- Which mistakes need a targeted fix?
- How to verify it
- Confirm Your iCloud Connection Before You Send
- How to verify it
- Frequently Asked Questions About iCloud IMAP
- Does iCloud Mail need POP?
- Is the full iCloud email address always required?
- How can an administrator tell whether custom-domain DNS is live?
Do not index
Do not index
iCloud Mail uses imap.mail.me.com on port 993 with SSL/TLS for incoming mail and smtp.mail.me.com on port 587 with STARTTLS for outgoing mail, with an app-specific password in place of the Apple Account password for manual password-based setup. What happens when those values are correct, but the app still rejects the account?
The missing detail is often authentication capability, not the server address. Supported apps can offer Apple Account authorization, while clients without that flow need an app-specific password and the correct username format.
Table of Contents
iCloud IMAP and SMTP Settings at a GlanceWhat do these fields actually control?Username Format for Your iCloud AddressCould an alias be causing the rejection?How to Create an App-Specific Password for iCloud MailWhat must be enabled before generating the password?How to verify itHow to Enter iCloud Settings in a Mail AppWhich fields need to be filled in?Check the outgoing server before sendingCustom Domain DNS Records for iCloud MailWhich records belong at the DNS host?How to verify itConnection Errors and Common MistakesWhich mistakes need a targeted fix?How to verify itConfirm Your iCloud Connection Before You SendHow to verify itFrequently Asked Questions About iCloud IMAPDoes iCloud Mail need POP?Is the full iCloud email address always required?How can an administrator tell whether custom-domain DNS is live?
iCloud IMAP and SMTP Settings at a Glance
The iCloud IMAP settings below apply to manual configuration in compatible email apps. Automatic Apple Account setup is a separate path and may not expose these fields.
Apple's iCloud Mail server settings document the incoming server as
imap.mail.me.com, port 993, with encrypted access, and explain the shortened-username fallback and app-specific-password requirement. Apple also states that iCloud Mail supports IMAP and SMTP, not POP.What do these fields actually control?
IMAP lets an email app access and synchronize a mailbox. SMTP handles outgoing messages. Receiving successfully doesn't prove that sending works, because the app makes separate connections to separate services.
The hostname identifies the service. The port and encryption setting determine how the app establishes a protected connection. Those settings must work as a pair: a security-mode mismatch can stop the connection before the server even checks the password.
Some apps use SSL as a broad label for encrypted connections. Others distinguish SSL/TLS, which starts encryption immediately, from STARTTLS, which upgrades the connection before authentication. The app's actual behavior matters more than a vaguely labeled checkbox.
The mailX IMAP finder provides provider settings and a setup-guide reference without asking for mailbox credentials. That makes it useful for checking a host or security setting before a login test.
For a manually configured client, the next preparation step is an app-specific password. An authenticated IMAP check then determines whether the server accepts the chosen username and credential.
Username Format for Your iCloud Address
Type the wrong string into the username field and iCloud Mail rejects the login even when the password is correct. The username tells the server which mailbox to open. The password proves you are allowed to open it.
For an
@icloud.com address, the username is the local part, the text before the @. An account at jane@icloud.com authenticates as jane. That shortening is why the address someone hands out and the string typed into a mail app can look different.The custom domain is the exception that catches administrators. With
@icloud.com, @me.com, and @mac.com, Apple owns the domain and can map the short name to a mailbox. With a domain you added to iCloud+, the login string has to carry the domain so the service knows which hosted mailbox is being requested.If a client rejects the short name, retype the full address before touching the password. Some clients pass the whole string through as the login and never split it at the
@.Could an alias be causing the rejection?
Yes, and it is the most common misread. An alias receives mail, which makes it feel like a login identity, but delivery and authentication are separate tests. Apple Account settings show the primary iCloud Mail address. Compare the client's username field against that primary address, not against the alias a colleague happens to use.
Outgoing settings need their own check. A setup that copies the shortened incoming username into the SMTP username may need the full iCloud Mail address entered explicitly, and app-specific passwords work as the credential on both connections.
How to verify it: run the IMAP checker with the confirmed account identity and a valid app-specific password. Success confirms the username and credential pair together. A rejection means going back to both fields, because the error message rarely says which one failed.
How to Create an App-Specific Password for iCloud Mail
First, identify the app's supported sign-in method. Apple's guidance on authorizing third-party apps distinguishes supported Apple Account authorization from apps that require an app-specific password.
An Apple Account approval flow isn't the same thing as entering the main account password into a generic IMAP password field. Desktop clients, scripts, and AI agents without an approval screen need the password-based fallback.
What must be enabled before generating the password?
Apple's app-specific password instructions require two-factor authentication, allow up to 25 active app-specific passwords, and state that changing or resetting the main Apple Account password revokes all of them.
- Confirm two-factor authentication. The Apple Account must have this protection enabled before an app-specific password can be generated.
- Sign in at the Apple Account website,
account.apple.com, and open Sign-In and Security. Password generation happens in the account's security settings, not inside the email app.
- Select App-Specific Passwords and generate a password. A descriptive label identifying the client or device makes later revocation easier.
- Copy the generated password into the mail client. The app-specific password belongs in the mailbox password fields instead of the main Apple Account password.
- Keep each client's credential separately in a secure password manager. Separate credentials let the account owner revoke access for a retired client without disrupting unrelated clients.
The main Apple Account password isn't the correct fallback for legacy password-based IMAP access. Repeatedly entering it won't repair a setup that requires an app-specific credential.
How to verify it
Run the mailX IMAP checker with the confirmed username and newly generated password. A good result shows connection, encryption, and authentication succeeding.
An authentication failure means the server was reached but didn't accept the submitted identity and credential. Check for an incorrect copy, a revoked password, or an unsuitable username before generating another password.
How to Enter iCloud Settings in a Mail App
Most manual setup screens split iCloud Mail into two server entries: one for incoming mail and one for outgoing mail. Both use the same username and app-specific password, but they use different hostnames, ports, and security modes.
The same field-by-field approach applies to a generic desktop application or a native Mac mail client from Sickle. The practical question is whether the app supports Apple authorization or requires manual IMAP and SMTP credentials.
Which fields need to be filled in?
- Open Add Account and choose Manual or Advanced setup. These options expose the server fields; an automatic Apple Account flow may handle configuration differently.
- Set Account Type to IMAP. A POP-only configuration won't provide access to iCloud Mail.
- Enter the incoming settings first. Select the security mode explicitly rather than relying on automatic detection.
- Enter the outgoing settings separately. Enable SMTP authentication if the client exposes that switch.
- Supply the confirmed username and app-specific password in both server entries. If the app offers "use incoming credentials," confirm that the copied SMTP username is the full iCloud address.
- Save the account and allow the initial mailbox fetch. Reopen the saved server settings if the app changes a port or security mode automatically.
An app may store an outgoing server independently from the mailbox. Saving the incoming account doesn't necessarily save a usable outgoing configuration, particularly when an existing SMTP profile is selected by default.
Check the outgoing server before sending
Watch the first mailbox sync to confirm incoming access. Then run the mailX SMTP test with the same username and app-specific password. A successful result shows connection, encryption, and authentication succeeding for the outgoing server.
Finally, send a message to an address controlled by the account owner. A delivered test message confirms the outgoing path end to end.
Custom Domain DNS Records for iCloud Mail
An iCloud+ custom domain adds a DNS task alongside mail-client setup. The client still connects to Apple's mail services, but the domain's DNS host must publish the records Apple assigns to that domain.
Three record types carry the load. MX records route incoming mail to Apple's servers. SPF identifies which sending services are authorized to use the domain. DKIM lets receiving systems verify a cryptographic signature using a public key published in DNS.
Which records belong at the DNS host?
The table below gives the typical MX and SPF values, plus the DKIM shape you will see in Apple's custom-domain settings. Apple generates the DKIM pair per domain, so treat the MX and SPF values as standard and the DKIM host and target as copies of what your account shows.
The
@ symbol commonly represents the domain root in DNS control panels. Some DNS hosts instead expect a blank host field or the domain itself, so follow your host's input convention.A control panel may also append the domain automatically. Pasting an already complete DKIM hostname into such a field can create a duplicated domain suffix and publish the record at the wrong name.
How to verify it
Run the mailX MX lookup and compare the returned hosts and priorities with Apple's domain configuration. Then read the SPF record as published and confirm the DKIM answer resolves at the exact selector Apple shows.
A good result returns the expected routing hosts and a signed authentication policy. A missing or mismatched answer means one of four fields was saved wrong: host, record type, target, or priority. Check those before touching mailbox credentials, and allow for DNS caching if a recent edit has not propagated yet.
Connection Errors and Common Mistakes
A generic connection error doesn't identify a single cause. Separate the failure into three layers: network reachability, encryption, and credential acceptance. The symptom narrows the layer, and the fix should match that layer. A timeout points to the host or port. A certificate warning points to the encryption setting. An authentication rejection points to the username or password.
The table lists likely causes. A firewall or network restriction can produce a timeout. A certificate warning requires checking the hostname and certificate chain; disabling validation hides the problem and leaves the connection exposed. Some clients save settings per account, so an old username or password can survive after the server fields are corrected.
Which mistakes need a targeted fix?
- Duplicate SPF records. Separate SPF policies at the same name make evaluation fail. Merge authorized services into one policy and inspect the result as a single record.
- Too many SPF DNS lookups. SPF has a fixed lookup limit, and include statements can trigger nested lookups. Remove unused services and evaluate the full chain rather than counting only visible includes.
- Wrong DKIM selector. A lookup for an unrelated selector won't find Apple's key. Copy the selector exactly from Apple's domain settings.
- CNAME instead of TXT for SPF. SPF policy text belongs in a TXT record at the appropriate domain name. Confirm the policy is published as text, not as a CNAME.
- Wrong port and encryption pair. An encrypted connection still fails when the client starts TLS at the wrong stage. Confirm 993 with SSL/TLS for IMAP and 587 with STARTTLS for SMTP, then choose the right IMAP port before retesting.
- Missing app-specific password. A manual client may still have the main Apple Account password saved in its credential store. Replace that saved credential and retest the login.
Fix DNS records for routing and SPF problems; fix credentials for authentication failures. An MX change doesn't repair an IMAP rejection, and a new app-specific password doesn't correct a missing SPF record.
How to verify it
Rerun the failing connection after each change. A clean pass on incoming and outgoing access confirms those paths; a repeated failure at the same layer means the associated hostname, security setting, username, or credential still needs investigation. For custom domains, rerun the specific DNS check separately. A successful mailbox login does not validate SPF, DKIM, or routing.
Confirm Your iCloud Connection Before You Send
Three results confirm an iCloud connection: incoming authentication passes, authenticated outgoing submission passes, and custom-domain DNS matches Apple's configuration.
- Test incoming access. Run an authenticated IMAP check with the confirmed username and app-specific password. A pass shows the account credentials and incoming host settings work together.
- Test outgoing submission. Run the mailX SMTP test, then send a test message to an address the account owner controls. The outgoing settings are saved separately, so they need their own authenticated pass.
- Check custom-domain DNS. Query the MX and SPF records against what Apple lists for the domain. DNS checks can run while client settings are still being corrected.
How to verify it
Confirm successful connection, encryption, and authentication for both paths, then confirm receipt of the test message. A delivered test message confirms the outgoing path end to end. The SMTP result alone confirms the login and submission handshake. Ask before submitting a mailbox password or sending a test message, and use credentials only for the account being tested.
Frequently Asked Questions About iCloud IMAP
Does iCloud Mail need POP?
No. iCloud Mail supports IMAP for mailbox access and SMTP for sending, but it doesn't support POP. A client that offers only POP isn't suitable for this setup. IMAP is the appropriate incoming protocol when the account owner needs server-backed mailbox access and synchronized changes across compatible devices.
Is the full iCloud email address always required?
No. For incoming access to an address ending in
@icloud.com, the username is usually the part before the domain. Some clients require the full address instead. Legacy addresses, aliases, custom domains, and outgoing SMTP authentication need separate attention, so an accepted incoming short name shouldn't automatically be assumed suitable for every field.How can an administrator tell whether custom-domain DNS is live?
Query the records using the mailX TXT lookup and the MX lookup. An expected answer confirms that the record is visible through the resolver used for that query, not necessarily every resolver. Cached older answers can remain until their TTL expires; the configured TTL and DNS host determine the relevant caching behavior.
mailX offers free, no-signup checks with plain-English explanations for iCloud connection and custom-domain DNS problems. Visit mailX to test incoming IMAP and outgoing SMTP separately, or use its MCP access for an explicitly authorized agent-assisted check.