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

By default, iCIMS sends email on behalf of your organization using iCIMS’s own mail infrastructure. If you have not configured SPF, DKIM, and DMARC records for your sending domain, recipient mail servers will see the message as coming from “via icims.com” or “on behalf of icims.com.” That flag triggers spam and junk filters in most corporate email environments, especially Microsoft 365 and Google Workspace.

Candidates report never receiving interview invitations, status updates, or offer letters. Hiring managers see rejections not being communicated. From inside iCIMS, emails show as “Sent” but they are sitting in junk folders the recipient never checks.

Have a team member send a test email to themselves through iCIMS. Check whether the email arrives, and if it does, look at the headers. If the “From” field shows “via icims.com” or “on behalf of icims.com,” authentication is not properly configured. You can also use a tool like Stellastra’s deliverability analyzer to test whether iCIMS emails from your domain are passing SPF, DKIM, and DMARC.

iCIMS has a dedicated guide (in the iCIMS Community under “Configuring Email Authentication”) that walks through setting up your own DKIM keys. You will need to add a DKIM TXT record to your domain’s DNS settings that authorizes iCIMS to sign outbound mail as your domain. You also need to add iCIMS’s sending IP ranges to your SPF record. Once both are in place and DMARC is set to at least “p=none” for monitoring, the “via icims.com” indicator disappears and deliverability improves significantly.

When an outbound email to a candidate bounces (for any reason: a typo in the address, a temporary server issue, or a full inbox), iCIMS marks that email address with a “bounced” or “invalid” status on the candidate’s profile. Once flagged, iCIMS stops all future outbound email to that address automatically. It will not retry or warn you when you try to send again. The send appears to go through, but nothing is delivered.

This affects a single candidate rather than your whole organization. Recruiters will notice that one specific person never responds to emails. It is easy to misread this as a candidate ghosting when the real problem is a suppressed email address.

Open the candidate’s Person Profile in iCIMS. Navigate to the Email tab. Look for a visual indicator on the email address field, such as a red or orange flag, a “bounced” label, or a status note. iCIMS also has a dedicated admin article called “Resetting a Candidate’s Email Status” in the community that describes what the flag looks like in your specific instance version.

If the email address is correct and the bounce was temporary, you can reset the email status directly from the candidate’s profile if your login group has that permission. If you do not see a reset option, submit a support request to iCIMS. They can clear the bounce flag on the back end. If the email address itself was wrong, update it first, then reset the status, and re-send your email.

iCIMS does not automatically email candidates when they move through workflow statuses. Each status step in a Workflow Profile has an optional Auto Notification field where you attach an email template. If that field is empty, no notification fires when a candidate enters that status. Many teams assume the system sends some kind of default notification. It does not.

Candidates never hear back after they apply, after interviews, or after decisions are made. This is the most common root cause of the “candidate said they never heard from us” complaint. It’s also one of the biggest drivers of poor candidate experience scores.

Go to Admin, then Workflow Profiles. Open the workflow profile used for the job in question. Click into the specific status step where a notification should fire. Look for the Auto Notification setting. If it says “None” or is blank, no email will send when a candidate reaches that status.

Create or choose an existing email template that is appropriate for that status, then assign it to the Auto Notification field on that step. Do this for every status where a candidate-facing or internal notification is expected. This is a configuration step that should be part of every iCIMS implementation setup, but it is often skipped or left incomplete.

iCIMS gives each user a Notification Profile that controls which system-generated events trigger an email to that user. If a hiring manager is not receiving alerts when new candidates apply, it is often because their Notification Profile does not have “New Applicant” alerts enabled. This is separate from the Auto Notification on the workflow step. Notification Profiles govern internal user alerts, not candidate-facing emails.

Hiring managers miss new applicants. Recruiters don’t get alerted when candidates complete assessments. Offer approval owners don’t know a request is waiting. The work is in the system, but the right person doesn’t know about it.

Go to Admin, then User Management. Find the specific user. Look for their assigned Notification Profile. Open that profile and review which notification events are enabled. Compare against what the user says they should be receiving.

Edit the Notification Profile to enable the missing event types, or assign the user to a different Notification Profile that includes the events they need. If multiple users have the same gap, update the shared Notification Profile rather than fixing them individually. Note that changes to Notification Profiles affect all users assigned to that profile.

Some iCIMS notification events are routed to the “Hiring Manager” field on the Job Profile. If that field is blank, or if it still lists a former employee who no longer has an active iCIMS account, the notification fires but has no valid destination. From the system’s perspective, everything worked. But no one received the email.

This is especially common on high-volume requisitions where jobs are cloned from a template. If the template had a placeholder or a departed employee in the Hiring Manager field, every cloned job inherits the problem silently.

Open the Job Profile for the specific requisition. Check the Hiring Manager field. Confirm it contains an active iCIMS user. Then verify that user’s account is still active and their Notification Profile includes new applicant alerts (per Cause 4).

Update the Hiring Manager field with the correct active iCIMS user. If this is happening across many jobs, it is worth running a report to identify all jobs with empty or inactive Hiring Manager assignments. This is a data quality issue that our iCIMS system audit process catches as a standard finding.

iCIMS login groups control not just what users can see and do in the interface, but also what system-generated notifications they are eligible to receive. Certain notification types in iCIMS are permission-gated. If a user’s login group does not include the permission for a specific event type, those notifications will not be delivered, even if the Notification Profile has them enabled. The two systems must align.

This is the hardest cause to diagnose because the Notification Profile looks correct. Everything appears to be turned on. But emails still don’t arrive. The gap is invisible unless you know to check login group permissions specifically.

Identify the user’s assigned login group in Admin, then User Management. Open the login group settings and review the Notification or Email-related permission categories. Compare against a user who is receiving the same type of notification successfully. The difference in permissions is your culprit.

Add the missing permission to the user’s login group. If you are not comfortable editing login groups, work with your iCIMS admin or engage your iCIMS consulting team to identify the exact permission and make the change safely, since login group edits affect everyone assigned to that group.

In iCIMS Workflow Rules, you can configure an action that sends an email when a candidate reaches a specific status. But the action has two modes: Prompt and Auto-Launch. A Prompt action pauses the workflow, surfaces a task to the recruiter, and waits for them to confirm before sending. An Auto-Launch fires the email immediately, without human intervention. If your rule is set to Prompt and recruiters are not completing those tasks, the emails simply never go out.

Automations that look fully built are doing nothing. Teams assume the system is sending rejection emails, interview confirmations, or offer communications, until a candidate or manager points out they never received anything.

Go to Admin, then Workflow Profiles. Open the relevant workflow and find the rule that should be triggering the email. Check whether the action type is listed as “Prompt” or “Auto-Launch.” Also check the recruiter’s task queue: if you see a pile of unactioned tasks related to email sends, that is confirmation this is the issue.

If the email should send without manual confirmation, change the action type from Prompt to Auto-Launch on the workflow rule. If you want recruiters to review and personalize the email before it goes out, Prompt is the right setting, but you need to train recruiters to action those tasks promptly. Our guide to iCIMS workflow rules not triggering covers additional scenarios where rules appear to fire but produce no visible output.