SPF DKIM DMARC Configuration: Step-by-Step DNS Setup Guide

Do not index

You've tested the subject lines, refined the copy, and checked the campaign audience. Then launch day arrives, and messages that once reached Gmail, Outlook, and Yahoo start landing in spam. Open rates fall, replies disappear, and the team blames content when the problem is often hidden in DNS and message headers.

Broken SPF, DKIM, or DMARC configuration can weaken inbox placement, expose a domain to spoofing, and damage sender reputation across marketing, transactional, recruitment, and outbound mail. Authentication won't guarantee inbox placement, but missing authentication gives mailbox providers less evidence that legitimate messages belong in the inbox.

The practical problem is that most companies use several sending systems at once. Google Workspace may handle employee mail, a CRM may send notifications, a recruitment platform may send outreach, and a separate ESP may deliver newsletters. Each vendor can authenticate successfully while still failing DMARC alignment with the visible From domain. That gap is where generic setup checklists fail.

Table of Contents

Why Your Emails Keep Landing in Spam Why the problem stays hidden What needs attention first How SPF DKIM and DMARC Work Together The three roles are different Authentication is not alignment Why the full stack matters Configuring Your SPF Record Build one authoritative record Control the lookup budget Setting Up DKIM Signing Generate and publish the key Activate signing and align the domain Rotate without breaking mail Publishing Your DMARC Policy Choose a policy deliberately Move from monitoring to enforcement Verifying and Testing Your Setup Use real messages and headers Handle forwarding correctly Common SPF DKIM DMARC Mistakes to Avoid

Why Your Emails Keep Landing in Spam

An email marketer sees the symptoms first. A campaign with strong content underperforms, replies slow down, and messages from the same domain receive inconsistent treatment across mailbox providers. The team may rewrite the subject line or change the template, but those fixes won't repair a sender identity problem.

Mailbox providers evaluate more than copy. They examine authentication results, domain reputation, sending behavior, recipient responses, and whether the domain used by the sending infrastructure matches the address displayed to recipients. A message can pass SPF or DKIM and still fail DMARC when the authenticated identity doesn't align with the visible From domain.

That distinction matters commercially. When legitimate campaigns go to spam, recipients miss product updates, renewal notices, sales conversations, and customer education. The result can be lost conversions, a poorer customer experience, and declining trust in the brand.

A useful definition of what is email deliverability is the ability to place legitimate messages where recipients can read and act on them. SPF, DKIM, and DMARC support that outcome, but they work alongside reputation and responsible sending practices.

Why the problem stays hidden

Authentication failures often affect only certain streams. Employee mail may authenticate correctly while CRM notifications use a different Return-Path domain. A vendor may rotate its DKIM selector without the DNS record being updated. Forwarding may break SPF even though the original message was legitimate.

The most damaging assumption is that a green check in one tool proves the whole environment works. DNS records show intended configuration. Real message headers and DMARC reports show what receivers evaluate.

What needs attention first

Before changing campaign content, teams should:

Inventory every sender: Include employee mail, marketing platforms, transactional services, support tools, recruitment systems, and outbound infrastructure.

Separate identity from authorization: Check the sending IP, the DKIM signing domain, and the visible From domain.

Inspect real headers: Test messages from every platform, not only the primary mailbox provider.

Protect reputation during repairs: Avoid sudden campaign changes while legitimate authentication failures remain unresolved.

For a company with several vendors, expert guidance becomes valuable when ownership is unclear, DNS records conflict, or enforcement could interrupt important mail. The technical work is manageable, but the dependency mapping requires discipline.

How SPF DKIM and DMARC Work Together

SPF, DKIM, and DMARC work as one authentication stack. SPF authorizes sending sources, DKIM attaches a cryptographic signature, and DMARC checks alignment with the visible From domain while providing policy and reporting. Publishing these records separately does not guarantee that the message will pass as a whole. The alignment gap is where many multi-vendor setups fail.

SPF was first published in 2006 as RFC 4408. DKIM was standardized in RFC 6376, and DMARC later emerged as RFC 7489 to address weaknesses in SPF and DKIM. The modern specification appears in RFC 9989, which describes SPF and DKIM as domain-level authentication mechanisms and DMARC as the system that lets domain owners publish DNS TXT policies for mail that fails validation or alignment.

The three roles are different

SPF evaluates whether the sending source is authorized for the SMTP envelope domain. It does not directly prove that the visible From address is authorized.

DKIM uses a private key to sign selected message content. The receiving server retrieves the matching public key from DNS and verifies whether the signature remains valid after delivery.

DMARC connects these results to the address recipients see. It passes when at least one of SPF or DKIM passes and aligns with the visible From domain. If neither aligned mechanism passes, the receiver applies the published policy, which can be none, quarantine, or reject. The evaluation rule is documented in DMARC authentication and alignment guidance.

Authentication is not alignment

A marketing platform may pass DKIM with vendor-example.com while recipients see From: sales@example.com. DKIM authentication passes, but DMARC can fail because the signing domain does not align with the visible From domain.

Relaxed alignment permits related subdomains under the same organizational domain. Strict alignment requires an exact domain match. Validate both authentication and alignment before enforcement. A passing SPF or DKIM result alone does not prove that DMARC will pass.

This integrated model helps organizations prevent email spoofing with protocols, but it creates dependencies across vendors. SPF must authorize legitimate sources, DKIM must sign with an aligned domain, and DMARC must report and enforce the intended result. A CRM, transactional service, and marketing platform may each use different envelope domains, selectors, and From-domain settings.

Why the full stack matters

Deployment remains uneven. A scan of resolvable top-million domains found SPF on 62.8% and DMARC on 47.2%, according to SpamCipher's email authentication analysis. Another dataset found that 81.6% of 10 million popular domains had no DMARC record, while 7.6% enforced quarantine or reject policies, as reported by Fortra's DMARC adoption research.

The operational conclusion is direct. One published record cannot compensate for a missing authorization source, broken signature, misaligned identity, or policy that has never been tested. Evaluate the three protocols together against real messages and each vendor's actual sending path.

Configuring Your SPF Record

A new marketing platform starts sending before anyone updates DNS. The campaign then fails SPF, or the domain already contains multiple SPF records that receivers cannot evaluate consistently. Build SPF from a verified sender inventory, not from a copied example. The record authorizes sending infrastructure, while the From-domain alignment required by DMARC remains a separate check.

Build one authoritative record

First, query the domain for a TXT record beginning with v=spf1. Publish one SPF record and combine every legitimate sender in that value. Multiple SPF records create an invalid configuration.

A Google Workspace example is:

v=spf1 include:_spf.google.com ~all

Use that value only when Google is an authorized sending service. If a CRM, ESP, or transactional platform also sends mail, add each provider's official include mechanism to the same record. Confirm the current instructions for every vendor before publishing them.

Email Service	SPF Include Value	Notes
Google Workspace	`include:_spf.google.com`	Use the provider's current value and confirm every sending source.
Other ESPs	Provider-specific include	Obtain the official mechanism from the sending platform.
Transactional providers	Provider-specific include	Verify whether the service uses a custom Return-Path domain.

The table avoids guessed values because provider records can change. An incorrect include may authorize infrastructure you do not control, while an omitted include can block legitimate mail. Check the envelope sender and Return-Path for each service, not only the visible From address.

Control the lookup budget

SPF has a hard 10-DNS-lookup limit. Includes, redirects, and nested mechanisms can consume lookups indirectly, so a short-looking record may still exceed the limit. SalesHive's analysis found that 1.1% of domains in a 2025 global scan exceeded it, and receivers may return a permanent evaluation error when the limit is breached. Review the full expansion before relying on a passing syntax check.

Use this process:

List all senders: Record every service that sends with the domain.

Collect official mechanisms: Get each provider's current SPF instruction.

Merge the sources: Publish one TXT record rather than separate records.

Check lookups: Expand includes with an SPF analysis tool and identify hidden consumption.

Send real tests: Confirm the actual Return-Path domain and SPF result in message headers.

Remove abandoned vendors: Delete authorization for platforms that no longer send mail.

Teams can check their spf record before configuring DKIM. The review should confirm syntax, record uniqueness, authorized sources, and lookup usage. A passing SPF result still does not establish DKIM or DMARC alignment, particularly when different vendors use different envelope domains.

Setting Up DKIM Signing

DKIM gives the receiving server evidence that a message was signed by an authorized system and that the signed content wasn't altered in transit. It also provides resilience when forwarding changes the sending infrastructure, although modifications to signed content can invalidate the signature.

Generate and publish the key

The sending platform normally generates a private key and provides a public key record for DNS. The private key stays with the platform. The public key is published at a selector-based hostname such as:

selector._domainkey.example.com

A DKIM TXT value commonly begins with:

v=DKIM1; k=rsa; p=<PUBLIC_KEY_FROM_YOUR_PROVIDER>

The public key placeholder must be replaced with the exact value supplied by the sending platform. The selector in the message header must match the selector published in DNS.

Use a 2048-bit DKIM key for new deployments, as recommended in the operational guidance from SpamCipher. A shorter or outdated key can weaken the trust model and create avoidable maintenance risk.

Activate signing and align the domain

Publishing a public key doesn't activate DKIM. The platform must be configured to sign outgoing messages, and the d= domain in the DKIM signature should align with the visible From domain for DMARC.

A practical sequence is:

Generate a selector: Use the provider's administrator console and choose a clear selector that can be tracked during rotation.

Publish the DNS record: Copy the provider's exact TXT or CNAME value without altering the key.

Enable signing: Return to the sending platform and activate DKIM after DNS publication.

Inspect the header: Confirm dkim=pass, identify the selector, and check the d= domain.

Test each stream: Send from employee mail, marketing, transactional, support, and outbound systems separately.

Google Workspace, Microsoft 365, and transactional providers can use different selector names and publishing workflows. A valid record under one selector won't help a vendor signing with another selector.

Rotate without breaking mail

A safe rotation keeps the old selector available while the new selector becomes active. Once reports and headers show that the provider uses the new key, the old selector can be retired according to the platform's operational requirements.

Forwarding commonly breaks SPF because the forwarding server isn't included in the original authorization. DKIM may survive when the message remains intact, which is why both mechanisms should be configured rather than treating either as sufficient. The dkim checker can verify that the selector resolves and that the public key is present, but real headers still determine whether signing is active.

Publishing Your DMARC Policy

DMARC turns SPF and DKIM results into an operating rule for receivers. It also exposes which platforms send mail using your domain, including vendors that authenticate successfully but fail alignment with the visible From address.

Publish the record at _dmarc.example.com as a DNS TXT value. Start with a monitoring policy such as:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The rua tag requests aggregate reports. Assign someone to review those reports, or route them into a system that can separate approved vendors from spoofing attempts and alignment failures. A published record without usable reporting leaves the sending stack difficult to troubleshoot.

Choose a policy deliberately

p=none supports discovery. It collects information without asking receivers to quarantine or reject messages, giving teams time to identify legitimate traffic before enforcement affects customer mail.

Policy	What It Does	When to Use
`p=none`	Requests monitoring without quarantine or rejection	During discovery and remediation of legitimate failures
`p=quarantine`	Requests that failing messages be treated as suspicious	After legitimate sources authenticate and align
`p=reject`	Requests rejection of messages that fail DMARC	After reporting supports confident enforcement

Adoption of strict enforcement remains limited, and many domains still publish no DMARC record. Publication alone therefore does not provide protection. The policy must match what your reports show.

Move from monitoring to enforcement

Use the mail flow to guide the rollout:

Publish monitoring: Start with p=none and an aggregate reporting destination.

Map sources: Identify every legitimate platform appearing in reports.

Fix alignment: Correct SPF domains, DKIM signing domains, selectors, and vendor settings.

Review subdomains: Confirm that subdomain policy and From-domain usage are consistent.

Increase enforcement: Move to quarantine after legitimate traffic is understood.

Reach rejection carefully: Use reject when reports show legitimate mail consistently passes.

Relaxed alignment often suits multi-vendor environments because envelope domains and DKIM identities can differ across providers. Strict alignment gives tighter control, but every sender must use the exact expected domain. Choose based on the way each platform authenticates, then raise enforcement only after the reports support it.

Verifying and Testing Your Setup

DNS publication is only the beginning. A record can exist and still fail during a real send because the platform uses an unauthorized source, signs with an unexpected selector, or authenticates a domain that doesn't align with the visible From address.

Use real messages and headers

Send separate test messages from each sending system. In Gmail, open the message, choose the option to view the original, and locate the Authentication-Results header. In Outlook, inspect the message source or internet headers for the corresponding authentication results.

Look for results such as:

spf=pass dkim=pass dmarc=pass

Then inspect the domains, not only the result labels. Confirm the SPF-authenticated domain and the DKIM d= domain align with the visible From domain under the selected alignment mode.

A practical checklist includes:

SPF validation: Confirm the sending source is authorized and the record stays within the lookup limit.

DKIM validation: Match the selector in the header to the public key in DNS.

DMARC validation: Confirm at least one authenticated mechanism also aligns.

Vendor coverage: Test CRM, ESP, support, transactional, recruitment, and outbound streams.

Report review: Use aggregate reports to identify unknown sources and recurring failures.

Teams can also check SPF and DKIM records with an external checker, then compare that DNS result with actual message headers. Tools are useful for discovery, but they can't replace stream-by-stream testing.

Handle forwarding correctly

Forwarding often changes the sending IP, so SPF can fail even when the original sender was legitimate. DKIM may continue to pass if the forwarding service preserves the signed message content.

Forwarding systems that support Sender Rewriting Scheme, or SRS, can preserve the SPF path by rewriting the envelope sender. DKIM remains important because it travels with the message, but a forwarder that modifies signed headers or body content can invalidate the signature.

DMARC aggregate reports should be reviewed continuously after changes. Vendor migrations, selector rotations, new subdomains, and forwarding behavior can create failures long after the original records appeared correct.

Common SPF DKIM DMARC Mistakes to Avoid

A technically valid-looking record can still produce poor delivery. The recurring failures are operational, not cosmetic.

Multiple SPF records: Receivers may return an SPF permanent error. Combine authorized mechanisms into one record.

Missing vendor sources: Legitimate CRM or transactional mail can fail SPF. Add the provider's official mechanism after confirming it sends for the domain.

More than 10 SPF lookups: Nested includes can exceed the evaluation limit. Expand the record and remove unnecessary services.

Stale DKIM selectors: Vendor rotation can leave the platform signing with a selector absent from DNS. Publish the active selector and confirm the header.

Unaligned DKIM: A passing signature from a vendor domain doesn't necessarily pass DMARC. Configure an aligned signing domain where the platform supports it.

Permanent p=none: Monitoring provides visibility but doesn't request spoofed mail to be quarantined or rejected. Progress after legitimate sources are mapped.

Weak or outdated keys: Use aligned 2048-bit DKIM keys and manage selectors deliberately.

Missing reporting: A 2025 analysis found 73% of valid DMARC records lacked forensic reporting, known as ruf, according to SalesHive's configuration analysis. Reporting choices must also reflect privacy, security, and provider support.

A DMARC implementation should be treated as a monitored system. MailAdept is one option for teams that need ongoing deliverability support across authentication, reputation, vendor changes, and mailbox-provider behavior. Its service combines technical audits with continuous monitoring and remediation rather than relying on isolated DNS checks.

MailAdept can audit the full SPF, DKIM, and DMARC stack, trace failures across multi-vendor sending environments, and help teams move from monitoring to safe enforcement. Visit MailAdept to request a deliverability assessment focused on inbox placement, authentication alignment, and reputation risk.