Summary
Inbound email reporting turns an email into a KC Safety incident automatically. You enable it for your account, choose an intake address, and point that address at KC Safety through your email provider. Anyone who can send an email to that address can file a report, without signing in to KC Safety.
Introduction
Not every reporter has a KC Safety account, and not every report starts in the portal. A contractor on site, an employee replying from a phone, or an existing internal mailbox that already collects safety concerns all represent reports that would otherwise be re-typed by hand.
Inbound email reporting closes that gap. KC Safety accepts parsed inbound email and creates an incident from it, matching the sender to an existing user where it can and creating an anonymous incident where it cannot. This is the main way to get incident data into KC Safety without a login.
Setting this up involves both KC Safety settings and DNS or email-provider configuration, so you will need administrator access to your account and to the domain you intend to receive mail on.
Key Concepts
- Intake address — the email address that reports are sent to. You choose this address when enabling the feature.
- Inbound parse — the email-provider service that receives a message on your domain and forwards its parsed contents to KC Safety. KC Safety uses SendGrid Inbound Parse for this.
- MX record — the DNS record on your domain that directs incoming mail to the parse service.
- Sender matching — KC Safety compares the sender's address against your users and links the incident to that user when it finds a match.
- Anonymous incident — the incident created when the sender does not match a known user; the report is still recorded, without an attributed reporter.
- Signature verification — inbound deliveries are verified before being accepted, so only genuine messages from your configured parse service create incidents.
Steps to Follow
Step 1: Enable Email-in Reporting
Sign in as an administrator and go to Admin Panel → Settings → General → Email-in Reporting. Turn the feature on. It is enabled per account, so this affects only your own KC Safety account.
Step 2: Choose the intake address
Set the intake address that reports should be sent to. Pick something recognizable that you are willing to publish internally, for example a safety or incidents mailbox on a domain you control, and note it down for the next step.
Step 3: Configure inbound parse and your MX record
On your side, configure SendGrid Inbound Parse for the domain or subdomain that hosts your intake address, and add the MX record that directs mail for that domain to the parse service. This is what causes a message sent to your intake address to be delivered to KC Safety rather than to an ordinary mailbox.
KnowledgeCity provides the signing key used to verify inbound deliveries. Request it as part of setting this up and configure it alongside the parse settings.
Note: Inbound deliveries are signature-verified and fail closed in production. If the signing key is missing or a delivery cannot be verified, the message is rejected rather than accepted — so an incorrect or absent key results in no incidents being created at all, rather than unverified incidents slipping through. If reports stop arriving after a change, check the signing configuration first.
Step 4: Understand how reports are attributed
When a message arrives, KC Safety compares the sender's email address against the users in your account:
- If the sender matches a known user, the incident is linked to that user as the reporter.
- If the sender does not match, KC Safety still creates the incident, but as an anonymous incident with no attributed reporter.
This means a report is never lost because the sender is unknown, but attribution depends on the sender writing from the address recorded on their KC Safety user account.
Step 5: Test the address end to end
Send a message to the intake address from an address that matches a known user, and confirm the incident appears in KC Safety with that user as the reporter. Then send one from an address that does not match any user, and confirm an anonymous incident is created. Testing both paths verifies your DNS, parse configuration, and signing key are all correct.
Step 6: Communicate the address to your organization
Once the address is working, publish it wherever people are most likely to need it — an intranet page, a site notice, a poster, or an email signature. Because no sign-in is required, keep in mind that anyone able to email the address can create an incident.
Conclusion
Inbound email reporting is the simplest way to collect incident reports from people who are not signed in to KC Safety. Enable it in your account settings, choose an intake address, configure inbound parse with the MX record and the signing key that KnowledgeCity provides, then test both a matched and an unmatched sender. Because verification fails closed, the signing configuration is the first thing to check if reports ever stop arriving.