Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Abnormal Security is now branded Abnormal AI. Its November 4, 2026 release introduces custom sender domains for AI Phishing Coach. That is a concrete sending workflow with domain authentication; it should not be confused with deploying inbound email protection. This guide covers the newly documented custom-sender feature and a controlled verification plan, not a universal SPF include for every Abnormal product.
Check that the feature matches your task
The official rebrand announcement establishes the current company identity. The custom-sender release covers simulations, coaching, training and related communications sent from an organization-controlled domain or subdomain. It states that the portal generates SPF, DKIM and DMARC records, verifies the domain and supports a test email with the chosen sender name and address.
The linked configuration article returned no readable procedural text in the public web read on 8 November 2026. Accordingly, exact menu labels, tenant eligibility, record types and generated values are not asserted here. Open that linked guide from your authenticated support context and confirm availability before scheduling DNS work. If the task is an alert from a different Abnormal feature, first establish that feature's supported sender configuration instead.
Prepare a bounded sender identity
Choose a domain or subdomain the organization controls and approve the exact From identity. A dedicated training subdomain can make ownership and retirement easier, but it is not a guarantee of reputation isolation. Inventory existing DNS and any mail already using that name. Record the platform administrator, DNS operator and awareness-program owner.
For simulations, separately authorize the audience, schedule and content. A successful authentication test does not authorize a phishing exercise or justify broad mail-security bypasses. Start with a controlled recipient and innocuous content, without collecting passwords or sending unapproved simulations to employees.
Review the generated records before publication
References: RFC 7208 §3.2, RFC 9989 §4.10, RFC 1034 §3.6.2.
Use the feature's generated record set, not values copied from an older third-party article. Capture each full DNS owner, type, value, purpose and applicable domain. If SPF already exists at the proposed owner, maintain one valid policy and preserve legitimate senders. If DMARC already exists, resolve whether the proposed change would replace an enforcement policy or reporting destination. Do not create a second DMARC record to satisfy a wizard.
For DKIM, publish only the generated public verification record or alias, never a private key. If a CNAME owner is occupied, resolve the conflict before proceeding. Translate full names into your DNS editor's required label format without duplicating the domain suffix. Keep the generated values and actual published answers together as the change record.
Separate portal verification from received evidence
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Run the portal's domain verification after publication, then query the exact owners at the authoritative DNS service. If verification remains pending, first compare the expected name and record type with the authoritative answer. Only after those match should you investigate recursive caches or a provider-side validation delay. Do not generate replacement keys repeatedly while the first record is still being diagnosed.
Use the supported test-email feature to the approved mailbox. Record the visible From, SMTP envelope domain, every DKIM d=/s= pair and trusted receiver results. Determine whether at least one passing SPF or DKIM identity aligns with the visible From under the effective DMARC mode. A message can pass SPF for a service-owned envelope while relying on aligned DKIM for DMARC.
Illustrative acceptance plan: approve a coaching sender on training.example.com, publish the portal's exact records, then verify one harmless test message from that identity. The domain, message and result in this example are invented; they are not evidence of a real Abnormal deployment.
Maintain the feature as a sending dependency
If verification fails, pause the rollout and preserve the generated records, DNS answers and test headers for support. Restore only an approved previous configuration; do not weaken the organizational DMARC policy as a shortcut. Recheck after feature updates, sender-domain changes and DNS migrations. When retiring the feature, confirm campaigns and queued communications have stopped before removing its authentication dependencies. The evidence here is documentary; account-specific steps and a real message remain implementation checks.