Hello,
I’m not a technical user, but I’ve searched a bit for answers before posting here and I found none.
I’ve been playing around with Stalwart for a bit and now my set up is:
Ubuntu server
Stalwart 0.16.24
domain: example.im (no DNSSEC because .im does not allow it)
mail host: notexample.org (with DNSSEC ebabled)
I’ve recently switched from a more easy configuration (domain: example.im and mail host: mail.example.im), which was working perfectly, because in the near future I will need to use different domains on the same server.
I’m experiencing two issues:
Many mails do not reach my inbox. Looking at the logs I see this entry repeated many times over:
“listenerId = “smtp”, localPort = 25, remoteIp = 139.71.106.170, remotePort = 43510, domain = “extmta2ipc1.americanexpress.com”, result = No SPF record (spf.none), elapsed = 18ms”
Before the change I always got the emails from my credit card issuer with no problem at all.
I cannot log on the iPhone mail app. It says that the username and password are incorrect. I’ve tried so many times with many possible combinations that I managed to ban my IP…
I appreciate that these are different issues, but both started with the new configuration. Do you think there is a link? Is there something I should be aware of when configuring the mail host with a different domain than the domain?
Sorry that my reporting is not great. I’d be thankful for any help you will provide.
Expected Behavior
Emails should be delivered to my inbox and I should be able to log onto the iPhone mail app
Actual Behavior
I am not getting A LOT of emails and I can’t add my account on the phone.
Relevant Log Output
listenerId = “smtp”, localPort = 25, remoteIp = 139.71.106.170, remotePort = 43510, domain = “extmta2ipc1.americanexpress.com”, result = No SPF record (spf.none), elapsed = 18ms
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Two separate issues here, and I don’t think they’re actually linked to each other:
1. The “No SPF record” (spf.none) log line is not a rejection.
That log entry is a debug-level informational event, it simply records that the sending server (Amex’s extmta2ipc1.americanexpress.com) doesn’t publish an SPF record for its HELO identity. By default Stalwart’s SPF check runs in relaxed mode, which only reports the result in headers, it does not reject the message. Unless you’ve explicitly set spfEhloVerify/spfFromVerify to strict on the SenderAuth object, this entry alone cannot explain messages failing to arrive. See SPF authentication.
If mail from that sender is truly missing (not just delayed or in spam), check:
Your MX record actually points to your mail host (notexample.org), and the mail host’s A/AAAA record resolves correctly.
The message isn’t being caught by spam filtering/greylisting rather than rejected outright, check the message queue and spam scoring in the WebUI.
Your domain’s own SPF/DKIM/DMARC records (published under example.im) correctly authorize your mail host, since the domain and mail host are now different names, your SPF record needs something like v=spf1 a:notexample.org mx -all rather than the default a/mx examples that assume domain and host match. See Setting up DNS.
2. iPhone login failures likely just need the full email address as the username, and you’ve now triggered the auto-ban system after repeated failed attempts. Authentication failures (from any protocol) count against your IP under the authBanRate threshold (default 100/day) and get recorded as a BlockedIp entry; you’ll need to remove that entry (via the WebUI’s Blocked IPs page, or the CLI) before you can try again. See Auto-banning.
Once unbanned, in Mail on iPhone use manual setup with:
Incoming/outgoing server: your mail host (notexample.org, whatever hostname the certificate actually covers)
Username: the full email address ([email protected]), not just the local part
If login still fails with correct full-address credentials against the right host, that would point to a directory/authentication problem rather than a DNS one, worth a follow-up post with the exact IMAP/SMTP error from the logs.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Using a mail host on a different domain is fine; plenty of servers are set up that way. That SPF line isn’t what stops the mail either. It checks the name the sending server introduced itself with, American Express publishes no SPF record for that name, and with the default settings the result is only logged. If you never changed the “EHLO SPF verification” setting to strict, the reason those messages don’t arrive comes later in the same connection. Search your log for 139.71.106.170 and post every line from one of those connections, and check your Junk folder too.
For the iPhone, first remove your own IP from the blocked IPs in the web UI, and add it to the allowed IPs so it can’t happen again while you test (Auto-banning | Stalwart). Then set the account up by hand: the username is your full email address, and the incoming and outgoing server is the new host name. Left to itself, the phone tries mail.example.im, which no longer leads to the right server and certificate.
Which host name does the MX record for example.im point at now?