Okta SPF, DKIM and DMARC setup, step by step

For an Okta-managed custom email sender, configure the email domain for the selected brand and publish the DNS values generated by Okta. Okta's SendGrid integration manages the underlying SPF and DKIM configuration through the supplied aliases. For an external email provider, configure SPF and DKIM with that provider, test the connection, enable it and associate the sending identity with each intended brand. Do not apply one route's DNS recipe to the other. Managed authentication · External-provider setup

This guide concerns Okta system notifications and branded email senders. It is not an Auth0 setup guide, an Okta Verify configuration guide or a guide to the HTTPS sign-in domain. Those products and settings can have different prerequisites and records.

On this page

• Scope, engine and eligibility
• Decide who controls authentication
• Route A: configure an Okta-managed custom email domain
• Route B: use an external email provider
• SPF, DKIM and DMARC checks that apply to both routes
• Acceptance test: use the correct brand and trigger
• Failure behavior and troubleshooting
• Frequently asked questions
• Review boundary

Scope, engine and eligibility

Record the organization, engine, brand, visible From address, email provider and intended triggering workflow before touching DNS. The managed-authentication support article explicitly covers both Okta Identity Engine and Classic Engine. The external-provider walkthrough used here is the Identity Engine publication; do not infer that every control is available in an older Classic organization. Managed sender scope

Custom email-address setup requires a super admin or org admin and access to public DNS. The Classic and Identity Engine help pages link to the shared developer workflow. That workflow defines one active email domain per brand, while the shorter help pages describe a one-domain limitation more broadly. Use the brand-specific workflow for multibrand configuration and verify your organization's entitlement rather than treating a single-domain statement as a universal org-wide limit. Classic setup · Identity Engine setup · Developer workflow

The current Identity Engine documentation labels custom-provider OAuth 2.0 as Early Access. Check whether that feature is enabled in your organization before selecting it. Email template customization is a separate capability: the developer guide directs Integrator Free Plan organizations to obtain access through Okta Support. Do not mistake template eligibility for proof that every custom sender or SMTP feature is licensed. External provider availability · Template prerequisites

Decide who controls authentication

OAuth or SMTP login authenticates Okta to the sending service. It does not by itself authenticate the visible From domain to recipients. An accepted connection can still send a message with unaligned SPF or DKIM.

Before changing anything, export existing DNS and record the current SPF, DKIM, DMARC, mail-routing and verification entries with TTLs. Identify any inherited DMARC policy. Confirm that the address is an authorized sender at the chosen provider, and decide which administrator will approve a record collision or a provider change.

Route A: configure an Okta-managed custom email domain

1. In the Admin Console, open Customizations > Brands and select the intended brand.
2. Open Domains, then the Emails section and choose Add domain.
3. Supply the notification From address and sender name, then continue.
4. Copy the generated DNS rows, including each complete owner, type and value.
5. Publish those rows at the authoritative DNS service, then select Verify in Okta.

Verification remains pending until Okta detects the DNS changes; the documented polling window can extend to 24 hours. The records in this email workflow are different from _acme-challenge and sign-in-domain TLS configuration. Do not alter authorization-server issuers or upload TLS private keys merely to authenticate email. Email-domain setup

Use the generated records, not a universal SPF include

The current managed-sender article describes three CNAMEs: a mail subdomain and two DKIM owners. Their destinations delegate authentication to Okta's SendGrid configuration. Publish any additional verification row shown in the wizard as well. Copy the actual selectors, subdomain and targets instead of deriving them from the organization name. Generated CNAME design

That distinction resolves an apparent conflict in the documentation: high-level pages discuss updating SPF, but the route-specific managed design uses provider-managed authentication behind aliases. Do not add include:sendgrid.net, include:okta.com or a guessed IP range to the root domain simply because you are setting up Okta. External-provider SPF changes belong to Route B.

Keep a full record inventory. A DNS editor may append your zone to an entered host; inspect the resulting name to avoid a duplicated suffix. Use DNS-only aliases where proxying exists. Do not put an HTTPS prefix on a target. A CNAME cannot coexist at its owner with ordinary TXT, MX, A or AAAA data. If a generated mail subdomain already has records, stop and resolve the conflict with the responsible administrators.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Okta's developer guide identifies a restriction when the domain already uses SendGrid and recommends a separate subdomain for Okta email. Plan that before replacing any existing SendGrid aliases. Confirm the exact From subdomain and its inherited DMARC policy, and re-check all generated rows after choosing it. Known issues

On Cloudflare, also leave flattening off for authentication aliases, including any zone-wide flatten-all-CNAME setting. DNS-only alone is insufficient if flattening hides the requested CNAME answer. Cloudflare verification guidance

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Route B: use an external email provider

First complete domain authentication with the external sender. Retrieve its actual SPF owner and DKIM records, publish the requested public values and enable signing where required. Some providers use TXT public keys, others CNAME delegation. A Google Workspace or Microsoft 365 mailbox does not acquire aligned DKIM merely because it can sign in to Okta.

For a Microsoft 365 external sending route, use EmailAuth’s Microsoft 365 SPF and DKIM guide for that tenant’s authentication. Those controls do not replace Okta’s brand association or managed-provider DNS workflow.

In Identity Engine, open Customizations > Email provider, add the provider and select the supported connection method. The current documentation offers OAuth client credentials for Microsoft-oriented configurations and JWT bearer authentication for Google-oriented configurations, subject to Early Access availability. Use the organization's approved secrets process; never put SMTP passwords, client secrets or private keys in DNS or an editorial worksheet. External provider methods

Use Okta's Send test email control with a valid From and a receiving address you control. Confirm receipt, then enable Use custom email provider. Add and verify the custom email domain for each intended brand. Do not assume configuring the organization-level connection automatically establishes every brand's sender.

A transport test is only the first gate. Check domain authentication on the received message too. An SMTP server may accept credentials but reject an unauthorized From address, or send successfully without the expected DKIM signature. Maintain the external provider's security requirements instead of weakening MFA or re-enabling obsolete password-based access to make a connection work.

SPF, DKIM and DMARC checks that apply to both routes

SPF authenticates the SMTP MAIL FROM domain, usually visible in Return-Path. Query that actual envelope domain rather than assuming the apex From domain controls SPF. If the external provider requires an SPF addition, preserve the existing authorized senders and merge the documented mechanism into the single policy at the correct owner. Do not create a second v=spf1 record. The limit is ten evaluated DNS-querying terms, including nested mechanisms, not ten top-level vendors. SPF specification

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

DKIM verifies a signature using the owner formed from its selector s= and signing domain d=. A record existing in DNS does not prove a message used it. With provider-managed signing, publish public verification data only; the service retains the signing key. DKIM specification

DMARC passes if either authenticated SPF or a valid DKIM signature aligns with the visible From domain. Relaxed alignment matches organizational domains; strict alignment requires the exact domain. A mail-subdomain envelope may pass SPF but fail strict alignment for an apex From. Evaluate the aligned DKIM path before considering any policy change. Current DMARC specification

Preserve existing reject/quarantine, strict alignment and reporting settings. Do not replace them with a tutorial's p=none record to cure a sender problem. For a domain without an established policy, plan monitoring across all senders and check parent-policy inheritance first. RFC 9989 supersedes RFC 7489 and removes pct; do not promise percentage rollout. Aggregate reporting is covered by RFC 9990, and RFC 9991 addresses failure reporting, which warrants a separate privacy review.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. Only when no direct or applicable inherited policy exists and the domain owner approves initial monitoring, an illustrative first record is TXT with value v=DMARC1; p=none. This requests no reports by itself; add rua only for a provisioned, approved destination after checking the reporting rule below. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Acceptance test: use the correct brand and trigger

Replace the example owners with your generated values:

dig +short CNAME ACTUAL-MAIL-SUBDOMAIN.example.com
dig +short TXT ACTUAL-MAIL-SUBDOMAIN.example.com
dig +short CNAME ACTUAL-SELECTOR._domainkey.example.com
dig +short TXT ACTUAL-SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Compare answers against every wizard row, including any TXT verification record. Check both authoritative and recursive answers if verification is pending. Follow CNAMEs to the underlying public SPF/DKIM data. An empty answer, missing key or stale target is not a pass.

Then exercise a legitimate notification workflow with a controlled test user. The trigger matters: Okta's email customization documentation explains that request-host selection determines the brand, and Admin Console sends may use the Okta domain rather than the intended custom address. For multibrand testing, use the documented brand-associated request domain and approved workflow. A generic Admin Console message is not sufficient evidence for every brand. Branded notification behavior

For each brand/provider combination, retain a redacted evidence row with trigger, From, Return-Path, DKIM d= and s=, receiving Authentication-Results, time and relevant System Log event. Use receiver-added authentication results, not an arbitrary similarly named header supplied by the sender. For the configured custom-domain route, require the expected branded DKIM signature to pass and align with the intended From, alongside receiver dmarc=pass. Also verify SPF authentication at the actual envelope owner. A DMARC pass through SPF alone does not prove the DKIM deployment is complete. Authentication-Results trust model

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Repeat after changing provider, brand, sender domain or credential material. A successful SMTP submission, Okta verification badge or received default-domain message does not prove custom-domain authentication. Neither authentication nor a System Log success guarantees inbox placement.

Investigate an actual spf=fail, permerror or temperror even if aligned DKIM makes DMARC pass. Check the observed envelope owner, authorized sender, evaluated lookup limit and DNS availability. A DMARC pass does not turn a broken SPF path into a healthy configuration.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Failure behavior and troubleshooting

The two routes have materially different failure behavior:

• Managed custom domain: Okta documents a daily domain check, administrator alerts and fallback to noreply@okta.com when a problem is detected. A notification arriving from the default domain can therefore indicate degraded custom-domain configuration, not a complete outage. Managed-domain monitoring
• External provider: delivery is retried, then recorded as FAILURE when attempts are exhausted, without fallback to the default service. Investigate the provider and System Log promptly, especially for activation and recovery messages. External-provider failure behavior

Plan credential renewal before expiry. Removing an external provider affects every brand using it and changes the sending arrangement; it is not a harmless debugging reset. Keep a reviewed recovery plan and avoid deleting still-needed DKIM records during an incident.

Review boundary

This is documentary guidance, not an account configuration or delivery test. No secrets were requested, no DNS or account settings changed and nothing was published. Before configuring your sender, confirm current tenant entitlement and official instructions. EmailAuth's next useful step is a brand-by-brand evidence review, not a promise of search visibility or guaranteed delivery.