For a US-based Everbridge Suite account with the Custom From Email feature, an administrator can add a custom domain at Account level, obtain its issued DNS instructions, wait for Active status, then save an approved custom sender at Organization level. This is separate from changing a display name or Reply-To address.
This guide covers native Everbridge Suite email Notifications and Communications on that documented US route, with SPF already configured and approved for the actual sending path. It does not establish an SPF include for a new route, extend custom DKIM to EU accounts, or promise that every system-generated message uses the custom signature. Confirm feature eligibility before beginning. Everbridge Suite User Guide, October 2026, pages 784–788.
Important source discrepancy: the manual labels the issued fields CNAME Name and CNAME Value and shows an alias in its interface, but one publication sentence says to create a TXT record. Do not guess which instruction to follow. Proceed only when the current account’s Instructions explicitly establish the actual record type, full owner and target. If they remain contradictory, ask Everbridge to clarify before publishing or activating the domain.
No customer account, DNS change, notification send or receiving-mailbox test was performed.
Confirm the product, account and change boundary
Use an authorized administrator for the existing US Custom From Email feature. Do not interpret the ability to change a From display name as proof that custom-domain signing is enabled. A default Everbridge-domain signature is also not evidence that your own brand domain is authenticated.
Record the exact Account, Organization, intended notification module, domain, authorized sender address and existing default. The manual separates Account-level domain provisioning from Organization-level sender selection. It also allows a sender choice within an individual Communication, so inspect that selection rather than assuming every message follows the Organization default.
Check the current entitlement with Everbridge if your account lacks the documented controls. This guide does not authorize feature purchases, role escalation, account migration or a change to emergency-notification policy. It does not configure SMS, voice Caller ID, inbound mail processing or relay connectors.
Obtain approval for the visible From identity and any default change. Keep an authorized mailbox for replies where required; a Reply-To setting controls replies, not DKIM alignment. Preserve working sender identities until the new path has been verified and its operational use approved.
Establish the SPF prerequisite without guessing a record
The reviewed manual recommends an SPF entry associated with everbridge.net, but does not provide enough detail to prescribe a universal include mechanism, record owner or envelope identity. This guide therefore assumes that the exact route’s SPF configuration has already been approved and verified. If it has not, obtain the current provider-specific requirements from Everbridge before proceeding. Do not turn a domain mentioned in prose into a guessed include: directive.
SPF evaluates the SMTP MAIL FROM domain, not automatically the address displayed in From. On a received message, record that actual envelope identity and compare it with the intended policy owner. An SPF pass for a provider-owned domain is not proof of alignment with your custom From.
Maintain one v=spf1 TXT policy at each applicable owner. Preserve existing authorized senders and policy qualifiers. Parent-domain SPF does not automatically cover a child domain. The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. If an all mechanism exists, redirect is ignored; placing another authorization after all does not make it effective. Do not remove unrelated senders, add a duplicate policy or copy a guessed IP list to make a checker pass. SPF processing rules.
The existing SPF prerequisite does not eliminate delivered-message checks. A valid-looking DNS record and an actual message’s authenticated identity answer different questions.
Add the domain at Account level
At Account level, open Settings > Notifications > Sender Information. Enter the approved domain in Custom Domain, then select Add Domain. The table displays the generated CNAME Name, CNAME Value, Status and creation information. Open its Instructions link and obtain the complete current publication requirements. Account provisioning and domain states, pages 784–786.
Use the domain already approved for this sending route. The manual identifies separate errors for an invalid domain format, a domain that cannot be found, a domain already in the account, and a domain mapped to another Everbridge account. It says domains cannot be shared across accounts. Do not delete or transfer another account’s mapping as a troubleshooting shortcut.
Copy the issued fields exactly. A sample selector, token or destination in the manual belongs to the example, not to your organization. Do not generate a replacement key in an unrelated tool or ask anyone to send a private key.
Resolve the CNAME-versus-TXT discrepancy before making a change. If the current account confirms a CNAME, publish that exact alias owner and target; do not put the target hostname inside a TXT value. If the current Instructions specify a different record or disagree with the table, stop for provider confirmation. This is a real source conflict, not permission to publish both types at the same owner.
Map the issued DNS record safely
Identify the authoritative zone, which may not be managed by the registrar or website host. Save the existing approved records and check dependencies at the proposed owner before publication.
For a hypothetical full owner selector._domainkey.alerts.example.com, an editor managing example.com may require selector._domainkey.alerts; an editor managing a separately delegated alerts.example.com zone may require selector._domainkey. If the _domainkey namespace itself is delegated, use its actual authority. These are mapping examples, not Everbridge selectors. Avoid creating a name with the domain appended twice. DNS zones and delegation.
A CNAME owner cannot also hold ordinary TXT, A, AAAA, MX or another CNAME record. Do not erase an existing dependency, selector or delegation to clear a conflict. Obtain a supported resolution from the responsible DNS administrator and Everbridge. Never change root mail routing or nameservers just to fit a tutorial. DNS record representation.
Where an issued CNAME must remain visible to the validator, do not route it through an HTTP proxy. For Cloudflare, check DNS Only and the applicable flattening behavior. Per-record, zone-wide, apex and same-zone settings can affect the literal answer. Turn off a relevant per-record Flatten option only when available and appropriate; do not make blanket zone changes. If unavoidable behavior prevents the required answer, ask for a supported configuration instead of removing a delegation or inventing a switch. Cloudflare flattening controls.
Wait for Active, then select the approved sender
The manual describes Pending while Everbridge awaits the DNS record and Active after verification succeeds. Compare the actual authoritative answer with the current Instructions if the domain remains Pending. Check owner, type, target, authority and cache lifetime before merely waiting longer. Do not claim a particular propagation deadline that the source does not establish.
After the domain is Active, move to the intended Organization’s Settings > Notifications > Sender Information. Select Custom, enter the authorized local part and choose the newly configured domain, then Save. The screenshot places these controls under Sender E-Mail Address; the nearby Sender E-Mail Display is the reader-friendly name, not the authenticated address. Confirm the saved address before use. Organization sender selection, pages 786–787.
The documented feature supports up to ten custom sender addresses, with a default selection. Changing the default can affect future communications and requires the owner’s approval. When a Communication offers its own sender choice under Settings > Sender Information, select the approved address for that specific message.
Do not confuse an Organization-level Save with an actual successful signature. Account DNS status, saved sender configuration and recipient authentication results are three separate checks.
Preserve existing DMARC protection
Inspect both direct and applicable inherited DMARC policy for the intended From domain. An empty query at one _dmarc name does not establish that no policy applies. Preserve existing enforcement and approved reporting recipients. Do not introduce a weaker child policy, add duplicates or replace quarantine or reject with none to get a green status.
Only if no direct or inherited policy applies, the owner approves and a monitored introduction is appropriate, an initial TXT policy may be v=DMARC1; p=none. For From alerts.example.com, its full owner is _dmarc.alerts.example.com, entered as _dmarc.alerts in the parent zone or _dmarc in a separately delegated child zone. This minimal example does not request reports and is not an Everbridge-issued requirement. Do not use obsolete pct as a rollout mechanism. Current DMARC standard.
If aggregate reports go to a different Organizational Domain from that of the domain where the policy was found, the reporting receiver must check DNS authorization. A destination within the same Organizational Domain is excepted. That check does not replace the owner’s privacy and data-sharing approval. Do not copy someone else’s report addresses. Aggregate-report authorization.
Verify without triggering an operational alert
Use only a harmless, explicitly approved test of the intended native email path to a controlled recipient. Do not use emergency-alert groups, start a live incident broadcast, select real operational audiences or enable SMS/voice channels merely to test DKIM. If the account cannot isolate such a test safely, arrange one with its authorized administrator or Everbridge instead.
Obtain the recipient’s original message and authentication results generated within the receiving service’s known processing boundary. Consult that service’s documented treatment of external Authentication-Results or obtain an administrator trace. A familiar authserv-id, header position or copied result alone is not trustworthy; disregard attacker-injected fields. Authentication-Results trust rules.
Record the actual From, SMTP MAIL FROM, intended Everbridge DKIM signing domain d= and selector s=, and trusted SPF, DKIM and DMARC results. Accept this custom-domain setup only when the intended signature passes and aligns with the intended brand From, alongside dmarc=pass, Active status and the correct saved sender. A fallback provider From or unrelated passing signature does not meet that goal.
DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires exact equality. A child envelope domain can align relaxed but fail strict alignment. A DMARC pass through SPF does not prove your intended DKIM works. See raw DKIM versus aligned DKIM results.
Investigate SPF fail, temporary lookup errors and permanent policy/lookup-budget errors separately, even when aligned DKIM makes DMARC pass. Keep message evidence private. Authentication does not guarantee delivery, inbox placement or the reliability of an emergency-notification process.
Troubleshooting and recovery
Active domain, wrong sender: inspect the Organization address, approved default and per-Communication selection. Do not mistake a display-name edit for a custom address change.
Existing custom From, no provisioned key: the manual describes a warning banner for this state. Follow the documented domain-provisioning process rather than assuming an older custom From was already branded DKIM.
Pending despite correct DNS: retain the exact account Instructions and authoritative answer, then ask Everbridge to investigate. Do not cycle through TXT and CNAME guesses.
Signature passes but does not align: compare d= with the actual From under the effective alignment mode. Preserve your policy and intended brand rather than accepting provider-domain signing as equivalent.
Signature fails after processing: investigate key selection and downstream changes with the responsible administrators. Do not disable required security or compliance controls to preserve a signature.
Do not use Renew or Delete as harmless refresh buttons. Renew regenerates keys and requires another DNS update. Deleting an in-use domain removes its mapping and causes notifications to revert to the provider address. Preserve queued-message dependencies and old selectors until an approved migration is complete. Key renewal and deletion consequences, page 786.
For a regression, pause the affected test or workflow only where operationally safe and coordinate recovery with its owner. Do not silently interrupt a critical-alerting service. Supply support only necessary redacted domain, selector, status and diagnostic information, not credentials, private keys or operational recipient lists.