Set up SPF, DKIM and DMARC on a new domain

A new domain needs three DNS records before it sends its first message: one SPF record naming the provider that will send for it, DKIM signing turned on for your own domain in that provider’s console, and a DMARC record at p=none with a rua address so the reports start on day one.

Publishing all three is about 20 minutes of work in one sitting, and a freshly registered domain is the easiest place you’ll ever do it, because there are no old senders to discover and nothing in production to break. The 20 minutes covers publishing, though. Two things take longer and no checklist can hurry them: resolvers caching your records at their own pace, and receivers deciding whether to trust a domain with no sending history. Both are covered below, with what to expect at each step.

Scan it before you touch DNS

Run the free scan on the new domain first, before you add anything. It takes seconds and it captures the graded “nothing configured” state, which is what makes the after-report worth keeping. If you’re doing this for a client, the before-and-after pair is the evidence you hand back at the end.

Do this even if you’ve already picked a provider and have the records ready. The baseline costs nothing and you can’t recreate it once the first record is live.

One SPF record, naming the provider that sends

SPF is a single TXT record at the apex of the domain, starting v=spf1, that lists who may send mail using your domain as the bounce address. For Google Workspace the record is v=spf1 include:_spf.google.com ~all. For Microsoft 365 the include is include:spf.protection.outlook.com. Paste your provider’s line and nothing else.

One record only. Two TXT records that both start v=spf1 are a permanent error, and a domain in that state has voided its SPF entirely. That usually happens later, when someone adds a second record during a migration instead of editing the first, so it’s worth knowing on the day you publish the first one.

Resist adding includes for services you might use one day. SPF caps the DNS lookups a record may trigger at 10, and each include: spends at least one. A record padded with extra providers in case something else sends can blow the cap and void itself. Add a sender when it starts sending.

Know what SPF checks. Receivers evaluate it against the Return-Path domain (RFC5321.MailFrom), the bounce address, and the From header your recipients see plays no part. For your own mailboxes those two domains match. For many third-party tools they don’t, which is one reason DKIM comes next rather than being optional. The SPF page covers the record syntax and the qualifiers in full.

Expect the new TXT record to be visible at public resolvers within minutes. Anything that looked the domain up before you published will hold its cached “no record” answer for the length of your TTL, and on a domain delegated this week the nameservers themselves can answer inconsistently for a few hours. Check with a lookup tool rather than editing the record again while the caches catch up.

DKIM that puts your domain in the signature

Your provider signs outgoing mail whether or not you do anything. The question is which domain the signature names. Until custom-domain DKIM is on, Google Workspace signs with its gappssmtp.com default and Microsoft 365 with onmicrosoft.com. Those signatures pass DKIM and fail DMARC alignment, because the signing domain isn’t yours, so DMARC has nothing to align with.

Generate the key in the provider’s admin console and publish exactly what it gives you. For Google Workspace that’s a 2048-bit public key in a TXT record. For Microsoft 365 it’s two CNAME records, selector1 and selector2, pointing at the hosted keys. Then go back to the console and turn signing on; both consoles look for the record before they’ll enable it.

The usual failure at this step is the DNS panel rather than the key. Some registrar panels won’t take a TXT value as long as a 2048-bit key, and either truncate it or split it wrongly, which leaves a record that looks published and never verifies. If the console still can’t see the record after the propagation window, that’s where to look first; the DKIM page walks through the panel workarounds.

The record itself resolves in minutes, the same as SPF. Signing starts when the console has verified the record and you’ve enabled it, and Google Workspace’s own guidance allows up to 48 hours for signing to begin once it’s switched on, so publish DKIM early in the session rather than last.

Do you still need DKIM if SPF already passes? Yes. SPF breaks under forwarding by design, because the forwarding server becomes the sender, and it validates the Return-Path domain, which for a lot of tools isn’t your domain at all. Aligned DKIM is the leg that survives both.

DMARC at p=none with a rua address, on registration day

One TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:[email protected]. Make sure the mailbox in the rua address exists; receivers send aggregate reports there, usually once a day, as XML attachments.

p=none is monitoring. It protects nothing and tells receivers to change nothing. What it does is switch on the reports, so from the first message the domain ever sends you have a record of each source that used its name and whether SPF and DKIM aligned. Established domains spend weeks at p=none discovering senders they’d forgotten they had; on a new domain the same reports confirm a list you wrote yourself this week.

The record is provider-independent, so it can go up on the day you register, before you’ve chosen where mail will live. SPF can wait for the provider decision; if you want something in place meanwhile, v=spf1 -all states that nothing is authorised to send yet and gets replaced when the provider is picked.

Most domains that reach p=none stop there and collect nothing. In the September 2026 census, 33,651,068 (80.33% of p_none) of the 41,888,985 domains at p=none carry no rua address at all. A new domain that publishes rua on day one gets its whole sending history in the reports, for the cost of one mailbox.

The DMARC record resolves in minutes. The first aggregate report normally arrives within a day or two of the first message a large receiver sees from the domain, and reports keep arriving daily from then on.

MTA-STS and TLS-RPT while there’s nothing to break

MTA-STS tells sending servers your domain requires TLS for inbound mail. It’s a DNS record plus a small policy file hosted at https://mta-sts.yourdomain.com. TLS-RPT is a second DNS record that asks receivers to report delivery-encryption failures to an address you name.

On an established domain both need care, because a mistaken policy can affect inbound mail. On a new domain with one mail provider there’s nothing yet to affect, and mode: testing reports problems without enforcing anything. Set them up now while the domain is quiet, or leave them out deliberately. The failure mode is drifting into “later” and finding, a year on, that later never came.

The DNS records resolve in minutes. Sending servers fetch the policy file on their own schedule and cache it for the max_age the file declares, so a change to the policy takes effect over hours to days rather than at once.

If the new domain replaces an old one

When the new domain is part of a rebrand, the domain you’re leaving behind becomes the bigger risk of the two. It’s still yours, still trusted by counterparties who’ve mailed it for years, and from now on nobody is watching it. Left as it is, its name can be put on invoices and password resets while your attention is on the launch.

Locking it down is its own short job: an SPF record that authorises no sender, DKIM keys removed, DMARC at p=reject. It takes less time than the setup above, and parked domains can be spoofed walks through it record by record.

Weeks to p=reject, then the report you hand back

Publishing the records gives the domain authentication. Reputation is separate, and a new domain has none. Receivers watch what a domain sends over time, and passing SPF, DKIM and DMARC means they can verify the mail is yours, which is a different thing from trusting it. Start with low, human-scale volume and ramp over weeks; authentication is the precondition for building reputation, and it can’t substitute for the sending.

Enforcement is weeks away on a new domain. What drags DMARC rollouts out on established domains is legacy senders nobody remembers wiring up: the CRM connector, the invoicing tool, the newsletter platform, each of which has to be found in the reports and fixed before the policy can tighten. A domain registered last week has none of those.

Run p=none through two to four weeks of real sending, confirm the reports cover everything in real use (mailboxes, invoices, receipts, the website’s contact form), then move to p=quarantine, then p=reject once the reports run clean.

The same logic settles ~all against -all. On an established domain ~all is the cautious choice while forgotten senders surface. On a new domain there are none, so once the provider’s include is in and DKIM is signing, -all is safe far sooner; two clean weeks of reports is enough to confirm it.

When the records are answering, re-scan the domain and keep the dated, graded report next to the baseline you took first. If you set this up for a client, that pair is the handover: the domain’s state at launch, in plain language, which is what the next supplier questionnaire or cyber-insurance renewal asks for.

It also puts the domain in thin company. Of the 316,600,902 domains carrying a grade in the September 2026 census, 7,862,126 complete the full triad of SPF, DKIM and enforcing DMARC. Twenty minutes of DNS on registration day, and a few weeks of patience, is what it takes to be one of them.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.