SPF, DKIM, and DMARC for a New Business Domain

SPF, DKIM, and DMARC for a New Business Domain

Three DNS records separate a trustworthy sending domain from one that lands in spam from day one. SPF authorizes the servers allowed to send as your domain. DKIM adds a cryptographic signature that receiving servers verify. DMARC ties both together and tells inbox providers what to do when a message fails either check.

Set all three up when you register the domain. Retrofit is possible and worth doing, but starting clean is faster than fixing a reputation built on unsigned mail.

Verified against Google Workspace Admin Help and Microsoft Learn email authentication documentation on 2026-05-12.

Before You Start

Three things need to be in place:

  1. Access to your domain's DNS settings (your registrar, Cloudflare, or wherever you manage DNS records)
  2. Admin access to your email provider (Google Workspace or Microsoft 365)
  3. A mailbox to receive DMARC aggregate reports; any address on the domain works, though a dedicated alias like dmarc-reports@yourdomain.com keeps the inbox clean

Budget 30 to 45 minutes for the full setup. DNS propagation can take up to 48 hours after you publish the records, but the steps themselves are quick.

Step 1: Add the SPF Record

How ScaleIT handles this: See how compliance works

SPF (Sender Policy Framework) is a TXT record on the root of your domain that lists which mail servers are authorized to send on your behalf. A receiving server that sees mail from you@example.com checks your SPF record before deciding whether to deliver it.

Google Workspace:

@    TXT    "v=spf1 include:_spf.google.com ~all"

Microsoft 365:

@    TXT    "v=spf1 include:spf.protection.outlook.com -all"

The ~all (softfail) and -all (hard fail) at the end tell receivers what to do with mail from servers not on your list. Microsoft recommends -all for their setup. If you send from other services (a CRM, a marketing tool, or a transactional email provider), add their include: clause to the same SPF record before you publish it. SPF allows exactly one TXT record per domain.

Step 2: Generate and Publish the DKIM Key

DKIM (DomainKeys Identified Mail) uses a public/private key pair. Your mail provider signs outbound messages with the private key. The public key lives as a TXT record in your DNS, and receiving servers use it to verify the signature.

Google Workspace:

  1. In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
  2. Select your domain from the Selected domain menu.
  3. Click Generate new record. Use the default 2048-bit key length and the default selector prefix google.
  4. Copy the TXT record value shown on screen.
  5. In your DNS panel, create a TXT record with the host google._domainkey and paste the key value.
  6. Back in the Admin console, click Start authentication. DKIM signing can take up to 48 hours to activate.

Microsoft 365:

Microsoft 365 uses CNAME records for DKIM, not TXT. The admin portal generates the two values you need.

  1. Go to the Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
  2. Select your domain. The portal displays two CNAME host/value pairs.
  3. Add both CNAME records in your DNS panel. The host values follow the pattern selector1._domainkey and selector2._domainkey.
  4. Once DNS propagation is complete (typically a few hours), return to the DKIM tab and enable DKIM signing for your domain.

Step 3: Add the DMARC Record

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at the _dmarc subdomain. It tells receiving servers what to do when a message fails SPF or DKIM, and where to send aggregate reports about authentication results.

Start with p=none (monitor only). This lets you collect reports on what is actually sending mail as your domain before you commit to quarantining or rejecting failures.

_dmarc    TXT    "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Replace dmarc-reports@yourdomain.com with a real mailbox on your domain. Reports arrive as daily XML digests from Gmail, Outlook, Yahoo, and most major providers. Free tools like MXToolbox DMARC Analyzer parse them into readable summaries.

After two to four weeks of monitoring with p=none, once you can confirm your legitimate mail is passing SPF and DKIM, upgrade to p=quarantine (sends failures to spam), then to p=reject (blocks failures outright).

Step 4: Register the Domain in Google Postmaster Tools

Google Postmaster Tools gives you a free visibility window into how Gmail treats your domain: spam rate, authentication pass rate, IP reputation, and delivery errors.

  1. Go to postmaster.google.com and sign in with a Google account.
  2. Click + (Add domain) and enter your domain.
  3. Verify ownership by adding the provided TXT record to your DNS.
  4. Once verified, the dashboard populates within 24 to 48 hours of your first sends.

Postmaster Tools is the fastest way to catch authentication problems early, before they affect deliverability at scale.

Verify

Once the records are live and propagated, check each one:

Troubleshooting

SPF returns "softfail" or "fail" for mail you sent: A sending service (a CRM, marketing tool, or transactional email provider) is not listed in your SPF record. Identify the service, find their SPF include: value in their docs, and add it to your SPF TXT record before the ~all or -all clause.

DKIM record not found: The DNS record has not propagated yet, or the host name in DNS is wrong. Double-check that the host value in your DNS panel is correct for your registrar's format. Some registrars expect just google._domainkey; others want the full google._domainkey.yourdomain.com. Check your registrar's documentation for which format they expect, since entering the full hostname when they auto-append the domain will produce a doubled entry that fails the lookup.

DMARC reports show a high failure rate even after SPF and DKIM are set up: DMARC requires alignment. The domain in the From: header must match the domain used in SPF or DKIM validation. If a third-party sending platform is signing with their own domain rather than yours, the alignment check fails even though DKIM itself passes. Fix this by configuring the sending platform to sign with your domain as the DKIM signing domain, or ensuring the Return-Path domain matches your domain for SPF alignment.

"Start authentication" button not available in Google Workspace: Google requires 24 to 72 hours after Gmail is provisioned on a new domain before the DKIM key generation option is available. Wait and retry.

Next Step

Email authentication takes an afternoon if you know the steps. If you would rather have someone handle the DNS setup, verify the records, and confirm your sending reputation is clean from day one, ScaleIt handles this as part of standard IT setup for new and growing businesses. Book a free call and we will scope it.

Q: What is the difference between SPF, DKIM, and DMARC: do I need all three?

SPF alone tells receivers who is allowed to send. DKIM alone verifies the message was not altered in transit. DMARC tells receivers what to do when either check fails and gives you visibility through reports. All three together are what the major inbox providers (Google, Microsoft, Yahoo) require for high-volume sending, and what they recommend for any business domain. SPF alone leaves you half-protected.

*Q: What do the DMARC policy values p=none, p=quarantine, and p=reject actually do?*

p=none monitors without taking action. Failing mail is delivered normally, and you only see the problem in your DMARC reports. p=quarantine routes failing mail to the recipient's spam folder. p=reject blocks it entirely before delivery. Start at p=none, review reports for two to four weeks, then move to p=quarantine, then p=reject once you are confident all legitimate sending is authenticated.

Q: Can I have multiple SPF records on the same domain?

No. SPF requires exactly one TXT record on the root hostname. A second SPF record causes both SPF and DMARC checks to fail. If you send from multiple services, combine all their include: clauses into a single SPF record: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Q: How often do DMARC reports arrive, and what should I do with them?

Aggregate reports (rua) arrive once a day from participating receivers. Forensic reports (ruf) arrive per failing message, but most providers no longer send them for privacy reasons. For most SMBs, the free tier of a DMARC report parser (MXToolbox, Dmarcian, or Google Postmaster Tools) that turns the raw XML into a readable summary. Watch for unauthorized senders appearing, domains failing alignment, and your overall pass rate.

Q: Does this apply to transactional email from tools like SendGrid, Mailgun, or Resend?

Yes. Any service that sends email "from" your domain needs to be either included in your SPF record or configured to sign with your DKIM key, or both. Most transactional email providers have a domain authentication guide in their docs that walks you through publishing their DKIM key and adding their SPF include: value. Complete this before sending production traffic.

Q: Will setting up DMARC break any existing email?

Starting with p=none is safe. It monitors without touching delivery. The risk comes from moving straight to p=reject before you have verified all your legitimate senders are authenticating correctly. Use the report data from p=none first. If you inherit a domain that has been sending for months without authentication, two to four weeks of monitoring usually surfaces every sending service you need to account for.

Verified against Google Workspace Admin Help (support.google.com/a/answer/174124, support.google.com/a/answer/33786, support.google.com/a/answer/2466580) and Microsoft Learn email authentication documentation (learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure, learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) on 2026-05-12.