UKG Pro SPF, DKIM and DMARC setup, step by step

For the documented native UKG Pro email route, UKG publishes include:_spf.ultipro.com and supports custom-domain DKIM through a Support case. Confirm the actual product, From domain and envelope domain first. Add SPF authorization only where that envelope identity requires it, obtain the DKIM instructions for your domains and subdomains, and verify a new message at a trusted receiver. A branded setup is complete when your domain's DKIM signature passes and aligns, and DMARC passes. UKG's email-security instructions.

These instructions do not make every UKG service use the same sender. The source includes general UKG Pro email-security guidance within its Onboarding documentation; its Onboarding menus and sender-address restrictions apply to Onboarding, not automatically to other Pro modules.

Identify the UKG Pro product and sending route

UltiPro is the former name of UKG Pro. The name change does not establish which email system your tenant or module uses. This guide covers the native UKG Pro SaaS route described in UKG's email-security guidance, which sends from UKG's data centers directly to the recipient domain's MX servers. It is not a UKG Ready, Kronos SaaShr, Ascentis or ADP WorkForce configuration guide. UKG product identity, current route documentation.

UKG's source separately identifies the SaaS email route for examples including Pro, People Analytics, Talent and Time, and describes different delivery services for Pro Learning, Benefits Prime, UKG Community and other communications. Do not add every address or service in that table to your SPF record. A shared UKG logo is not proof that a message uses the same envelope identity or DKIM setup.

Before requesting a change, record:

Have UKG Support confirm that your exact module, tenant and notification use the documented native route. If they use a different service, obtain that service's current instructions instead. This guide does not establish identical sender options or activation controls across all UKG Pro modules.

Check sender options before editing DNS

Onboarding has a specific sender-address limitation

For UKG Pro Onboarding, the documented path is Settings > Notifications. Advanced Settings contains Global Email Settings. Where available, its default Sender Name and Email Address apply when an alternate sender is not specified. However, UKG states that the sender Email Address field is not available for organizations that went live with Onboarding after November 1, 2022. The same restriction appears in its alternate-sender instructions. Onboarding notification settings.

Do not treat a missing field as a DNS problem or try to bypass the restriction. Ask Support which sender identity the notification actually uses and what options your tenant supports. A display name or branded email template does not change the authenticated domain. Do not copy this menu path into instructions for Core HR, payroll or another Pro module.

Provider-domain sending is different from branded signing

UKG documents DKIM signing for mail sent from ultipro.com and ultimatesoftware.com, with no customer-side DKIM setup for those provider domains. You do not administer their DNS. A valid signature for a UKG domain does not, by itself, align with a company-domain From address.

For custom company domains, the documented route is to open a UKG Support case and list the domains and any subdomains that need DKIM signing. UKG also describes support-assisted non-spoofing options that vary by product. One option rewrites company-domain From headers to a UKG address; the documented rewrite has broad scope across the affected company-domain mail and does not create a mailbox. Confirm its exact impact and reply behavior before approving it. It is not equivalent to enabling your company's DKIM signature. Custom DKIM and alternative sender options.

Prepare a domain-specific Support request

Use your authorized UKG Support process through UKG Community or the UKG support entry point. Include the product, notification route, tenant context, intended From domains and all subdomains. Ask Support to confirm:

1. Whether the desired company-domain sender is supported for this specific route.
2. The expected MAIL FROM domain and whether your DNS needs the published SPF authorization.
3. The exact DKIM record types, full owner names and public values or targets for each domain.
4. The intended signing d= domain and all selectors, including any rotation records.
5. Any account-side activation steps, who performs them and how readiness is confirmed.
6. Which message classes the configuration covers and which require separate setup.

The current public workflow does not publish a universal customer selector, record type, key or self-service activation screen. Obtain those details from Support. Do not infer them from a UKG-owned domain, another customer or a generic Kronos “Mail Signature” guide. Do not generate and email a private signing key merely because an older third-party recipe describes it.

The product owner, DNS administrator and email administrator should agree on the change and recovery plan. Save the current DNS values, TTLs, sender settings and effective DMARC policy. Identify the active authoritative DNS provider and any delegated subdomain owner. Preserve existing mailbox MX records, other senders' SPF authorizations and DKIM selectors.

No employee record, onboarding document, payroll detail or real new-hire message is required to request public authentication values. Reserve a controlled, approved test route that does not trigger a real employment process.

Add SPF only to the correct envelope policy

UKG's published mechanism for the documented native SaaS route is:

include:_spf.ultipro.com

This is a mechanism to merge, not a complete replacement SPF record. UKG's documentation also lists regional IP alternatives, but its include is the maintained domain-based option. Do not convert it into a static IP list or mix in unrelated UKG services. Confirm the current route with Support. Official SPF source.

SPF checks the connecting sender IP against the SMTP MAIL FROM domain, not the visible From address. A policy at example.com is not inherited by hr.example.com. If UKG uses a provider-owned envelope domain, editing your root SPF will not change that envelope's SPF result or make it align. Obtain the actual identity before choosing a DNS owner. SPF rules.

At the confirmed customer-controlled envelope owner:

• Retrieve the existing TXT records and identify the one beginning v=spf1.
• If a policy exists, merge the authorized mechanism before its terminal all, preserving approved senders and the established qualifier. Do not create a second SPF policy.
• If no policy exists, have the domain owner assemble one that accounts for every legitimate sender at that owner. Do not invent a universal replacement based on this single application.
• Check for existing aliases or other ownership constraints before adding data. A CNAME owner cannot also carry ordinary TXT or MX data.
• Validate syntax and the complete evaluated lookup path before deployment.

The SPF limit is ten evaluated DNS-querying terms across nested include, a, mx, ptr, exists and redirect, not ten top-level includes or ten DNS packets. ip4, ip6 and all do not count toward that term budget. Separate MX-address bounds and void-lookup limits apply; RFC 7208 recommends limiting void lookups to two. A record that looks short can still produce permerror through nested dependencies.

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.

Publish the DKIM batch and confirm activation

Publish only the public DNS records UKG issues for your actual domains. Preserve each record's type, complete owner, selector and target or value. If a supplied name is occupied by another service, stop and have Support and the DNS owner resolve it. Do not delete that service's key or improvise a selector.

For an illustrative owner SELECTOR._domainkey.hr.example.com, the DNS entry depends on the authoritative zone:

A full-name editor may require the complete FQDN instead. This table explains DNS structure, not UKG's selector format. Check the final published name for duplicated suffixes. Locate the authoritative zone separately for any envelope-domain record. Do not create a delegation solely to match this example. DNS zones and aliases.

If UKG issues CNAMEs, keep them DNS-only and ensure flattening does not hide their alias responses. For Cloudflare, check both record-level flattening and the zone-wide flatten-all setting; DNS-only alone is not sufficient. Coordinate changes without disturbing unrelated website records. If UKG issues TXT public keys, preserve the entire value and let the DNS provider handle permitted TXT string segmentation. Never publish a private key. Cloudflare flattening, proxy status, DKIM key lookup.

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.

Publishing a key does not activate signing in UKG Pro. Follow the account-specific Support instructions, confirm all required records resolve publicly and ask Support to confirm that signing is enabled for each domain and route. Do not invent an activation button or assume a sender-address edit performs this step.

Preserve DMARC and evaluate alignment

DMARC passes through aligned SPF pass or aligned DKIM pass. Relaxed alignment compares organizational domains as determined by DMARC policy discovery; strict alignment requires exact domain equality. For example, From hr.example.com and DKIM d=example.com align in relaxed mode but not under adkim=s. A passing d=ultipro.com signature does not align with either company domain. Current DMARC standard, RFC 9989.

Inspect _dmarc at the exact From domain and the applicable parent policies. No record at a child name does not mean no policy applies. Retain established p, sp, np, alignment modes and approved report destinations. Do not publish a child p=none to bypass inherited quarantine or reject enforcement.

Only when no effective direct or inherited policy exists, the owner has considered the domain's other senders and monitored deployment is approved, a first policy can take this form:

Before publishing that first policy, obtain the domain owner’s explicit approval of the monitoring and review plan. For a full apex owner _dmarc.example.com, the relative owner in the example.com zone is _dmarc; use the complete name where the editor requires it. Keep existing direct and inherited policies unchanged.

Owner: _dmarc.FROM_DOMAIN
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS

Replace placeholders before use. For root From example.com, the appending root zone uses owner _dmarc. For From hr.example.com, use _dmarc.hr in the parent example.com zone, or _dmarc in a separately delegated hr.example.com zone. A full-name editor uses _dmarc.hr.example.com. Publish one policy, not a second competing record.

Use an operational, approved reporting destination. When its organizational domain differs from the policy domain's, the receiver of the reports must authorize them in its own DNS, normally at POLICY_DOMAIN._report._dmarc.REPORT_DESTINATION_HOST with v=DMARC1, or through a permitted wildcard. Follow the reporting service's exact instructions. Publishing that authorization in the company's sending zone does not substitute for the destination's consent. Consider report privacy; do not add message-level failure reporting casually. Aggregate reporting and authorization.

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.

p=none is not a delivery guarantee. RFC 9989 supersedes RFC 7489 and removes pct; do not rely on it for percentage rollout. Section 7.4 requires valid DKIM for domains publishing p=reject and cautions against reject policies for general-purpose mail. Account for forwarding and lists before any domain-wide enforcement decision.

Verify DNS and a newly delivered message

Use the actual names from Support. These are checks for your administrator to run, not reported test results:

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN TXT +noall +answer
dig @1.1.1.1 DKIM_OWNER_FQDN TXT +noall +answer
dig @1.1.1.1 MAIL_FROM_DOMAIN TXT +noall +answer
dig @1.1.1.1 _dmarc.FROM_DOMAIN TXT +noall +answer

For a CNAME-based batch, also query the exact owner with type CNAME and verify its target. A recursive TXT lookup follows aliases to the public key; an authoritative-only response may show only the alias. Check every issued selector, each relevant authoritative zone and applicable parent DMARC policy. Expect the supplied values, no missing or conflicting records, and consistent public responses. Do not mistake a wrong authoritative owner for ordinary cache delay.

When inspecting delivered signatures, keep each actual d= and s= pair together. EmailAuth’s DKIM selector guide explains that lookup; it does not supply UKG’s account-specific records or replace Support activation.

After UKG confirms activation, have an authorized administrator send a harmless message through the specific supported test path to a controlled recipient. Do not launch a real hire, transmit payroll data or trigger employee notifications merely to test authentication. Repeat for each From domain and materially different message path.

Obtain raw headers through the receiving service and use receiver-controlled authentication diagnostics or a mail trace that identifies its own results. Alternatively, have the receiving-mail administrator establish the trust boundary, including how externally supplied Authentication-Results are removed or distinguished from locally generated results. Match the documented authserv-id only within that boundary. A familiar name such as mx.google.com, or the first header in a message, is not proof by itself. If you cannot distinguish the receiver's result from sender-supplied text, do not accept it as commissioning evidence. RFC 8601 section 7.1.

For a company-domain DKIM setup, require all of these:

1. The intended company-domain From, without an unexpected rewrite.
2. dkim=pass for the intended company-controlled d= and an issued selector, aligned under the effective adkim mode.
3. dmarc=pass for that From domain.
4. The actual smtp.mailfrom and SPF result recorded, with errors or failures investigated rather than dismissed because DKIM passed.
5. Receipt and expected product behavior checked separately from authentication.

Aligned SPF alone may pass DMARC, but does not prove the requested custom DKIM setup works. For a deliberately approved UKG-domain sender, evaluate the provider-domain identities instead; do not label that result company-domain authentication. Test direct delivery before assessing forwarding or list behavior, then use available aggregate reports to monitor recurrence. Reports are not a complete view of every message or receiver.

Troubleshoot without weakening the domain

For rollback, coordinate with the product owner and UKG Support before pausing or changing essential notifications. Restore the saved valid configuration where appropriate, keeping DNS and the active signing key synchronized. Retain old public keys as needed for queued or in-flight messages. Do not disable DMARC, erase other senders or broadly allow all UKG-branded traffic. Retest the repaired route before resuming normal operation.

Documentation and verification boundary

The guide uses current public UKG documentation and protocol standards, with account-specific provisioning left to UKG Support. No customer account was accessed, DNS changed, message sent, delivered customer header inspected or live implementation verified. Successful authentication does not guarantee inbox placement.