ICIMS Email Notifications Not Working: 7 Causes and How to Fix Each One

Most organizations want ICIMS email to come from their own address, such as recruiting@yourcompany.com. ICIMS supports this once your domain is authenticated. That means publishing a pair of DKIM CNAME records that ICIMS provides (ICIMS hosts the key and rotates it for you) and having a DMARC policy on the domain. A policy of p=none is enough to meet the requirement. Adding ICIMS to your SPF record is optional. Until every check passes, ICIMS keeps sending from its own system address instead of yours.

This shows up in two ways. Before setup is finished, candidates receive email from a system address they don’t recognize and may ignore it or filter it out. After setup, a later DNS cleanup or email platform migration can remove the records, and mail from your domain starts failing authentication and landing in junk folders.

Send a test email from ICIMS to an outside mailbox you control. First check the From address: if it shows an ICIMS system address rather than yours, your domain isn’t in use yet. Then open the message headers and look for dkim=pass and dmarc=pass in the authentication results. Ask IT to confirm the ICIMS CNAME records and your DMARC record still exist in DNS.

Open a request with ICIMS Technical Support and name every domain you want to send from, because keys are issued per domain. Have IT publish the CNAME records ICIMS returns, confirm a DMARC record is in place, and optionally add include:_netblocks.icims.com to SPF. Ask IT to allow ICIMS’s published IP addresses and domains through your own mail gateway as well, so internal notifications to recruiters and hiring managers aren’t quarantined. ICIMS updates that list over time, so IT should recheck it periodically.

When an email to someone bounces, whether from a typo, a full mailbox, or a temporary server problem, ICIMS sets that person’s email status to Bounced. From then on they are left out of mass emails and appointment invitations until the status is reset. You can still email them individually, which is why the problem is easy to miss.

It affects one person at a time. A candidate misses a bulk status update or never receives an interview invitation, and it looks like they stopped responding when the address was simply excluded.

Run a Candidate search (Search > Person > Candidate) and add the Email Status filter from the Contact tab, set to Bounced. If the candidate appears in the results, this is your cause. Saving this search and reviewing it regularly catches bounced addresses before they cost you an interview.

Correct or confirm the email address first. Then select the candidate in the search results and choose Reset Email Status from the More menu. By default only user admins can reset email status, so route these requests to your admin. If you reset without fixing the address, the next email bounces and the status returns to Bounced.

Status-driven candidate emails in ICIMS are usually built with auto-launch actions, which are configured on each recruiting workflow status. A Compose Email auto-launch action opens an email to the candidate as soon as a user moves them into that status, and the Mail Template for Auto-Launch setting preloads the right template. If a status has no email action, or the action has no template, nothing prompts the recruiter and the email depends on someone remembering to send it.

This is a frequent source of the “candidate says they never heard from us” complaint, especially after interviews and rejections. It also drags down candidate experience scores.

Go to Admin > System Configuration > Applicant Tracking > Workflow and edit Recruiting Workflow Bins and Statuses. Select the status in question and review its Auto-Launch Action and Mail Template for Auto-Launch settings. Status options can be set differently for different user groups, so check the configuration for the group your recruiter belongs to.

Set the status’s auto-launch action to the appropriate Compose Email action and select a template in Mail Template for Auto-Launch. Repeat for every status where a candidate should hear from you. This belongs in every ICIMS implementation plan, and it is worth revisiting whenever statuses are added or renamed.

An auto-launch email action opens a pre-filled message for the recruiter to review and send. It doesn’t send on its own. If the recruiter closes the window or moves on, the status change still saves but no email goes out. A second, related case: if the status is flagged for Delayed Email, the message is held and sent according to your delayed email settings, which can look like a failure to someone testing in real time.

The workflow looks fully built, yet whether candidates hear from you depends on each recruiter completing every email window. Under volume, some get skipped.

Sit with a recruiter and have them move a test candidate into the status. Confirm the email window appears and watch what happens to it. Then check whether the status has Delayed Email turned on, and review the timing under Admin > System Configuration > System > Notifications > Delayed Email Settings.

For statuses where the email must go out, turn on Auto-Launch Required. The recruiter then has to send the email to complete the status change. Add an Auto-Launch Prompt with a one-line instruction so the expectation is clear, and include the step in recruiter training. Our guide to ICIMS workflow rules not triggering covers related cases where a status change doesn’t produce the result you expect.

Teams often expect ICIMS to email a hiring manager when a candidate is submitted for review, or a recruiter when someone applies. Hands-off emails like these are Event Notifications. Each one has a trigger (a candidate moving into a specific status, an iForm being updated or completed, or a career portal application being finished), optional conditions such as department or hiring manager, and one or more recipients. Event Notifications are configured with ICIMS Technical Support rather than in the admin screens. Candidate-facing portal emails, such as the confirmation a candidate receives after applying, are separate: user admins turn those career portal notifications on or off and edit them in System Configuration.

People wait for alerts that were never built. Hiring managers miss candidates, recruiters miss completed forms, and the gap is often blamed on email delivery when nothing was ever triggered.

List every alert your team believes happens automatically. Compare that list with the Event Notifications actually in place for your organization. If no one has that documented, open a case with ICIMS Technical Support to review what is configured. If candidates say they never received an application confirmation, check that the career portal notification is turned on.

For each missing alert, define the trigger, the conditions, the recipients, and the message, then submit it to ICIMS Technical Support. Where possible, use relational recipients, such as the hiring manager on the job, so the alert follows whoever owns the requisition instead of a fixed address.

Alerts that go to “the hiring manager on the job” rely on the Hiring Manager field on the Job profile. If that field is blank, or still points to someone who has moved on, the alert has no one to reach.

This is especially common when jobs are created from a template. If the template carries a placeholder or a former employee in the Hiring Manager field, every job built from it inherits the gap.

Open the Job profile and check the Hiring Manager field. To find the problem across many jobs, run a Job search with Hiring Manager as a column and look for blanks and names that should no longer be there.

Update the field on affected jobs, then correct the job templates so new requisitions start with the right owner. Reviewing hiring manager assignments is a standard part of our ICIMS system audit.

ICIMS users receive in-system notifications in the Notifications Center, with email as an optional second channel. These cover events such as being @mentioned in a profile note, interviews being scheduled, rescheduled, or canceled, and candidates responding to offers on their jobs when Offer Management is in use. Each user decides which of these also arrive by email, and those preferences belong to the individual rather than the admin.

A recruiter or hiring manager reports that ICIMS “stopped emailing them.” The notifications are still arriving. They are just in the Notifications Center instead of the inbox.

Ask the user to open the Notifications Center from the menu bar. If the notification is there but no email arrived, their email preference for that type is off. In-system notifications expire after 28 days, so check soon after the event.

Have the user turn email back on for the notification types they rely on. Because admins can’t set these on someone’s behalf, add a short preferences step to recruiter and hiring manager onboarding.