Authentication requirements
The platform requires inbound emails to pass standard email authentication checks before they are processed. Emails that fail these checks are rejected and will not trigger any import process, regardless of how the processing rules are configured.
Three authentication mechanisms are relevant.
SPF (Sender Policy Framework) allows domain owners to publish a list of authorised mail servers via a DNS TXT record. When an email arrives, the receiving system checks whether it was sent from an approved server for that domain. If not, the email may be rejected.
DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing emails. The receiving system uses a public key published in DNS to verify that the email was authorised by the sending domain and has not been altered in transit. Organisations using Microsoft email services should ensure DKIM is configured for their custom domains, not just default service domains.
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by specifying how receiving systems should handle emails that fail authentication — whether to monitor, quarantine, or reject them. The platform does not support bypassing these checks when SPF or DKIM validation fails.
These standards are configured by the administrators responsible for the sending domain, typically by adding DNS records. Your email service provider or DNS provider will have specific instructions. If data providers are sending emails to the platform and their messages are being rejected, SPF and DKIM configuration on their sending domain is the first place to check.
Monitoring incoming email
When the platform receives an email, it stores the message and any attachments in the database. You can review what has been received and how each message was processed via Configuration \> Email Logs \> Incoming Email.
The log displays standard message details - sender, subject, received time, and processed time - alongside a status for each email and each attachment. You can apply filters to locate a specific message.
Two time fields are shown for each record: Received Time is when the email arrived at the mail server, and Processed Time is when the platform stored it in the database. If an email contained body text, the platform saves it as a text file attachment named ES_EMAIL_BODY, visible in the Email Attachment File Status panel beneath the log entry. Attachments can be downloaded from the same panel.
Email statuses
Each email record carries one of the following statuses.
Status | Meaning |
Accepted | Email was received and parsed successfully. |
Rejected | Email was rejected, for example because the sender is not permitted. |
Discarded | Email was discarded, for example because the email service is disabled. |
Failed | An error occurred while parsing the email. The message field provides further detail. |
Attachment statuses
Each attachment has its own status, shown in the Email Attachment File Status panel.
Status | Meaning |
Validated | Attachment passed validation before process matching. |
Queued | Attachment matched a process and has been queued for execution. |
N/A | No matching process was found - sender, subject, or filename pattern did not match any email processing rule. |
Rejected | Attachment was rejected, for example because the matched process is not of type Import. |
Success | Process executed successfully. |
Warning | Process executed successfully but issues were detected. |
Failed | Process execution failed. The message field provides further detail. |
How processing works
When an email arrives, the platform first checks the sender against the permitted sender configuration. If permitted, the email appears in the Incoming Mail Log. The platform then evaluates the sender, subject, and attachment filename against your email processing rules. If all criteria match, the associated process runs.
You can trace the outcome of a matched process in three places: the Email Attachment File Status panel, the Process History screen of the application assigned to the process, and the Calculation Log if logging is enabled for that process.
Outbound email error reference
When a process sends email via EU_OUTGOING_MAIL, the platform records the outcome against each email record. The table below describes the possible outcomes.
Outcome | Result | Status | Message |
Success | Sent | Sent | — |
Invalid recipient | Rejected | Failed | Recipient Not Permitted |
Report failed to generate | Rejected | Failed | Report Failed to generate |
Reports not yet ready | Requeued | Waiting | Email waiting for reports to complete. Checking again in \{n\} seconds |
Report never generated within timeout | Rejected | Failed | Report took more than \{n\} days to generate |
Email too large | Rejected | Failed | Attachments exceeded max size of \{n\} bytes |
Email service suspended | Requeued | N/A | Email Service Suspended |
Unexpected error | Failed | Failed | Email failed to send. Please contact Support |
Recipient Not Permitted means the recipient address is not registered as a permitted outgoing email recipient. Add the address in Email Management \> Email Recipient before retrying.
Report Failed / Report Never Generated means an attachment referenced by EU_OUTGOING_ATTACHMENT either failed to generate or did not become available within the allowed window. Check the process report configuration and process execution logs.
Email Too Large means the total size of the email and its attachments exceeds 20MB. Reduce attachment size or split the email into multiple sends.
Email Service Suspended means the outgoing mail service is temporarily unavailable. The platform will retry automatically.