Email Authentication Setup: SPF, DKIM, and DMARC Step by Step

Email authentication setup is the DNS work that proves messages using your domain are legitimate. Done well, it protects customers from impersonation and gives receiving mailbox providers the evidence they need to trust your transactional and marketing email.

What email authentication setup actually does

Email was designed without a built-in way to verify that the visible sender is authorized to use a domain. A criminal can therefore put billing@yourcompany.com in a message’s visible From field without owning yourcompany.com. Authentication standards reduce that gap by checking the infrastructure and cryptographic signatures behind a message.

The three standards you need are:

• SPF (Sender Policy Framework): a DNS policy saying which servers or services may send mail using a domain in the SMTP envelope sender, also called Return-Path or MAIL FROM domain.
• DKIM (DomainKeys Identified Mail): a cryptographic signature attached to each message. Receivers retrieve a public key from DNS and use it to confirm the signed content has not changed and the sending system controls the signing domain.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): a policy that ties SPF and DKIM to the domain people see in the From header, tells receivers what to do when checks fail, and can send aggregate reports.

These controls complement rather than replace good sending behavior. They cannot make unwanted mail welcome, repair a poor permission model, or guarantee inbox placement. They do establish domain identity, which is essential for delivery, brand protection, and diagnosing spoofing.

A useful distinction is that SPF and DKIM can pass even when they authenticate a third party’s domain. DMARC asks whether at least one passing identifier is aligned with the visible From domain. That alignment requirement is why simply seeing “SPF: pass” in a mail header does not prove your visible brand domain passed DMARC.

The records and identities you must map first

Do not start by pasting records from a provider’s dashboard. First make an inventory of every system that sends as your organization. Missing one is the most common cause of authentication failures after a DNS change.

Include systems such as:

1. Your application’s receipts, password resets, and notifications.
2. Marketing and newsletter platforms.
3. Customer-support tools that send ticket updates.
4. CRM, sales sequencing, and form automation tools.
5. Workspace or Microsoft 365 mailboxes.
6. Website, ecommerce, invoicing, recruiting, monitoring, and status-page software.
7. Any agency, affiliate platform, or legacy SMTP relay.

For each system, collect the answers below. A spreadsheet is sufficient.

You can use the organizational domain itself, such as example.com, for all mail. Many teams instead use a dedicated subdomain, such as mail.example.com for application email or news.example.com for marketing. Subdomains isolate operational streams and make it easier to identify the source of an issue. They do not evade the need for authentication: each domain that appears in a visible From header needs appropriate DMARC coverage.

If your visible From address is updates@news.example.com, DMARC first checks for a record at _dmarc.news.example.com. If none exists, receivers can use the organizational-domain policy at _dmarc.example.com, subject to the DMARC discovery rules. Publish an explicit subdomain record when that subdomain has a distinct policy or reporting destination.

SPF setup: authorize senders without breaking lookup limits

An SPF record is a TXT record at the domain used in the envelope sender. It begins with v=spf1, contains mechanisms that authorize sources, and ends with a policy qualifier. A simple record for a domain whose Google Workspace mail and an email API provider both send mail might look like this:

Type: TXT
Host/Name: @
Value: v=spf1 include:_spf.google.com include:spf.email-provider.example -all
TTL: 3600

The two include mechanisms delegate evaluation to the authorized services’ SPF records. The -all ending means every sender not matched by the preceding mechanisms fails SPF. Use the exact include hostname documented by your provider; spf.email-provider.example above is illustrative, not a hostname to deploy.

SPF rules that prevent expensive mistakes

There must be one SPF TXT record per domain. DNS permits multiple TXT records, but SPF does not permit multiple SPF policies. If two records both start with v=spf1, SPF evaluation returns PermError. Merge mechanisms into one record instead.

SPF has a strict limit of 10 DNS-query-causing mechanisms and modifiers during evaluation. include, a, mx, exists, redirect, and some ptr use can consume this budget. An include may itself trigger additional lookups, so a short-looking record can still exceed the limit. More vendors are not always better: remove services that no longer send, and ask a provider whether it offers a flattened SPF option only after understanding how it maintains IP changes.

Avoid +all, which allows every IP address on the internet. Avoid using ?all as a permanent production policy because it produces a neutral result rather than a clear unauthorized result. ~all is a soft fail and is sometimes used during a brief migration, but -all is the normal end state after you verify all authorized senders.

SPF is vulnerable to forwarding. A forwarder can relay a legitimate message from an IP that is not in the original sender’s SPF policy, causing SPF to fail. This is one reason DKIM is essential: a valid DKIM signature usually survives ordinary forwarding.

SPF validation checklist

After publishing, query the TXT record with a DNS lookup tool or command such as:

dig TXT example.com +short

Then send a test message from every sending platform to a Gmail or Outlook mailbox you control. Inspect the raw message source. You want to see an Authentication-Results line with a passing SPF result for the intended envelope domain. Do not stop there: continue to DKIM and DMARC alignment checks.

DKIM setup: publish keys and sign every mail stream

DKIM lets a receiver verify that selected headers and the message body were signed by a domain that controls a DNS key. The sending system inserts a DKIM-Signature header containing fields including d= for signing domain and s= for selector. The receiver looks up the public key at:

<selector>._domainkey.<signing-domain>

For example, if a message is signed with d=example.com; s=s1, the receiver queries:

s1._domainkey.example.com

TXT versus CNAME DKIM records

Some systems provide a TXT record containing a key, commonly shaped like this:

Type: TXT
Host/Name: s1._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB
TTL: 3600

The p= value is a long public key and must be copied exactly. Some DNS dashboards automatically split long TXT strings into quoted chunks. That is valid DNS behavior as long as the assembled record value is unchanged. Do not insert spaces, omit characters, or manually alter the key.

Other providers ask for CNAME records, for example:

Type: CNAME
Host/Name: s1._domainkey
Value: s1.domainkey.provider-mail.example
TTL: 3600

A CNAME lets the provider host and rotate the underlying DKIM key. Use the record type and target supplied by the service; a CNAME is not interchangeable with a TXT record. Some providers require two or three selectors, so add every record they specify.

For normal sending, use keys of at least 1024 bits; 2048-bit RSA keys are widely supported and generally preferred when your DNS provider supports the record size. Ed25519 DKIM keys are defined by the standard but support depends on the sender and receiver. Follow your sending provider’s documented key format rather than inventing one.

DKIM alignment and reliable signing

For DMARC, the domain in DKIM’s d= value must align with the visible From domain. In relaxed alignment, mailer.example.com can align with example.com because it is a subdomain. In strict alignment, they must be identical. A signature from provider-mail.example can pass DKIM but does not align with example.com.

Configure custom domain signing in every third-party platform. This is often called domain authentication, sending-domain verification, or branded sending domain. It usually means adding provider-supplied CNAME records and then clicking Verify in that platform.

Send a message and inspect its headers for dkim=pass and a header.d= value aligned with the From address. A published DKIM record alone proves nothing if the application is not actually applying a signature. Likewise, a valid signature from the wrong domain is inadequate for DMARC.

DMARC setup: monitor first, then enforce

A DMARC record is a TXT record at _dmarc.yourdomain. Its minimum useful form is:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
TTL: 3600

p=none asks receivers to take no special disposition action based on DMARC failure, while still allowing reporting. It is the appropriate initial policy because it reveals legitimate systems you missed. It does not mean DMARC is disabled: receivers still evaluate and report DMARC.

The most important tags are:

Aggregate reports arrive as XML files, typically compressed, from participating receivers. They show the IP address, count, SPF and DKIM outcomes, disposition, and domains used for authentication. They are telemetry, not a real-time alert system, and not every receiver sends them.

A sensible DMARC rollout

Start with p=none and a working aggregate-report mailbox or reporting service. Review reports through enough normal business cycles to capture monthly invoices, scheduled campaigns, and low-volume tools. Classify every meaningful source as authorized, unauthorized, or unknown.

Then tighten policy in stages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

After you have fixed legitimate failures, raise pct progressively and move to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

quarantine asks receivers to treat failing mail suspiciously, often by sending it to spam. reject asks them not to accept it. Both are requests, not absolute commands; each receiver makes the final delivery decision.

Relaxed alignment (r) is the practical default for most organizations. Strict alignment (s) can be valuable when you deliberately want exact-domain matching, but it frequently exposes subdomain configurations that have not been planned. Make that choice intentionally after your inventory is clean.

If reports go to a different domain, DMARC requires an additional external-destination authorization record. For a policy on example.com sending reports to reports@dmarc-service.example, the reporting domain publishes a TXT record at example.com._report._dmarc.dmarc-service.example authorizing that destination. Managed DMARC services normally provide the exact value. This detail is why a report mailbox at your own domain is simpler for an initial deployment.

Worked example: authenticate a SaaS product domain

Assume Acme Cloud owns acmecloud.com. Employees send personal correspondence through Google Workspace. Its product sends login links and receipts through an email API provider. Marketing sends newsletters through a separate platform. The team wants all customer-facing messages to use @acmecloud.com initially.

1. Choose domain roles

Acme decides on these visible From addresses:

• support@acmecloud.com from Google Workspace.
• receipts@acmecloud.com from the application email provider.
• newsletter@acmecloud.com from the marketing provider.

It asks both external providers to authenticate acmecloud.com as a custom sending domain. This is preferable to leaving a vendor domain in DKIM when the From address is Acme’s domain.

2. Merge SPF authorization

Google Workspace documents its include mechanism, and each external provider supplies its own. Acme publishes one consolidated SPF record:

acmecloud.com.  TXT  "v=spf1 include:_spf.google.com include:spf.appmailer.example include:spf.marketingmailer.example -all"

The last two include domains are placeholders. In production Acme substitutes the exact hostnames from each vendor’s DNS instructions. It confirms there was no old SPF record before publishing this one and checks its total lookup count, including nested includes.

3. Add provider DKIM records

Google Workspace may use a selector such as google and give Acme a TXT public key. The application provider might supply three CNAME records such as a1._domainkey, a2._domainkey, and a3._domainkey; the marketing system may provide another set. Acme adds every record without altering its target.

It then uses each provider dashboard to verify the domain and enables DKIM signing. DNS publication is not the final step: verification confirms the provider can resolve the record and has activated it.

4. Start DMARC observation

Acme creates dmarc-reports@acmecloud.com and publishes:

_dmarc.acmecloud.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@acmecloud.com; adkim=r; aspf=r"

It sends tests from all three systems to mailboxes at several major providers. In the message source, it checks for a result like:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=mail.acmecloud.com;
       dkim=pass header.d=acmecloud.com;
       dmarc=pass header.from=acmecloud.com

The precise wording differs by receiver. What matters is that DMARC passes and at least SPF or DKIM is both passing and aligned with acmecloud.com.

5. Read reports and enforce

Reports reveal an old helpdesk tool still sends From: support@acmecloud.com but signs with the helpdesk vendor’s domain and uses an unaligned Return-Path. Acme either configures custom DKIM in that tool or changes its From address to a properly authenticated domain. Only after resolving that legitimate source does it advance DMARC to quarantine, then eventually to reject.

This process protects the brand without accidentally filtering password resets, invoices, or support replies.

How to test whether authentication worked

Use multiple checks because each catches a different failure. A DNS checker proves publication, but it cannot prove that a sending application uses the records correctly.

First, inspect DNS directly:

dig TXT acmecloud.com +short
dig TXT s1._domainkey.acmecloud.com +short
dig TXT _dmarc.acmecloud.com +short

For CNAME-based DKIM, query CNAME rather than TXT at the selector host. Allow for DNS propagation according to the TTL and your DNS provider’s update behavior; do not repeatedly change records while caches are still serving the previous value.

Second, send real messages from every platform. Gmail’s “Show original” view displays SPF, DKIM, and DMARC outcomes. Microsoft Outlook and other clients expose message headers, though their interface and header presentation vary. Header analysis services can make results easier to read, but avoid sending real customer data to a third-party analyzer.

Third, test the details that dashboards may hide:

• SPF shows the expected envelope sender domain, not merely a pass on a vendor domain.
• DKIM has d=yourdomain.com or an aligned subdomain.
• The visible From domain is what you intended.
• DMARC shows pass for each actual sending stream.
• The message is signed after any system that modifies content, such as a mailing list or relay.
• DMARC aggregate reports contain only expected authorized sources before enforcement.

For transactional email, test actual flows: a signup confirmation, password reset, invoice, bounced address, reply handling, and an attachment if your product sends one. Authentication is a sending-domain control, but user-visible sending reliability depends on the entire mail path. Teams comparing providers should also consider authenticated-domain support, API workflows, and transactional email sending costs, not only a headline message allowance.

Common email authentication setup errors and fixes

Two SPF records or too many DNS lookups

Symptom: SPF returns PermError, or a receiving provider reports an SPF error.

Fix: Find every TXT value beginning v=spf1, merge authorized mechanisms into one record, remove obsolete vendors, and evaluate nested lookup use. Do not simply add a second record because a new provider requests SPF.

DKIM is published but fails

Symptom: dkim=fail, “no key,” or provider verification never completes.

Fix: Check the selector character for character, query the fully qualified name, and verify that your DNS control panel did not append the domain twice. A host field entered as s1._domainkey.example.com in a panel that appends example.com may become s1._domainkey.example.com.example.com. Also ensure the app is sending through the same provider account whose selector you configured.

SPF and DKIM pass, but DMARC fails

Symptom: The raw headers show individual passes but dmarc=fail.

Fix: Compare the visible From: domain with SPF’s smtp.mailfrom domain and DKIM’s header.d domain. Configure a custom Return-Path and/or custom DKIM signing domain so at least one pass aligns. This is especially common with SaaS tools left on their default vendor domain.

DMARC enforcement blocks legitimate mail

Symptom: A valid business system starts landing in spam or being rejected after quarantine or reject.

Fix: Temporarily reduce enforcement only as needed, identify the failing source from reports and headers, and authenticate that source correctly. Do not permanently weaken the policy to preserve an unmanaged sender. If a provider cannot support aligned SPF or DKIM, use a From domain it can authenticate or replace the sending path.

A third party wants to send as your root domain

Symptom: A new tool asks you to add broad SPF permission or claims it can “send from” your company.

Fix: Confirm its custom-DKIM capabilities, permission controls, and use case before authorizing it. Consider giving the tool a dedicated subdomain such as events.example.com. This limits operational coupling and makes DMARC reports easier to interpret.

Deliverability requirements and the limits of authentication

Major mailbox providers expect senders to authenticate mail. Google’s sender guidelines specify SPF or DKIM for all senders to personal Gmail accounts, while bulk senders must use SPF, DKIM, and DMARC and meet additional requirements. Google defines a bulk sender as one that sends close to 5,000 or more messages in a day to personal Gmail addresses. Yahoo Mail also publishes requirements covering authentication, DMARC for bulk senders, unsubscribe handling for marketing mail, and complaint-rate expectations.

Authentication is therefore baseline infrastructure, not an optional deliverability trick. It is also separate from list hygiene, consent, content relevance, complaint management, IP and domain reputation, and unsubscribe design. A perfectly authenticated campaign sent to people who never asked for it can still be filtered.

For marketing messages, implement one-click unsubscribe where required by the mailbox provider’s policy. This is generally done through List-Unsubscribe and List-Unsubscribe-Post headers, not by relying solely on a footer link. Your email platform may generate these headers automatically, but test an actual delivered message rather than assuming the setting is enabled.

Keep transactional and marketing traffic logically separate where practical. Separate subdomains and provider configurations make it easier to monitor reputational signals, identify a compromised integration, and avoid an aggressive campaign affecting critical product mail. They are not a substitute for consent or a license to send bulk mail from a new domain.

Operating DMARC after the initial rollout

Email authentication is not a set-and-forget DNS task. Treat it as an operational control with an owner, a change process, and recurring review.

Review DMARC aggregate reports at least regularly enough to notice a new unauthorized source before it becomes normalized. Look for new IP ranges, unfamiliar DKIM domains, a sudden rise in failed messages, and legitimate vendors that have quietly changed their mail infrastructure. Maintain a sender inventory alongside your DNS records so departing vendors are removed promptly.

Rotate DKIM keys according to your provider’s capabilities and security policy. With CNAME-based DKIM, the provider may manage rotation. With self-managed TXT keys, publish a new selector, configure the sender to use it, verify delivery, and only then retire the old selector after old mail has had time to finish delivery and verification.

Protect DNS access with least privilege and multi-factor authentication. An attacker who can modify your DNS can redirect DKIM selectors, weaken DMARC, or authorize their infrastructure in SPF. Record changes in your change-management system, especially adjustments to SPF includes and DMARC policy.

DMARC reports can expose operational information about mail volume and sending sources. Use a mailbox or reporting vendor with appropriate access controls, and avoid forwarding raw reports indiscriminately. If you use a platform’s API to manage domains and sending, keep its API credentials scoped and documented; implementation details belong in the provider’s email API setup documentation.

Email authentication setup checklist

Before treating the project as complete, confirm all of the following:

• You have a current inventory of every system that sends visible mail from your domains.
• Each SPF-enabled domain has exactly one valid SPF record and stays within the 10-lookup evaluation limit.
• Every production sender applies DKIM, and its signing domain aligns with the From domain where needed.
• A DMARC record exists for each actively used From domain or an intentional organizational-domain policy covers it.
• DMARC started in monitoring mode and reports were reviewed before enforcement.
• Legitimate sources are fixed rather than exempted with a permanently weak policy.
• Your intended policy has progressed to quarantine or reject after validation.
• Test emails from every sender show dmarc=pass in delivered message headers.
• Marketing mail has the appropriate unsubscribe mechanism and permission practices.
• DNS and sending-provider access are secured, owned, and documented.

The practical definition of success is not merely a green check in one provider dashboard. It is a consistent dmarc=pass on real messages from every approved system, meaningful report visibility, and an enforcement policy that makes spoofed mail materially harder to deliver.

FAQ

Do I need SPF, DKIM, and DMARC, or is one enough?

Use all three. SPF authorizes sending infrastructure, DKIM cryptographically signs messages, and DMARC enforces alignment with the visible From domain. DKIM also provides resilience when forwarding breaks SPF.

How long does email authentication setup take?

DNS records can become visible according to their TTL and resolver caching behavior, but a safe DMARC deployment takes longer because you need to observe normal sending cycles and fix every legitimate source before enforcement. Do not move to p=reject simply because a single test message passes.

Can I have more than one DKIM record?

Yes. Multiple selectors and multiple providers can coexist because each DKIM record has a distinct selector hostname, such as s1._domainkey.example.com. This differs from SPF, where a domain must have only one SPF policy record.

What is the safest first DMARC record?

Start with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. Confirm the mailbox works, analyze reports, and make sure all legitimate sources pass aligned SPF or DKIM before raising enforcement.

Does DMARC reject every spoofed email?

No. DMARC tells participating receivers what you request for messages that fail, but each receiver controls its own final handling. A reject policy is still the strongest standard DMARC posture for reducing direct-domain spoofing after you have validated legitimate mail.