Verifying sending domains

Before Sendly sends mail from your own domain, that domain has to be verified. Verification is also what lets receivers authenticate your mail, which is most of what keeps it out of the spam folder.

What is a sending domain?

A sending domain is the domain in the address your mail comes from: yourdomain.com in hello@yourdomain.com. It can be your root domain or a subdomain such as mail.yourdomain.com; each one you add is verified on its own and keeps its own reputation with mailbox providers.

Verifying it means publishing DNS records that prove you control it. Sendly asks for three kinds, each covered below:

• DKIM — 3 CNAME records that let receivers verify the DKIM signature your mail is sent with. These decide verification.
• Custom MAIL FROM — an MX and an SPF TXT record on sendly.yourdomain.com, the subdomain your Return-Path (envelope sender) uses, so SPF aligns with your domain.
• DMARC — one TXT record stating your policy for mail that fails both checks.

Verifying a domain

You can verify a domain by adding it in the domain tab of the project settings. Once added, Sendly will provide you with the necessary DNS records to add to your domain's DNS settings.

Once you have added the DNS records, it may take some time for the changes to propagate. You can check the verification status in the domain tab of the project settings.

DNS Records

Domain verification requires adding several DNS records to your domain. Each record serves a specific purpose in email authentication and delivery. Every value in the table below has a copy icon next to it in the dashboard — use it rather than retyping.

DKIM Records (3 CNAME records)

DomainKeys Identified Mail (DKIM) adds a digital signature to your emails, proving they haven't been tampered with during transit.

You'll need to add 3 CNAME records provided by Sendly. These records contain cryptographic keys that email receivers use to verify your emails are authentic.

These are the records that decide verification: the domain flips to Verified when Amazon SES reads them back.

Why it matters:

• Prevents email spoofing and tampering
• Improves deliverability and inbox placement
• Required by most email providers (Gmail, Outlook, etc.)

Custom MAIL FROM (1 MX + 1 TXT record)

Sendly sets a custom MAIL FROM subdomain — sendly.yourdomain.com — on every sending identity. Both of the following records belong on that subdomain, not on your root domain:

The dashboard fills in your deployment's actual AWS region. The MX record is how bounce and complaint reports get back to your own subdomain; the TXT record is the SPF policy that authorizes Amazon SES to send for it.

Why it matters:

• Bounces and complaints are attributed to your domain instead of Amazon's
• SPF aligns with your domain, which is what DMARC actually checks
• Automatically tracks which contacts have bounced or complained
• Prevents sending to invalid email addresses

DMARC Policy (1 TXT record)

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receivers what to do with mail that claims to be from your domain but fails DKIM and SPF.

Sendly prescribes p=none on purpose. It is a monitor-only policy: it changes nothing about how receivers treat your mail, so publishing it cannot break a domain that is already sending — while still making _dmarc present, which some receivers weigh. Once you're confident you know every system that sends as your domain (your app, your CRM, your invoicing tool, your helpdesk), you can tighten it to p=quarantine and then p=reject yourself. Starting at p=reject before that inventory exists is how legitimate mail gets thrown away.

Inbound Email (1 MX record)

This MX record, on your root domain, decides where mail addressed to your domain is delivered. It is separate from the MAIL FROM MX above and is not required for sending.

Verification Status

After adding all DNS records, Sendly will automatically check the verification status. Verification typically completes within a few minutes but can take up to 72 hours depending on DNS propagation.

You can check the status in the Domains section of your project settings:

• The domain shows a Verified or Pending badge. Amazon SES is the only authority on this — the badge flips when SES confirms your DKIM records, not when your DNS provider says the records were saved.
• The DNS Health row shows a chip per record family: DKIM, SPF, DMARC and MAIL FROM, plus the date of the last check. Sendly re-checks these on its own schedule; the refresh button on the domain row runs a check immediately.
• If guided setup is connected, an amber DNS Drift chip appears when a record you had published stops resolving.

Troubleshooting

Records not verifying

If your DNS records aren't verifying after 24 hours:

1. Double-check the values: Ensure you copied the exact values without extra spaces
2. Check you're in the right zone: If your domain's DNS is delegated to a subdomain or a second provider, the records must go in the zone that actually answers for the name shown in the table
3. Watch for auto-appended domains: Many DNS panels append your domain to whatever you type. Pasting the full name into such a field produces sendly.yourdomain.com.yourdomain.com
4. Check DNS propagation: Use tools like dig or online DNS checkers to verify the records are published
5. TTL settings: Some DNS providers cache records. Try lowering the TTL (Time To Live) value
6. Contact your DNS provider: Some providers have specific requirements or interfaces for adding these record types

MAIL FROM says "ACTION REQUIRED"

SES isn't using your sendly.yourdomain.com subdomain yet. The notice in that section names the exact state:

In every one of these states your mail still sends — with amazonses.com as the envelope sender.

The DNS Drift chip appeared

A record you had successfully published stopped resolving. This is usually a DNS record deleted during unrelated cleanup, a provider migration that didn't carry every record across, or a zone that was rebuilt from an older export.

Drift does not un-verify your domain — SES may still consider the identity verified because of caching and TTLs — but it is an early warning that sending will start failing. Open the DNS records table, re-publish the records that no longer match, and use Re-check DNS to ask for an immediate re-check. See drift monitoring.

Emails still going to spam

Even with a verified domain, emails may go to spam if:

• Your content triggers spam filters (excessive links, suspicious keywords)
• Your sender reputation is new or low
• Recipients have marked your emails as spam in the past
• You're sending to invalid or unengaged contacts

Follow email best practices and maintain good list hygiene to improve deliverability.