Managing domains and DNS

SPF, DKIM, DMARC and MX — what verification actually checks.

Four record types matter, and they do different jobs. Publishing the wrong subset is the most common reason a domain will not verify.

Sending and receiving are separate

To send you need SPF and DKIM. To receive you need MX.

Mailyte tracks these separately — dns_verified for sending, mx_verified for receiving — and that separation is deliberate. Requiring MX before allowing sending locks out every customer who relays through us but keeps their mailboxes at Google or Microsoft, which is a large share of them. If that is you, publish SPF and DKIM and leave MX alone.

The records

curl "$MAILYTE_BASE/api/v1/domains/yourdomain.com/dns-records" \
  -H "Authorization: Bearer $MAILYTE_API_KEY"

SPF — a TXT record at the root saying which servers may send as you.

yourdomain.com.  TXT  "v=spf1 include:mailyte.com ~all"

You may have only one SPF record. If you already have one, merge the include: into it rather than adding a second — two SPF records is a permanent error, and most checkers report it as "no SPF" rather than "two", which sends people looking in the wrong place.

DKIM — a TXT record holding a public key, so receiving servers can verify a signature we add to every message.

mailyte._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

Long, and truncating it is a classic failure. Some DNS panels split long TXT values across quoted chunks; that is fine. Dropping the tail is not.

DMARC — tells receiving servers what to do when SPF and DKIM disagree with the From address, and where to send reports.

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Start at p=none, which changes nothing and only collects reports. Move to quarantine and then reject once the reports show your legitimate mail passing. Going straight to p=reject on a domain you have not measured is how a company discovers its invoicing system was sending as a domain nobody remembered.

MX — only if you want Mailyte to receive mail for this domain.

Verify

curl -X POST "$MAILYTE_BASE/api/v1/domains/yourdomain.com/verify" \
  -H "Authorization: Bearer $MAILYTE_API_KEY"

Safe to call repeatedly. A scheduled check runs anyway; this just asks now.

"But the record is correct"

Usually it is, and one of these is true:

Propagation. DNS is neither instant nor uniform. Your resolver and ours can disagree for minutes or hours. Wait, then check again.
The provider appended your domain. Many panels turn a host of mailyte._domainkey.yourdomain.com into mailyte._domainkey.yourdomain.com.yourdomain.com. Enter the host relative to the zone.
Multiple TXT records at the same name. Legal, and we read the whole set — but a stray old value alongside the right one can still fail DMARC alignment.
The value was truncated. Compare the tail of the published DKIM key against what we gave you, not just the start.

Create a mailbox before pointing MX

A provisioned domain with no mailboxes accepts mail and then has nowhere to put it. Create at least one mailbox before you cut MX over, or the gap is silent loss rather than a bounce the sender can see and act on.

Check what receiving servers see

dig +short TXT yourdomain.com
dig +short TXT mailyte._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX  yourdomain.com

Your own DNS panel shows what you asked for. dig shows what the world actually resolves — and when those two differ, the second one is the one that matters.

Provisioning mailboxes.