Which DNS records a sending domain needs

The complete list of records for a sending domain, which are required, which are optional, and where each one goes.

The full list

Everything below explains what each one is for. The deep detail on the first three lives in their own guides.

SPF, required

One TXT record on the root of your domain listing who may send for it. Exactly one, merged if you already have another provider. Full detail in the SPF guide.

DKIM, required

One TXT record holding your public signing key, at a selector host under _domainkey. This is the record that keeps authenticating when your mail is forwarded. Full detail in the DKIM guide.

DMARC, recommended

One TXT record at _dmarc telling receivers what to do when authentication fails, and where to send reports. Without it, SPF and DKIM do not protect the From: address your recipients see. Full detail in the DMARC guide.

Bounce return-path, optional

A CNAME at bounces.yourdomain.com pointing at the platform. It moves the envelope sender onto your own domain, which means bounce handling looks like it comes from you and SPF aligns on your domain rather than the platform’s. Useful, not required.

Tracking links, optional

A CNAME at links.yourdomain.com. Click tracking rewrites links, and without this record they point at the platform’s redirect host. With it, recipients see your domain in the URL. This is about brand and trust, not deliverability.

MX, only for receiving

MX records tell the world where to deliver mail addressed to your domain. Sending does not use them. You can send from a domain with no MX record at all. It is still a poor experience, since replies go nowhere, and some filters treat a missing MX as a mild negative signal.

Root domain or subdomain?

You can send from yourdomain.com directly, or from a subdomain like mail.yourdomain.com. Two things to know:

• SPF and DKIM do not inherit. A subdomain sender needs its own records. The root domain’s SPF does not cover mail.yourdomain.com.
• DMARC does inherit, through the organizational domain and the sp= tag, so a policy on the root applies to subdomains unless you override it.

Sending from a subdomain isolates reputation, which is worth it when different kinds of mail leave your organization. It is not necessary for a single transactional stream.

If a domain never sends mail at all, publish v=spf1 -all and a DMARC record with p=reject on it. That prevents impersonation of a domain nobody is watching.

In Mailverick

Add a domain in the Domains section of the portal and every record above is generated for you with the exact values, walked through in Getting Started. Check DNS validates them and reports a per-record status of valid, warning, invalid, or absent, showing what it found against what it expected.

SPF and DKIM must both be valid before the domain can send. DMARC and the two CNAMEs can be added later at any point.

Common mistakes

Entering the host name wrong. Providers differ: some want @ for the root, some want the bare domain, and some append the zone to whatever you type. Entering a full name in an interface that appends produces _dmarc.yourdomain.com.yourdomain.com. Read the record back after saving.

Creating the wrong record type. SPF, DKIM, and DMARC are all TXT. The bounce and tracking records are CNAME. A DKIM key created as a CNAME will never verify.

Publishing two SPF records. Adding a second one is a permanent error that invalidates both. Merge instead.

Assuming a subdomain is covered. The most common cause of a sudden authentication failure after someone switches the From: address to a subdomain.

Waiting on the wrong thing. DNS changes propagate as caches expire, governed by the record’s TTL. If you are checking within seconds of saving, you are testing your resolver’s cache and not your zone.

FAQ

Do I need an MX record to send email?

No. MX is only for receiving. Adding one is still sensible so replies do not vanish.

Can I use the same domain for transactional and marketing mail?

You can, but reputation is shared, so a campaign that draws complaints damages your password resets. Separate subdomains are the usual answer. See transactional vs marketing email.

What about PTR and reverse DNS?

That record belongs to whoever owns the sending IP, so on Mailverick it is ours to maintain, not yours. It matters, and you do not have to do anything about it.

What about BIMI?

BIMI displays your logo in supporting inboxes, and it requires DMARC at quarantine or reject plus a Verified Mark Certificate. Get authentication right first; BIMI is the last step, not an early one.

How long until records are recognized?

Usually minutes, occasionally a few hours. Lower a record’s TTL before a planned change if you want faster switching.

Last updated: April 2026