Email security architecture

Three layers, each with its own place in the payload

Each layer adds information or removes a threat, and the results of the last two arrive in the webhook payload, so your code can see what was checked.

The mail server turns away known bad senders

Before any content is analysed, the mail server decides whether to accept the connection at all. These checks apply to all mail we receive:

• Blocklists: Spamhaus and other domain-based blocklists, checked in real time.
• Sender checks: strict validation of HELO and sender identity claims.
• Rate limiting: a single client can open only so many connections per minute.
• Encrypted transport: inbound mail is accepted over TLS whenever the sending server offers it, with legacy protocols disabled and an MTA-STS policy published.

Details: Security and privacy →

Spam analysis gives you a score, not a verdict

On Maker and above, rspamd analyses every email to your custom domains and adds a spam object to the payload. It checks headers and content patterns, detects phishing (links whose text and target differ, URLs on the OpenPhish and PhishTank lists) and lists each rule that matched in symbols.

"spam": {
  "score": 6.5,
  "engine": "rspamd",
  "symbols": [
    { "name": "PHISHED_URL", "weight": 4.0, "description": "evil-site.com" }
  ]
}

There is no isSpam field, by design. Where the line between wanted and unwanted mail falls depends on how much a false positive costs you, so you draw it: compare spam.score in your endpoint, or let EmailConnect block or tag the mail with an alias rule. Scores of 5 and above are worth suspicion; 7 and above is very likely spam.

On Free, spam is a stub ({ "available": false }), and addresses on @user.emailconnect.eu get no spam analysis. Check for spam.score, not for spam. Spam filtering →

Sender authentication: SPF, DKIM and DMARC per email

The same analysis checks whether the sender is who they claim to be, and returns each result with the domain it applies to in spam.authentication.

"authentication": {
  "dkim": { "result": "pass", "domain": "example.com" },
  "spf": { "result": "pass", "domain": "example.com" },
  "dmarc": { "result": "pass", "domain": "example.com" }
}

Before your code acts on who an email is from (an invoice, a password reset, an order), check that DMARC passed for that domain.

Virus scanning keeps infected files out of your systems

On Business and Platform, ClamAV scans attachments before your webhook fires. It is off by default: turn on Scan attachments for viruses in Settings → Storage.

• What is scanned: documents, archives, executables and other files, up to 10 MB (the largest email we accept). Images, audio, video and plain-text files are skipped.
• Clean files are delivered as usual, with virusScan.status: "clean" and the scan duration in milliseconds.
• Infected files are excluded: the entry stays in the payload with excluded: true, excludeReason: "virus-detected" and the threat name, but carries no content and no downloadUrl.
• Definitions are updated automatically by ClamAV's freshclam, in the background.

Each payload also carries a summary for the whole email:

"security": {
  "virusScan": {
    "scanned": true,
    "engine": "clamav",
    "attachmentsScanned": 1,
    "attachmentsSkipped": 0,
    "threatsFound": 0
  }
}

Check scanned first. If the scanner was unavailable, it is false and the object carries only a reason; the email is still delivered, unscanned, so your handler should not assume a file is clean just because it arrived. Test it with the EICAR file →

What a security review can take from this

Every check above leaves a record in the payload you receive, so your own logs can show what each email went through:

• The spam score and each rule that contributed to it
• SPF, DKIM and DMARC results, with the domain each one applies to
• Per attachment, the scan result and, for an infected file, the threat name
• The ClamAV engine version and when its definitions were last updated, when available

The checks run in our application and mail server at Hetzner in Germany; no US company is in the processing chain, apart from optional sign-in with Google or GitHub. Where your email is stored, for how long, who can access it and how it is encrypted are answered in the trust center. If your procurement requires a specific certification, audit or penetration test, tell us what you need.

All answers for your security review: trust center →

Related