EmbedAuth sends every authentication email for you, from our own domain. You do not need to configure DNS, SPF, DKIM or a mail server for auth email to work. If a verification email is not arriving, the cause is almost never DNS on your side — see what to check below.

The second half of this page is a reference for the separate job of making your own domain send and receive mail. That is independent of EmbedAuth, but it is the setup people most often get wrong, so the records and the traps are documented here.

What EmbedAuth sends

All of them are sent from:

EmbedAuth <[email protected]>

This address is authenticated by our SPF and DKIM records, aligned under a DMARC policy, and it stays the same for every account. Nothing about it depends on your domain, which is why there is nothing for you to set up.

Your brand in the message

The brandName configured for your client app appears in the subject line and body of these emails, so a user sees your product name rather than ours. The From address remains [email protected].

If you would rather your users never saw a reply address you do not control, tell them to reply to your own support address in your onboarding copy — replies to no-reply@ are not monitored.

When an email does not arrive

Work through these in order. They are ordered by how often each turns out to be the cause.

1. Check the spam folder. New sending relationships land in spam more often than anywhere else, particularly for a first-time recipient on a corporate mail filter.
2. Confirm the address is real. A typo in the signup form is by far the most common cause. The API returns success either way, deliberately — it does not confirm whether an address is registered, since that would let anyone enumerate your users.
3. Check the recipient's mail server is not greylisting. Some servers defer a first message from an unfamiliar sender and accept the retry a few minutes later. The mail arrives late rather than never.
4. Check your rate limits. Repeated requests for the same address in a short window are throttled, and the later ones send nothing.
5. Corporate filters. If a customer's whole company is missing emails, ask their IT team to allow [email protected]. Because SPF, DKIM and DMARC all pass, an allow rule is straightforward for them to justify.

If you have worked through all five and mail is still missing, contact support with the recipient address and an approximate timestamp so we can trace the delivery.

Setting up email on your own domain

Everything below is about your domain — a support inbox at [email protected], or your own transactional mail. It is not required for EmbedAuth. Publish these records with whichever DNS provider hosts your zone; the examples use Cloudflare, but the records themselves are provider-independent.

Four record types do four different jobs:

Without MX you receive nothing. Without SPF and DKIM your outgoing mail is unauthenticated and gets filtered as spam.

The records

Replace mail.yourdomain.com with your mail server's hostname and the DKIM values with the keys your mail server generates.

MX — the host that receives your mail. Lower priority number wins.

Type: MX    Name: @    Content: mail.yourdomain.com    Priority: 10

SPF — a TXT record at the domain root. mx authorises whatever your MX points at; -all means "reject anything else".

Type: TXT   Name: @    Content: v=spf1 mx -all

DKIM — a TXT record per signing key, named <selector>._domainkey. The selector and the key both come from your mail server; never invent them.

Type: TXT   Name: myselector._domainkey    Content: v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBg...

DMARC — a TXT record at _dmarc. Start at p=none while you confirm things work.

Type: TXT   Name: _dmarc   Content: v=DMARC1; p=none; rua=mailto:[email protected]

Make sure the address in rua= actually exists, or the daily reports bounce.

Traps that cost people hours

Only one SPF record is allowed. Two v=spf1 records on the same name is a protocol violation — receivers return permerror and SPF fails completely, which is worse than having no SPF at all. If you are adding a provider, merge it into the existing record with include:, never add a second one. The same rule applies to DMARC: one record at _dmarc, no exceptions.

A leftover MX can silently outrank yours. Priority is lowest-number-first. An old forwarding service sitting at priority 0 beats your new server at priority 10, and every message keeps going to the old provider while your DNS looks correct. List every MX record on the domain, not just the one you added.

Check where the MX actually points. An MX record naming a host that no longer resolves — or resolves to a decommissioned server — fails exactly like having no MX. Resolve the target to an IP and confirm something is listening on port 25 there.

No MX at all is not neutral. Senders fall back to your domain's A record. If that points at a web server or a CDN, every message bounces.

The mail host must not be proxied. If your DNS provider offers proxying (Cloudflare's orange cloud), the A record for your mail host has to be set to DNS-only. Proxying rewrites the address to the CDN, which speaks HTTP, not SMTP. MX and TXT records cannot be proxied at all.

The DKIM selector in DNS must match what your server signs with. If your server signs with selector abc and you publish xyz._domainkey, verification fails for every message. Send yourself a test message and read the DKIM-Signature header — the s= value is the selector that must exist in DNS, and d= is the domain it must exist under.

Delete DKIM records you no longer control. A stale selector left in DNS is a standing statement that whoever holds that private key may sign mail as your domain. It survives every other control you put in place, including p=reject.

A new record can look missing for half an hour. Resolvers cache negative answers for the zone's SOA minimum — commonly 1800 seconds. If you queried a name before creating it, your own machine keeps saying it does not exist long after it does. Check against a resolver that never saw the old answer before concluding something is wrong.

Verifying

dig +short MX yourdomain.com
dig +short TXT yourdomain.com          # SPF
dig +short TXT _dmarc.yourdomain.com
dig +short TXT myselector._domainkey.yourdomain.com

To bypass a stale local cache, query a public resolver directly:

curl -s 'https://dns.google/resolve?name=yourdomain.com&type=MX'

Then send a message to an account elsewhere — a personal Gmail address works — and inspect the headers. You want spf=pass, dkim=pass and dmarc=pass in Authentication-Results.

Tightening DMARC

Once SPF and DKIM pass consistently, move DMARC from p=none to p=quarantine, and later to p=reject.

Do it in that order. p=reject instructs receivers to bounce anything that fails authentication, and if some service you had forgotten about still sends as your domain — a newsletter tool, a CRM, an invoicing system — its mail stops being delivered the moment you switch. The rua reports tell you every source sending as your domain, so read a few days of them before tightening. Note also that plain forwarding breaks SPF, so mailing lists and .forward rules can fail under a strict policy.