Defaults.Exposed › Pembaikan › Guides

Setting Up Email on a New Domain: The 20-Minute SPF, DKIM and DMARC Checklist (2026)

Diterbitkan 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

A new domain needs four things before its first email: a baseline scan, one SPF record naming your real provider, custom-domain DKIM signing, and a DMARC record with reporting on from day one. Most domains never get there — 46.4% (121,145,609 of 261,086,232 graded domains) have no SPF at all, according to the Defaults.Exposed census (as of 2026-06-29).

Publishing everything takes about 20 minutes: scan for a baseline, add one SPF record, turn on your provider’s custom-domain DKIM, publish DMARC p=none with a reporting address, optionally add MTA-STS, then re-scan and keep the report. What takes longer is what no checklist can rush — DNS propagation and sending reputation — and this guide is honest about both.

Is 20 minutes really enough?

For publishing the records, yes — every step below is a DNS entry plus a couple of clicks in your provider’s admin console. Two things take longer, and pretending otherwise is how new domains end up in spam:

• Propagation. New records usually resolve within minutes, but resolvers cache per the TTL and a freshly delegated domain can take hours to answer consistently. Verify with dig; don’t panic-edit while caches catch up.
• Warm-up. A new domain has zero sending reputation, and authentication is the precondition for reputation, not a substitute. Start with low, human-scale volume and ramp gradually over weeks.

The honest claim: 20 minutes buys correctly published authentication. The next few weeks of sensible sending buy deliverability.

The 20-minute checklist

1. Run the free scan at defaults.exposed first. Scan the new domain before you touch DNS. The graded “nothing configured” baseline takes seconds to capture and makes the after-report meaningful — you’ll want the before-and-after pair (step 6).
2. Publish one SPF record for your actual provider. Exactly one TXT record starting v=spf1, containing your provider’s include — for example v=spf1 include:_spf.google.com ~all for Google Workspace, or include:spf.protection.outlook.com for Microsoft 365; if your DNS lives at a registrar panel, the GoDaddy walkthrough covers the UI quirks. One record only: two v=spf1 records are a permanent error that voids SPF entirely — the state 1,013,416 domains are stuck in, roughly one in 138 of the domains that attempt SPF (census as of 2026-06-29), usually a migration leftover. Don’t add includes “just in case”: SPF caps DNS lookups at 10, and at least 797,263 domains have voided their record by blowing that cap. And know what SPF actually checks: receivers evaluate it against the Return-Path (RFC5321.MailFrom) domain — the bounce address — not the From header your recipients see.
3. Turn on custom-domain DKIM signing. Your provider signs mail either way; the question is which domain the signature names. Until you complete this step, Google Workspace signs with its gappssmtp.com default and Microsoft 365 with onmicrosoft.com — signatures that pass DKIM but don’t align with your domain, so DMARC still fails. Generate the key in the admin console and publish what the provider gives you: a 2048-bit TXT record for Google, two CNAMEs (selector1/selector2) for Microsoft 365. If a record won’t fit your DNS panel, see fix DKIM — long keys mangled by UIs are a classic.
4. Publish DMARC from day one — p=none with a reporting address. One TXT record at _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:[email protected]. Be clear about what this does: p=none protects nothing yet — it’s monitoring mode. But it costs nothing, and aggregate reports then cover your domain’s sending history from the very first message. Established domains spend weeks of reporting just discovering senders they forgot they had; you’re buying that visibility for free, from day zero. See fix DMARC for the record anatomy.
5. Optional but cheap on a new domain: MTA-STS and TLS-RPT. MTA-STS tells sending servers your domain requires TLS for inbound mail (a DNS record plus a small hosted policy file); TLS-RPT reports delivery-encryption failures. On an established domain these need care; on a new domain with one mail provider there’s nothing to break, and mode: testing is essentially risk-free. Set them up now or skip them — but decide, don’t drift.
6. Re-scan and keep the report. Run the scan again — SPF, DKIM and DMARC should all show green. Save the graded report: dated evidence of the domain’s state at launch, and exactly what an insurer or client questionnaire will ask for.

How many domains actually complete this checklist?

Very few — and most fall at the first hurdle. Of the 261,086,232 domains graded in the Defaults.Exposed census (as of 2026-06-29):

The 20 minutes this page describes puts a brand-new domain ahead of roughly 96% of the internet on the full triad. The SPF adoption maturity model breaks down every rung of that ladder.

How fast can a new domain reach p=reject?

Weeks, not months — the genuine advantage of starting fresh. What makes DMARC enforcement slow on established domains is legacy: the forgotten CRM connector, the invoicing tool someone wired up in 2019, the newsletter platform nobody documented. Each has to be found in the reports and fixed before the policy can tighten — hence the standard months-long rollout.

A new domain has no legacy senders: you configured every sending source yourself, this week, and step 4’s reports will confirm it. Run p=none for two to four weeks of real sending, check the reports cover everything you actually use (mailboxes, invoices, receipts, the website’s contact form), then move to p=quarantine and on to p=reject once they run clean. The staged mechanics — pct ramps, subdomain policy, what to watch — are in from p=none to p=reject; on a new domain you’ll move through them at speed, to a place only 10.59% of graded domains have reached.

What about the old domain you’re replacing?

If this new domain is part of a rebrand, the domain you’re leaving behind is now your biggest email risk: still yours, still trusted by counterparties, no longer watched. Don’t abandon it — lock it down explicitly. That’s its own short job: that old domain from your rebrand is a door you left open.

Frequently asked questions

Can I publish these records before choosing a mail provider? DMARC, yes — p=none with rua is provider-independent, so publish it the day you register. SPF needs your provider’s include; until you’ve picked one, publish v=spf1 -all (nothing is authorised to send) and replace it in step 2. That’s strictly better than the no-record state 121,145,609 domains sit in (46.4% of 261,086,232 graded, as of 2026-06-29).

Do I need DKIM if SPF already passes? Yes. SPF breaks under forwarding by design, and it validates the Return-Path domain, which for many tools isn’t yours — aligned DKIM is the leg that survives both. Only 3.87% of graded domains complete the full SPF+DKIM+enforced-DMARC triad (census as of 2026-06-29); DKIM is the step most quitters skip. Start at fix DKIM if the scan flags it.

Should a new domain use ~all or -all? On an established domain, ~all is the cautious choice while you find forgotten senders. A new domain has none to find: once your provider’s include is in and DKIM is signing, -all is safe far sooner. Want belt and braces? Confirm with two clean weeks of DMARC reports first.

All three records pass — why is my mail still going to spam? Because authentication and reputation are different things: passing records mean receivers can verify the mail is yours, not that they trust you yet. New domains earn trust by sending consistent, wanted, low-volume mail and ramping gradually. If mail is failing checks rather than just landing in spam, start at fix SPF and work down the scan results.

Send the owner the report

If you’re setting this domain up for a client, close the job with evidence. Re-run the free scan after step 6 and forward the graded report to the business owner: SPF, DKIM and DMARC passing, in plain language, dated at launch. It’s the artefact they’ll need for the cyber-insurance renewal and the next supplier security questionnaire — and it proves the domain started life the way 96% of the internet never manages.

Check your domain → · From p=none to p=reject without losing legitimate email → · Aggregate data only. Data stored and processed in the EU.