How to set up SPF, DKIM and DMARC for a new sending domain

A new sending domain has no history. Mailbox providers cannot tell your newsletter from a forged one, so they lean on three DNS records to decide: SPF, DKIM and DMARC. Get them right before the first campaign and most early deliverability trouble never shows up.

This guide covers what each record does, the order to publish them in, how to check that they work, and how to tighten DMARC step by step. We use the Mailnaptic Domains page for the examples, but the DNS side is the same with any sending platform.

Every domain name, selector and address below is a placeholder. Copy the real values from your own Domains page, not from this article.

What each record does

The three records answer three separate questions, and all of them live in DNS under your domain.

DMARC does not authenticate anything on its own. It looks at whether SPF or DKIM passed and whether the passing domain matches the visible From address, a test called alignment. That is why Mailnaptic's own guidance says to get SPF and DKIM passing first and add DMARC last.

The order to do things in

The sequence matters, mostly because DMARC is the one record that can do damage if it goes in too early.

Steps 1 to 4 are an hour of work plus some waiting for DNS. Steps 5 and 6 are spread over weeks, and that is on purpose.

The records, with placeholder values

When you add a domain, Mailnaptic lists the records to create. The shapes below match what you will see, using example.com in place of your domain.

SPF

SPF is a single TXT record on the root of the domain. If you already send from Google Workspace or Microsoft 365 you have one, and the right move is to add the Mailnaptic include to it, for example v=spf1 include:_spf.google.com include:spf.mailnaptic.com ~all. Two SPF records on one domain make SPF fail outright.

Two limits are worth knowing. SPF allows ten DNS lookups in total and every include counts toward that, so a domain with many services can go over without anyone noticing. And use ~all (soft fail) while you are setting up. Switch to -all once you are sure every legitimate sender is listed.

DKIM

DKIM is two CNAME records, one per selector. Mailnaptic uses two so keys can be rotated without a gap in signing. Create both, even if the second looks redundant.

Two gotchas come up again and again. Some DNS panels append your domain automatically, so typing the full name produces mn1._domainkey.example.com.example.com. If a record cannot be found, check that first. And if you use Cloudflare, set the DKIM records to DNS only (grey cloud) instead of proxied.

DMARC

DMARC is a TXT record at _dmarc on your domain. Start in monitoring mode. The rua address receives daily aggregate reports, so use a mailbox that exists and that someone will actually open.

Verify before you send

Publishing is half the job. A typo fails quietly, and you find out when mail starts landing in spam.

Open the domain in Mailnaptic and click Verify DNS. Each record gets a pass or fail. Then check from the outside, which tells you what the rest of the internet sees:

The domain list shows a health badge. Green means every record verified. Yellow means partial, such as SPF passing and DKIM missing. Red means nothing verified, or records that used to be valid no longer are. Mailnaptic will not let you send campaigns or activate automations from a domain until SPF and DKIM both verify.

Propagation takes minutes at most providers and up to 48 hours at slow ones. If verification fails right after you publish, wait and retry before you change anything.

Moving DMARC from none to reject

A policy of p=none tells receivers to deliver everything and send you reports. It protects nothing yet, but it shows you every server that sends mail as your domain, which is exactly what you need to know before you enforce anything.

In Mailnaptic, DMARC report monitoring (the DMARC Reports tab on the domain page) is available on Pro and above. It turns the daily XML into a table of pass and fail by source IP. Three things to look for:

Before quarantine, list every legitimate sender: staff mail, the support desk, the invoicing tool, the CRM. Each one needs to pass SPF or DKIM aligned with your domain, or it will start going to spam. The pct tag applies the policy to a share of failing mail, so a mistake costs you a fraction of the problem. Check reports weekly during setup, and monthly once you are at reject with clean results.

Common mistakes

Warm up the new domain

Authentication tells providers who you are. It does not tell them whether to trust you. A new domain that mails a whole list on day one looks like a spam operation, however clean its DNS.

Mailnaptic starts warmup with your first campaign and raises sending volume level by level. Each domain shows its current level and the next one. Your side is simple: send the first campaigns to your most engaged contacts, keep the content ordinary, and avoid a large import followed by an immediate blast.

The health score comes from bounce rate, complaint rate and open engagement. If it sags, slow down instead of pushing through the next level. Run the blacklist check on the domain page too. Mailnaptic checks major lists such as Spamhaus ZEN and SpamCop and alerts you when a new listing appears.