SchedulinqHelp
Go to Schedulinq

Send from your own domain

Have confirmations and reminders arrive from your address instead of Schedulinq's — including the DNS records you need to publish.

By default Schedulinq sends your email from mail.schedulinq.com. That works, but your customer sees a sender that isn't yours. Connect your own domain and confirmations, reminders and invoices arrive from your address — and Gmail and Outlook recognise your messages as legitimate, which keeps them out of the spam folder.

Step by step

  1. Open the sending-domain setting

    Go to Communication → Settings and stay on the Email tab. The Sending domain block sits at the top. Click Connect a domain.

    The Sending domain block with the Connect a domain button highlighted.

    Until you connect your own domain, this tells you which address your email currently leaves from.

  2. Choose the domain you want to send from

    The field starts with mail. on purpose. Complete it into a subdomain of your own domain — mail.yourbusiness.com, for example.

    Step 1 of the wizard, with the subdomain tip and the domain field.
    Why

    A subdomain keeps the sending reputation of your automated messages separate from your ordinary business mail. If delivery ever goes wrong, it doesn't touch your main domain. Just as importantly, your existing mail (Google Workspace, Microsoft 365) already has SPF and DKIM records on your main domain, and those could clash with the new ones.

  3. Publish the DNS records at your provider

    Schedulinq shows three records. Log in to your domain provider, find the DNS management screen for your domain, and add them one by one.

    Step 2 of the wizard with the MX and TXT records and copy buttons.

    Use the copy button next to each value. The DKIM key is a block of several hundred characters that the screen truncates with — retyping it almost always goes wrong.

  4. Verify the connection

    Click I've added the records — verify. When it succeeds you get a confirmation, and Schedulinq sends from your domain from that moment on.

    Step 3 of the wizard: the domain is verified.

The records, one by one

Here's what you're publishing and why. The exact values are in your own screen — copy them from there, not from this example.

The three DNS records: one MX record and two TXT records.

MX record

Required

Name send.yourdomain, value feedback-smtp.eu-west-1.amazonses.com.

Why

This catches the feedback from mail servers that reject your message or mark it as spam. Without it you still send, but you never hear about it when delivery starts failing.

TXT record for SPF

Required

Name send.yourdomain, value v=spf1 include:amazonses.com ~all.

Why

SPF is the list of servers allowed to send on behalf of your domain. If Schedulinq's server isn't on it, any receiving mail server is entitled to reject your message — and in practice they do.

TXT record for DKIM

Required

Name resend._domainkey.yourdomain, value a long key starting with p=.

Why

DKIM puts a digital signature on every message so the recipient can check it wasn't altered in transit. This is the record that most often goes wrong, precisely because the value is so long.

TXT record for DMARC

Recommended

Name _dmarc.mail, value v=DMARC1; p=none;.

The recommended DMARC record below the required ones.
Why

DMARC tells Gmail and Outlook what to do when SPF or DKIM doesn't check out. Without it your messages land in spam more often, even with the other records set correctly. p=none means observe only, reject nothing yet — the safe setting to start with.

When verification doesn't work yet

You'll see DNS records not yet propagated.

The not-yet-propagated notice at the bottom of the wizard.

That's usually patience rather than a mistake. DNS changes have to spread across the internet, and the check runs in the background as well — sometimes clicking again after half a minute is enough.

If it still fails after an hour, work through this:

  1. Are all three records there? The DKIM line is the one most often missed.
  2. Are the names written correctly? See the warning above.
  3. Is the DKIM value complete? Copy it again with the copy button.
  4. Is there already an SPF record on the same subdomain? Two SPF records side by side is invalid; they have to be merged into one line.

You don't have to sit and wait with the screen open. Click Later — your domain stays listed as Pending under Sending domain, and you can reopen the wizard there to verify.

Once it works

The domain shows as Verified in your settings, and all customer mail goes out from it from then on.

The Sending domain block with a verified domain and a delete button.

Leave the records in place. Remove them at your provider later and Schedulinq loses its verification, and a warning appears in your settings saying the setup has to be completed again.

Frequently asked questions

Can I use my main domain instead of a subdomain? Yes. Enter a domain without a subdomain and a warning appears — you have to tick that you understand the risks before you can continue.

The root-domain warning with an 'I understand the risks' checkbox.

The risk is a clash with the SPF and DKIM records of your existing mail, which can cause delivery problems for your ordinary business post. Choose a subdomain unless you have a good reason not to.

Does this change the address customers can reply to? No. The reply address is set separately under Default sender on the same page.

Do I need to do anything if I move to another domain provider? Yes — your DNS moves with you, so the records have to be recreated at the new provider. Do that before the move if you can, so there's no window in which your messages go out without a valid signature.

Can I disconnect the domain again? Yes, with the delete button next to the domain. Your messages then go out from mail.schedulinq.com again.

Last updated August 26, 2026