How To Set Up a New Domain: A Security-First Guide

Why Authentication Matters

New domains have no sending reputation. Authentication is the strongest verifiable signal a mailbox provider can evaluate when deciding whether to deliver, quarantine, or block a message. Without it, receiving servers have nothing to trust, and there’s nothing stopping someone else from sending in your domain’s name.

Two risks exist from the moment a domain is registered.

Delivery. Most mailbox providers evaluate SPF, DKIM, and DMARC on every inbound message. Unauthenticated messages are more likely to be filtered or rejected. Launching a domain without configuring authentication creates delivery problems that are difficult to recover from.

Security. An unprotected domain can be spoofed immediately. Cybercriminals actively target newly registered domains, knowing they’re likely unmonitored and unauthenticated. Spoofed emails sent in your domain’s name generate spam complaints that damage your sending reputation before you’ve sent a single legitimate message. That reputation damage is difficult to reverse.

Configure SPF, DKIM, and DMARC before sending begins, in the right sequence, with all sources accounted for. Done correctly, it protects delivery and reduces the risk of attackers exploiting the domain.

How To Set Up a New Domain

Step 1: Create an SPF Record

SPF authorizes which systems can send email on behalf of your domain. The record is published in the DNS and evaluated by receiving servers.

An example SPF record:

Each component does a specific job:

• v=spf1 specifies the version
• ip4: authorizes a specific IP address
• include: references the record of a different domain
• -all fails all senders not listed in the record

The most common mistake at setup is failing to include all sending services in the SPF record before the domain goes live. Teams that add marketing platforms, CRMs, helpdesk tools, or HR systems after launch – without updating SPF – cause authentication failures. Legitimate emails from those services can then land in the Spam folder or get rejected.

Audit every service that will send email from your domain before publishing the SPF record. That includes transactional email services and billing systems.

Step 2: Configure DKIM

DKIM adds a cryptographic signature to outbound messages. Receiving servers use the public key published in the DNS to verify the signature and confirm the message hasn’t been altered in transit. If the signature is valid, the message passes DKIM authentication.

DKIM works with a key pair. The private key is held by the sending service. The public key is published in DNS as a TXT record.

An example DKIM record:

Each sending service requires its own DKIM key pair. Google Workspace, Microsoft 365, marketing platforms, helpdesk tools, and any other service sending on your domain’s behalf must each have a separate key pair. All public keys must be published in DNS before sending begins.

Missing DKIM configuration for third-party senders is one of the most common authentication gaps in new domain setups.

Step 3: Publish a DMARC Record

DMARC ties SPF and DKIM together. It enforces alignment between the domain in the message header and the domain verified by SPF or DKIM, and it tells receiving servers what to do with messages that fail authentication.

DMARC has three policies:

• p=none – Monitor only. Messages are delivered regardless of authentication results. DMARC aggregate reports are generated and sent to the address specified in the rua
• p=quarantine – Messages that fail authentication are sent to Spam or Junk instead of the inbox.
• p=reject – Messages that fail authentication are blocked.

An example DMARC record:

Start at p=none to gather reporting data. The aggregate reports generated at this stage identify every source sending email from your domain, including services you may not be aware of. Use that data to validate your SPF and DKIM configuration before moving to enforcement.

p=none is a starting point, not a destination. Organizations that remain at p=none receive no protection from spoofing. Receiving servers deliver all messages – including spoofed ones – regardless of the authentication results.

Moving Your New Domain from p=none to p=reject

Reaching p=reject is what actually prevents spoofed email from being delivered. The progression from p=none to p=reject follows a defined sequence:

1. Analyze aggregate reports to identify every source sending email from the domain – authorized and unauthorized.
2. Fix authentication failures. Ensure that all legitimate senders are included in the SPF record and have DKIM keys published in the DNS.
3. Move to p=quarantine and monitor for a period before moving to full enforcement.
4. Advance to p=reject once all legitimate sources pass authentication consistently.

DMARC aggregate reports are delivered daily to the address in the rua tag. They show every sending source, authentication result, and policy outcome. Reading and acting on those reports is the operational task that moves a policy from monitoring to enforcement.

Many companies configure p=none and never advance the policy. Reports accumulate without review, authentication failures persist, and the domain remains exposed to spoofing. This is the default outcome when DMARC is treated as a checkbox.

Common Mistakes That Leave New Domains Exposed

• Publishing SPF without including all sending services. Any service that sends email on behalf of the domain must be listed in the SPF record. Marketing platforms, CRMs, billing systems, and ticketing tools added after launch without an SPF update can cause legitimate emails to fail authentication and land in Spam or get rejected.
• Failing to configure DKIM for third-party senders. Every platform that sends on your domain’s behalf needs its own DKIM key pair. A sending service without a published DKIM key will fail DMARC checks. This includes services often overlooked at setup, such as helpdesk platforms, HR tools, and automated notification systems.
• Setting DMARC to p=none and not reviewing reports. DMARC reports are only useful if someone reads them. Businesses that publish a DMARC record and don’t review the resulting reports can’t identify misconfigurations or unauthorized senders, and the policy never advances to p=reject.
• Failing to standardize authentication across all domains. Enterprises with multiple domains – from acquisitions or regional expansion – often configure authentication controls on primary domains and leave secondary domains unprotected. Attackers target secondary domains precisely because they’re less likely to be monitored.

How Sendmarc Helps You Set Up a New Domain

Configuring authentication controls manually on a single new domain is manageable. Maintaining it across many domains – including new ones added by various business units over time – is a far more complex challenge.

SPF records break when teams add sending tools without authorization. DKIM keys expire. DMARC policies stall at p=none. These aren’t edge cases. They are the default outcome when authentication is treated as a one-time setup task and not an ongoing operation.

Sendmarc provides unified visibility into authentication status across all domains. Sendmarc helps you identify unauthorized senders, surface misconfigurations, and move from p=none to p=reject.

For enterprises growing through acquisitions or regional expansion, every new domain is a potential gap. Sendmarc closes those gaps at setup and maintains enforcement as the environment grows – without increasing the burden on already-stretched security and IT teams.

See how Sendmarc manages email authentication across every domain, at enterprise scale.