Okta SPF and DKIM setup

What you are setting up

Okta is an identity provider, and the mail it sends is transactional and security-sensitive: account activations, password resets, MFA enrollment, and admin alerts. By default all of it comes from noreply@okta.com, which authenticates fine but as Okta, not as you. The custom email address feature moves that sender onto your domain, and it is configured per brand: one email domain per brand, and Okta's super admins get a confirmation email once it is working. Under the hood Okta delivers this mail through SendGrid with SendGrid's automated security turned on, which is why there is no include:okta.com to add and no key to paste: you publish CNAME records that delegate SPF and DKIM to SendGrid, and Okta's SendGrid account keeps them current. Okta's support article on the subject says it plainly: a lookup on the first CNAME “reveals an existing SPF record for the sender that includes all the IP addresses SendGrid uses to send Okta emails,” and the last two CNAMEs “confirm the active DKIM configuration.”

If you instead point Okta at your own SMTP or OAuth 2.0 email provider (Microsoft 365 or Google Workspace, under Customizations > Email provider), none of the records below apply; Okta's guide says you then “need to configure SPF and DKIM records” for that provider, so follow our Microsoft 365 or Google Workspace guide instead. The rest of this page covers the default Okta-delivered path.

Publish SPF and DKIM

In the Admin Console, go to Customizations > Brands, select the brand, open the Domains tab, and in the Emails section click Add domain. You need to be a super admin or org admin. In the Email address field, enter the full sender address your users will see, for example noreply@mail.example.com; the domain part of that address is the email domain Okta verifies. Enter the Name of email sender, click Continue, and Okta shows the DNS records to publish. With mail.example.com as the email domain, the shape is (these are Okta's own documented examples; yours carry your account's selector labels and SendGrid identifiers):

Type:  TXT     (domain verification)
Host:  _oktaverification.mail.example.com
Value: 9da4ac4cb6ca4bb3b78934f91ed4c60b       (32 hex characters, unique to you)

Type:  CNAME   (return-path, carries SPF)
Host:  mail.mail.example.com
Value: u17770251.wl002.sendgrid.net

Type:  CNAME   (DKIM key 1)
Host:  p03._domainkey.mail.example.com
Value: p03.domainkey.u17770251.wl002.sendgrid.net

Type:  CNAME   (DKIM key 2)
Host:  p032._domainkey.mail.example.com
Value: p032.domainkey.u17770251.wl002.sendgrid.net

Three things about those hosts. First, the selector labels are per account: Okta's examples show p03 and p032 in one place and t02 and t022 in another, always a short label and the same label with a 2 appended, and the u number and wl pool in the targets are Okta's SendGrid identifiers, so copy every value from your own Okta page rather than from this article. Second, the return-path CNAME sits at a mail label under your email domain (Okta's API calls it the validationSubdomain), which is why an email domain of mail.example.com produces the odd-looking mail.mail.example.com. That host never appears in a message your users read; Okta uses it for the SendGrid CNAME delegation. Third, every host above is fully qualified. If your DNS host appends the zone for you, enter only the label part (_oktaverification.mail, p03._domainkey.mail, and so on); Okta's own note for its verification record is that “depending on your domain provider, you may only need to enter _oktaverification” rather than the full name.

There is no SPF TXT record to write for this sender. The mail.mail.example.com CNAME resolves to a SendGrid host that publishes its own SPF record, and Okta's SendGrid account signs with the two delegated keys, so SPF and DKIM are both handled by the CNAMEs. Okta's only SPF rule is the standard one: “You can't have more than 10 DNS lookups in your SPF record,” and if you already publish SPF at the email domain, keep it valid; our lookup counter shows where you stand. Do not add include:sendgrid.net for Okta. It spends a lookup and authorizes nothing extra, because the Okta mail stream is authorized through the delegated host, not through your record.

Add DMARC

Okta publishes SPF and DKIM through the CNAMEs above but leaves DMARC to you. It belongs at the root domain, where it covers mail.example.com and every other subdomain; start in monitor-only mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Okta's own support article on DMARC for a custom email address offers v=DMARC1;p=reject;pct=100;rua=mailto:dmarc@example.com as its sample, at _dmarc. followed by the custom email domain. That is a fine destination and a poor starting point: publish p=none first, confirm in your reports that the Okta source is aligned, then progress past p=none. Alignment should hold twice over, because both the DKIM d= and the Return-Path host sit on your email domain, and a subdomain such as mail.example.com aligns with a record at example.com under DMARC's default relaxed mode. If you place the record on the subdomain itself as Okta's article does, remember it then applies only to that subdomain; the root still needs its own. Build either one with our DMARC builder.

The Okta gotcha

A domain that already uses SendGrid cannot be Okta's email domain. Okta lists this as a known issue in its own words: “You can't configure Okta to send emails through a domain that uses SendGrid. Instead, configure a subdomain with your DNS provider for custom Okta emails.” The reason is the mechanism above. Okta's records are SendGrid domain authentication for Okta's SendGrid account, and SendGrid ties an authenticated domain to one account, so if example.com is already authenticated in your own SendGrid account, or through another SendGrid-backed product such as Braze, Okta's verification will not complete there. The same trap applies to the mail label: many SendGrid setups already own a mail.example.com or em1234.example.com CNAME, and a CNAME cannot share a name with any other record. The clean answer is a subdomain used by nothing else, such as okta.example.com or id.example.com, so the sender becomes noreply@okta.example.com and the four records land where nothing collides. Pick it before you click Add domain, because the email address is what the users see and changing it later means re-verifying.

Verification is a poll, not a button, and a broken record quietly reverts you to okta.com. After you click Verify, Okta “begins polling your DNS records until it detects your updates (this may take up to 24 hours),” and the address stays pending until then. Once verified, Okta keeps polling once every 24 hours; if a record disappears, it emails your super admins and “Okta-generated emails are sent from the default address noreply@okta.com until the problem is resolved.” That failover keeps mail flowing, but it also means the Okta row can vanish from your DMARC reports for your domain without any bounce to alert you, so a missing source is a signal, not a quiet week. One related trap: Okta's support has an article on activation and reset emails bouncing with 550 5.7.26 Unauthenticated email ... not accepted due to domain's DMARC policy, and its suggested fix is to relax the domain to p=none. Do not do that. The message failed because it was unauthenticated for your domain, and the right fix is the four records above, verified; a domain at enforcement should stay there.

Confirm it worked

• Check the Domains tab. Under Customizations > Brands > Domains > Emails the address should show as verified, and your super admins should have received Okta's confirmation email. A record that will not verify is usually a DNS host that appended your zone to a host that was already fully qualified, or a proxied CNAME; look the four names up with dig and confirm each answers with the exact target Okta printed.
• Trigger a real email and read the headers. Send yourself a password reset or an activation, open the message, and confirm the From is your address, the DKIM signature shows d=mail.example.com (your email domain) with one of the two selectors Okta gave you, the Return-Path sits under that same domain, and the result is dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. Okta mail shows up in your DMARC aggregate reports as SendGrid infrastructure sending for your email domain, aligned on both SPF and DKIM, and trustyourinbox labels the source accordingly. Volume will be low and spiky (people reset passwords in bursts), so judge it on pass rate, not count.