Add a custom domain

Connect a domain you own so Smailor can receive and send customer email from an
address such as [email protected]. This guide explains the decisions, DNS
changes, verification steps, and final tests.

Use the exact record names and values shown in your Smailor dashboard. Values
in this guide are examples and must not be copied into production DNS.

Before you start

You need:

• access to Settings → Domains in Smailor;
• permission to edit DNS at the authoritative DNS provider for the domain;
• a mailbox outside the domain, such as a personal Gmail or Outlook account, for
  end-to-end tests;
• a record of every service that already sends or receives mail for the domain.

If another provider currently receives mail for the same domain, changing MX
records can redirect all incoming mail. Read Use Smailor with Proton
Mail when Proton must remain the primary inbox. Ask
Smailor support before changing MX if the desired coexistence model is unclear.

Choose the domain carefully

You can connect an apex domain or a dedicated subdomain:

Enter only the domain portion in Smailor. For [email protected], add
mail.example.com, not the full email address and not https://mail.example.com.

How the records fit together

Customer sends mail
        |
        v
MX record ------> Smailor receives the message

Smailor sends a reply
        |
        +------ SPF authorizes the sending path
        +------ DKIM signs the message
        `------ DMARC checks alignment and applies your policy

Ownership verification proves that you control the domain. It does not, by
itself, route or authenticate email.

Step 1: Add the domain

1. Open Settings → Domains.
2. Select Add domain.
3. Enter the exact apex domain or subdomain you chose.
4. Keep the Smailor tab open so you can copy the generated records exactly.

Smailor displays a record set for that specific domain. Do not reuse records
from another domain or from a screenshot of another account.

Step 2: Publish the DNS records

Add each record at the DNS provider that hosts the domain's nameservers.

DNS interfaces label the same fields differently. Name, Host, and
Hostname usually mean the record name; Value, Content, Target, and
Points to usually mean the record value.

Avoid the most common DNS mistakes

• Publish only one SPF record per hostname. Merge authorization mechanisms
  into the existing SPF value instead of adding a second v=spf1 record.
• Do not delete existing MX records until you intentionally want Smailor to
  replace the current receiving provider.
• Enter the host exactly as your DNS provider expects. Some providers append the
  domain automatically, so pasting a full hostname can create
  name.example.com.example.com.
• Keep mail records in DNS-only mode when a provider offers HTTP proxying.
• Copy DKIM without changing, wrapping, or truncating the p= public key.
• Start DMARC in monitoring mode unless you already understand every legitimate
  sender for the domain.

Step 3: Verify in Smailor

1. Return to Settings → Domains.
2. Open the domain, then its Deliverability section.
3. Select Verify DNS.
4. Review each record separately. A green ownership result does not mean SPF,
   DKIM, DMARC, and MX are all correct.

DNS changes are cached. Many changes appear within minutes, but previous TTLs
and provider caches can make a record take 24–48 hours to appear everywhere.
Repeatedly editing a correct record usually delays diagnosis; first compare the
public lookup result with the value shown by Smailor.

Step 4: Create the customer-facing address

After ownership and the required DNS checks pass:

1. Open Settings → Addresses.
2. Add the local part, such as support, and select the verified domain.
3. Confirm that the address shows as active.
4. Assign it to the appropriate group or team workflow.

An active address controls what Smailor accepts and what users may send from. A
DNS record alone does not create an inbox address.

Step 5: Test both directions

Use an external mailbox that is not hosted on the domain.

Test incoming mail

1. Send a new message to the Smailor address.
2. Confirm it appears as a new ticket with the expected sender and subject.
3. Confirm attachments and routing rules behave as expected.

Test outgoing mail

1. Reply from the ticket in Smailor.
2. Confirm the external mailbox receives the reply.
3. Inspect the received message's authentication details and verify SPF, DKIM,
   and DMARC results.
4. Reply again from the external mailbox and confirm the conversation threads
   onto the existing ticket.

Do not start production traffic until both directions pass.

Go-live checklist

• The intended apex domain or subdomain is connected.
• Ownership is verified.
• MX matches the chosen receiving model.
• Exactly one SPF record authorizes every legitimate sender.
• DKIM is verified in Smailor.
• DMARC is published with a reporting address you monitor.
• The customer-facing address is active and assigned correctly.
• New message, reply, and threading tests pass.
• Bounce and complaint monitoring has an owner.

Troubleshooting

Smailor still shows a record as missing

Query the exact hostname shown by Smailor, confirm which provider owns the
authoritative nameservers, and compare the public value character for character.
Editing DNS at the registrar has no effect when nameservers point elsewhere.

Incoming mail stopped reaching the old provider

MX controls incoming delivery. Restore the previous MX records if the change
was accidental, then decide whether to forward selected addresses or use a
dedicated subdomain.

Sending works but messages go to spam

Authentication is necessary but not sufficient. Verify alignment, send only to
consenting recipients, warm a new domain gradually, remove invalid addresses,
and monitor delivery statistics.

Next steps

• Understand SPF, DKIM, DMARC, and MX
• Publish and verify DKIM
• Integrate with the REST API