Per-Domain Email Policies: How to Configure Different Rules for Each of Your Domains

Why Different Domains Need Different Policies

If you manage more than one domain — and most organizations with serious email infrastructure do — you've probably noticed that a single spam filter configuration rarely serves all of them well. The reason is that domains have fundamentally different email profiles, different sender relationships, and different tolerance for false positives.

Consider a typical scenario with three domains at the same company:

• acme.com — the main corporate domain. Employees send and receive regular business email here. False positives are costly because a missed customer email can mean a lost deal. Spam tolerance is moderate.
• mail.acme.com — a transactional sending domain used for automated order confirmations, password resets, and shipping notifications. This domain sends a lot of mail, but receives almost nothing except bounces and delivery receipts. It needs very aggressive filtering on inbound because nearly anything arriving here is either a bounce loop exploit or a misdirected spam campaign.
• support.acme.com — a customer support ticketing address. Customers email this from every corner of the internet, often from free webmail services with poor sender reputations. Greylisting would delay support tickets by minutes, which is unacceptable. The spam threshold may need to be looser here too because support email sometimes looks "spammy" — forwarded threads, all-caps subject lines, non-Latin characters.

Running all three on the same policy means you're constantly making tradeoffs. The answer is per-domain configuration with global inheritance.

How Global Defaults Work

In Indition Spam Killer, every domain inherits from a global defaults block. You only need to override the settings that should differ per domain. Anything you don't override at the domain level is silently inherited from the global block.

A typical global defaults section might look like this:

defaults:
  upstream: mail.acme.com:25
  spam_threshold: 5.0
  quarantine: true
  greylisting:
    enabled: true
    defer_minutes: 5
    expire_hours: 168
  spf:
    enabled: true
    fail_action: reject
    softfail_action: quarantine
  dkim:
    enabled: true
    fail_action: quarantine

This sets a baseline that applies to every domain unless overridden. Now let's look at how individual domains can diverge from that baseline.

Per-Domain Configuration

Domain-level blocks are keyed by the domain name. Settings in this block merge with — rather than replace — the global defaults. Only what you specify here is overridden.

Example: The Main Corporate Domain

For acme.com, the defaults are mostly fine, but you want slightly looser spam thresholds and you want to route mail to a specific internal Exchange server:

domains:
  acme.com:
    upstream: exchange.internal.acme.com:25
    spam_threshold: 6.0

Everything else — greylisting, SPF enforcement, DKIM enforcement — is inherited from defaults. You're not touching what you don't need to change.

Example: The Transactional Domain

For mail.acme.com, nearly everything that arrives should be treated with suspicion. You want aggressive filtering, no greylisting (since legitimate bounce processors retry quickly anyway), and you want the upstream to be a dedicated bounce-handling server:

  mail.acme.com:
    upstream: bouncehandler.acme.com:25
    spam_threshold: 2.5
    greylisting:
      enabled: false
    spf:
      fail_action: reject
      softfail_action: reject

Notice that the spf block here only overrides fail_action and softfail_action. The enabled: true field is still inherited from the global defaults — you don't need to repeat it.

Example: The Customer Support Domain

For support.acme.com, greylisting must be disabled, the spam threshold needs to be higher to reduce false positives, and you want DKIM failures to only add score rather than quarantine, since many customers' sending setups don't have proper DKIM configured:

  support.acme.com:
    upstream: helpdesk.acme.com:25
    spam_threshold: 8.0
    greylisting:
      enabled: false
    dkim:
      fail_action: score_only

A Complete Multi-Domain Configuration

Putting it all together, a realistic configuration for three domains looks like this:

defaults:
  upstream: mail.acme.com:25
  spam_threshold: 5.0
  quarantine: true
  greylisting:
    enabled: true
    defer_minutes: 5
    expire_hours: 168
  spf:
    enabled: true
    fail_action: reject
    softfail_action: quarantine
  dkim:
    enabled: true
    fail_action: quarantine

domains:
  acme.com:
    upstream: exchange.internal.acme.com:25
    spam_threshold: 6.0

  mail.acme.com:
    upstream: bouncehandler.acme.com:25
    spam_threshold: 2.5
    greylisting:
      enabled: false
    spf:
      fail_action: reject
      softfail_action: reject

  support.acme.com:
    upstream: helpdesk.acme.com:25
    spam_threshold: 8.0
    greylisting:
      enabled: false
    dkim:
      fail_action: score_only

This configuration is 35 lines and covers three entirely different email profiles. The global defaults do the heavy lifting, and each domain block is surgical — only specifying what needs to change.

Inheritance Rules: What Merges and What Replaces

Understanding how inheritance works prevents surprises. The rules are straightforward:

• Scalar values (strings, numbers, booleans) at the domain level fully replace the global default value.
• Nested objects (like spf, dkim, greylisting) are merged at the key level, not replaced wholesale. You can override a single key inside a nested block without losing the other keys.
• Lists (like whitelist entries) are typically appended unless you explicitly use a replace: directive.

This means if your global spf block has five settings and you override only fail_action at the domain level, the other four settings are still active for that domain. You never need to copy-paste settings just to change one field.

Testing Your Per-Domain Config

After making per-domain changes, use the CLI to verify the effective configuration for a specific domain before putting it into production:

spam-killer config show --domain support.acme.com

This outputs the fully merged configuration as it will be applied to that domain — global defaults overridden by domain settings — so you can confirm the result is exactly what you expect. There are no hidden defaults and no silent merges; what you see is what gets applied.

For organizations managing a dozen or more domains, per-domain policies are the difference between a spam filter that's carefully tuned for each use case and one that's perpetually misconfigured for half of them.