SPF, DKIM, and DMARC Setup Guide for Google Workspace, Microsoft 365, and Custom Domains

Overview

If you manage a domain that sends email, SPF, DKIM, and DMARC setup should be treated as core infrastructure, not an optional hardening step. These records help receiving mail systems decide whether a message is authorized, whether it was modified in transit, and what to do when authentication fails.

The practical model is simple:

• SPF lists which servers or services are allowed to send mail for your domain.
• DKIM adds a cryptographic signature to outgoing mail so recipients can verify the message came from an approved sender and was not altered.
• DMARC defines policy and reporting for messages that fail alignment checks based on SPF and DKIM.

Together, these records improve deliverability, reduce spoofing risk, and make email behavior easier to audit when multiple systems send on behalf of the same domain.

Before making changes, keep four operating assumptions in mind:

1. Your domain’s DNS zone is under your control or your team can coordinate quickly with whoever manages it.
2. You know every platform that sends mail using your domain, including marketing tools, support systems, and internal automation.
3. You are prepared to wait for DNS propagation and verify records from outside your local resolver cache.
4. You will review the vendor documentation for exact hostnames and selectors before publishing changes, because provider values can change over time.

If you need help with DNS record basics before editing TXT, CNAME, or MX entries, see Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types. After publishing changes, use a workflow like the one in DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays to confirm that new records are visible publicly.

A final naming note: exact DNS hostnames vary by provider and DNS UI. Some dashboards expect the root domain to be entered as @, some as blank, and some auto-append the zone name. Treat the examples below as patterns to verify, not values to copy blindly.

Checklist by scenario

Use this section as your working checklist. The goal is not just to “add the records,” but to make sure the right systems are authorized and the wrong systems are not.

Scenario 1: New domain using Google Workspace for primary email

This is a common baseline for startups, internal teams, and product organizations using Google Workspace for human-to-human mail.

1. Confirm your outbound scope. Decide whether only Google Workspace users send email, or whether transactional and marketing services also send from the same domain.
2. Publish or verify the SPF record. Your SPF record should authorize Google Workspace mail servers. If no other service sends mail for the domain, keep the record minimal. If you later add another sender, update the same SPF record rather than publishing a second one.
3. Enable DKIM in the Google admin interface. Generate the DKIM key, note the selector, and publish the required DNS record in your zone. Once the DNS record is live, return to the Google admin side and activate signing.
4. Add a DMARC record. Start with a monitoring-oriented policy if you have not audited all senders yet. Set reporting addresses that your team actually monitors.
5. Verify alignment. Send test messages to external mailboxes and inspect headers to confirm SPF and DKIM pass using your domain, not just the provider domain.
6. Document the selector and owner. Record where DKIM was generated and who owns the admin access, so key rotation does not become a future outage.

If you are specifically handling a Google Workspace DMARC setup, the key operational point is sequencing: publish SPF and DKIM first, observe reports, then move DMARC policy toward stricter enforcement once you know legitimate sources are covered.

Scenario 2: New domain using Microsoft 365 for primary email

Microsoft 365 introduces the same concepts with slightly different management flows.

1. Verify domain onboarding is complete. Make sure the domain is fully added and validated in Microsoft 365 before troubleshooting outbound authentication.
2. Publish the Microsoft 365 SPF record. Ensure the root domain has a single SPF TXT record that includes Microsoft 365 authorization. Do not create multiple SPF records for separate vendors.
3. Enable DKIM for the domain. Microsoft 365 often requires DNS records before DKIM can be switched on in the admin interface. Add the required selectors exactly as instructed.
4. Add DMARC at the organizational domain. Start with a policy level appropriate to your current inventory of senders and monitoring maturity.
5. Test from user mailboxes and shared systems. Messages sent from individual users may pass while a legacy workflow or app relay still fails. Test both.
6. Check for inherited or legacy settings. Older tenants sometimes have relay paths, third-party gateways, or retired systems that still send using the domain.

For teams searching specifically for a microsoft 365 spf record, the most important rule is that SPF must remain singular at the DNS level. One domain, one SPF record, even when several services send mail.

Scenario 3: Custom domain with multiple senders

This is the most error-prone setup. Your primary mailbox provider may be Google Workspace or Microsoft 365, but the domain may also be used by a billing platform, CRM, ticketing system, CI notifications, marketing platform, or product email service.

1. Inventory every sender. List all systems that send mail with your domain in the visible From address or envelope sender.
2. Consolidate SPF includes carefully. Merge authorized senders into a single SPF record. Keep it readable and review whether any include is obsolete.
3. Enable DKIM per provider. DKIM is not “global” in practice. Each sending platform may require its own selector and DNS record.
4. Use subdomains when useful. Many teams reduce complexity by sending product email from a subdomain such as notify.example.com and marketing mail from mail.example.com, while keeping employee mail on the root domain.
5. Publish DMARC where mail is actually sent. Apply policy deliberately across the organizational domain and any active subdomains.
6. Review return-path and alignment behavior. Some services pass SPF against their own bounce domain while failing alignment for your visible From domain. DKIM often becomes the more stable path here.

If you manage email authentication DNS for more than one sender, subdomain separation is often the cleanest long-term decision. It simplifies DMARC policy, narrows blast radius, and makes provider changes easier.

Scenario 4: Migrating from one provider to another

Migrations create temporary overlap, which is exactly when email authentication breaks.

1. Keep both providers authorized during transition. If users or systems are still sending from the old platform, keep that authorization in place until cutover is complete.
2. Enable DKIM on the new provider before switching traffic. Do not wait until after migration to publish DKIM records.
3. Lower TTL before planned DNS changes. If your DNS provider allows it, reducing TTL ahead of time can make controlled updates less painful.
4. Watch DMARC reports during overlap. They can reveal messages still originating from the old provider or from forgotten systems.
5. Remove old includes and selectors after validation. Cleanup matters. Leaving old records in place increases confusion and can widen your authorized sending surface unnecessarily.

Scenario 5: Transactional email only on a product or app domain

For engineering teams running app-generated mail, the recommended pattern is usually distinct from employee mail.

1. Prefer a dedicated subdomain. Use something like tx.example.com or notify.example.com for app mail.
2. Publish only the provider-specific SPF authorization needed for that subdomain.
3. Add the provider’s DKIM DNS records. Many platforms require two CNAME records or one TXT record per selector.
4. Add DMARC for the subdomain if it sends visible mail.
5. Test production headers from the application, not only sandbox mode.
6. Version-control your DNS intent. If your team uses infrastructure as code, codify records so service rotation is repeatable.

This is where dns automation pays off. If you use a provider API or terraform dns records, you can keep email authentication changes reviewable, auditable, and easier to roll back.

What to double-check

Once records are published, do not stop at “the DNS entry exists.” Most delivery problems come from records that are present but ineffective.

• Only one SPF record exists per hostname. Multiple SPF TXT records usually cause evaluation problems.
• The SPF syntax is valid. Watch for missing spaces, malformed mechanisms, or trailing fragments copied from vendor docs.
• The record is published at the correct host. Root-domain SPF and subdomain SPF are not interchangeable.
• DKIM selectors match exactly. A selector typo is enough to make signatures fail.
• DKIM is enabled on the provider side. Publishing the DNS record alone is not always enough; many providers require a separate “enable signing” step.
• DMARC is at _dmarc.yourdomain. This is one of the most common host-name mistakes.
• Reporting mailboxes are valid. If you use DMARC reports, ensure the addresses can receive mail and are monitored.
• Alignment is passing. SPF may technically pass for a provider-controlled envelope sender while DMARC still fails if alignment with your visible From domain is missing.
• DNS propagation is complete. Public resolvers can lag. Check more than one location before assuming the provider is broken.
• Old records were removed deliberately. Audit for stale selectors, previous includes, and deprecated subdomains.

For post-change validation, a lightweight checklist works well:

1. Query the TXT or CNAME records directly from public DNS.
2. Send a real message to at least two external mailbox providers.
3. Inspect authentication results in message headers.
4. Compare the passing domain in SPF and DKIM with the visible From domain.
5. Review DMARC aggregate reports if enabled.

If records are visible in your DNS dashboard but not in public lookups, work through a dns propagation check before changing configuration again. Repeated edits during propagation often make debugging harder, not easier.

Common mistakes

This section covers the failure patterns that show up repeatedly across Google Workspace, Microsoft 365, and mixed-provider environments.

Publishing multiple SPF records

This is the classic mistake. Teams add one SPF record for Google Workspace, another for Microsoft 365, and another for a marketing platform, assuming recipients will combine them. They usually will not. Merge authorizations into a single SPF record for that hostname.

Using the wrong domain or host label

DNS control panels vary. Entering the full host where the provider expects only the label can create duplicated names. The reverse can also happen. Always confirm the final record as published in authoritative DNS, not just how it appears in the UI.

Forgetting that DKIM is provider-specific

A successful dkim dns record setup for one platform does nothing for another. If your CRM and your mailbox provider both send mail with your domain, both may need their own selectors and signing enabled separately.

Turning on strict DMARC too early

A reject policy can be appropriate, but not before you understand all legitimate senders. Start with visibility, then tighten policy after you confirm alignment across real traffic.

Ignoring shadow senders

Forgotten systems are common: invoice tools, contact forms, cron-based scripts, support platforms, CI alerts, and older apps. If a service can send a message that appears to come from your domain, it belongs in your sender inventory.

Leaving stale providers authorized

After a migration, old SPF includes and DKIM selectors often remain in place for months. That increases maintenance burden and can complicate incident review later.

Assuming “pass” equals healthy

A message may pass one check while still failing DMARC policy because alignment is wrong. Deliverability troubleshooting should always look at SPF, DKIM, and DMARC together, not in isolation.

When to revisit

Email authentication is not a one-time project. Revisit it whenever the sending landscape changes, especially before a high-volume season, a product launch, or an infrastructure migration.

Use this action-oriented review list:

1. Before seasonal planning cycles: confirm all active senders, test deliverability, and verify that DMARC reports still go to the right mailbox.
2. When workflows or tools change: update SPF and DKIM whenever you add or remove a mail platform, CRM, support system, or product email provider.
3. After domain, DNS, or registrar changes: re-check that no records were dropped, reformatted, or published on the wrong host.
4. After an email incident: review headers, compare current DNS to your expected configuration, and remove uncertainty before tightening policy.
5. On a recurring schedule: audit records quarterly or semiannually, especially if several teams can enable outbound email tools.

A practical operating pattern for small dev teams is to maintain a simple source-of-truth document with these fields: sending service, purpose, domain or subdomain used, SPF dependency, DKIM selector, DMARC owner, date added, and date last tested. Better still, move records into automation where possible so changes are reviewed like code.

The real value of a reusable SPF, DKIM, and DMARC setup checklist is not just faster initial configuration. It is safer change management. Every time you add a provider, rotate keys, split traffic to a subdomain, or retire a legacy tool, come back to the same checklist: inventory senders, update DNS deliberately, validate from outside your network, and clean up what no longer belongs. That discipline is what keeps email authentication reliable over time.