The Zone file correctly shows example.com. IN MX 10 mail.example.com..
Expected Behavior
Set the correct DNS record.
Actual Behavior
DNS Record on example.com for key and type MX is mail.example.com.example.com.
Stalwart Version
v0.16.x
Installation Method
Docker
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.
This looks like a bug in how the Scaleway DNS provider integration composes record names rather than a configuration mistake on your side. Stalwart’s DNS record builder generates the MX exchange target correctly (mail.example.com.), and the zone file that Stalwart computes internally shows the correct value, but the Scaleway API client appears to append the zone origin (example.com) to the record name a second time when submitting it to Scaleway’s API, resulting in mail.example.com.example.com. being sent instead of the plain mail.example.com.. There’s nothing in the current docs about a workaround for this (e.g. no config knob to disable the extra suffixing for Scaleway specifically), so this isn’t something you can fix from your side via configuration.
Given the specificity of this, a human/staff member should confirm and look at the Scaleway provider integration directly.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.