DMARC module

DMARC is a technology leveraging SPF & DKIM which allows domain owners to publish policies regarding how messages bearing their domain in the RFC5322.From field should be handled (for example to quarantine or reject messages which do not have an aligned DKIM or SPF identifier) and to elect to receive reporting information about such messages (to help them identify abuse and/or misconfiguration and make informed decisions about policy application).

DMARC in rspamd

The default configuration for the DMARC module in rspamd is an empty collection:

dmarc {

This is enough to enable the module and check/apply DMARC policies.

Symbols added by the module are as follows:

  • DMARC_BAD_POLICY: Policy was invalid or multiple policies found in DNS
  • DMARC_NA: Domain in From header has no DMARC policy or From header is missing
  • DMARC_POLICY_ALLOW: Message was authenticated & allowed by DMARC policy
  • DMARC_POLICY_REJECT: Authentication failed- rejection suggested by DMARC policy
  • DMARC_POLICY_QUARANTINE: Authentication failed- quarantine suggested by DMARC policy
  • DMARC_POLICY_SOFTFAIL: Authentication failed- no action suggested by DMARC policy

Rspamd is able to store records in redis which could be used to generate DMARC aggregate reports but there is as of yet no available tool to generate such reports from these. Format of the records stored in redis is as follows:


where spf and dkim results are true or false indicating whether an aligned spf/dkim identifier was found and dmarc_disposition is one of none/quarantine/reject indicating policy applied to the message.

These records are added to a list named $prefix$domain where $domain is the domain which defined policy for the message being reported on and $prefix is the value of the key_prefix setting (or “dmarc_” if this isn’t set).

Keys are inserted to redis servers when a server is selected by hash value from sender’s domain.

To enable storing of report information, reporting must be set to true. Please see the section on reporting in this document for more information.

Actions can be forced for messages based on DMARC disposition as demonstrated in example config below.

dmarc {
	# If Redis server is not configured below, settings from redis {} will be used
	#servers = ""; # Servers to use for reads and writes (can be a list)
	# Alternatively set read_servers / write_servers to split reads and writes
	# To set custom prefix for redis keys:
	#key_prefix = "dmarc_";
	# Actions to enforce based on DMARC disposition (empty by default)
	actions = {
		quarantine = "add_header";
		reject = "reject";
        # Ignore "pct" setting for some domains
        # no_sampling_domains = "/etc/rspamd/";


From Rspamd 3.0 you should use rspamadm dmarc_report tool called manually (e.g. via cron or systemd timers) to send reports, this should be done either daily or hourly depending on traffic. You also need a working MTA running on a specific host that allows email to be sent with no authentication/ssl (preferrably local MTA).

While migrating from the previous versions, please ensure that you don’t have something like reporting = true; in rspamadm configdump dmarc. It was intentionally converted to the new options schema to avoid misconfiguration. The line reporting = true; must be removed from the local.d/dmarc.conf if it is there.

DMARC reporting information is stored in Redis- see here for information about configuring Redis.

Here are the configuration parameters for Dmarc reporting with the corresponding comments:

# local.d/dmarc.conf
  reporting {
    # Required attributes
    enabled = true; # Enable reports in general
    email = ''; # Source of DMARC reports
    domain = ''; # Domain to serve
    org_name = 'Example organisation'; # Organisation
    # Optional parameters
    bcc_addrs = [""]; # additional addresses to copy on reports
    report_local_controller = false; # Store reports for local/controller scans (for testing only)
    helo = 'rspamd.localhost'; # Helo used in SMTP dialog
    smtp = ''; # SMTP server IP
    smtp_port = 25; # SMTP server port
    from_name = 'Rspamd'; # SMTP FROM
    msgid_from = 'rspamd'; # Msgid format
    max_entries = 1k; # Maxiumum amount of entries per domain
    keys_expire = 2d; # Expire date for Redis keys
    #only_domains = '/path/to/map'; # Store reports merely from those domains
    # Available from 3.3
    #exclude_domains = '/path/to/map'; # Exclude reports from those domains or eslds
    #exclude_domains = ["", ""]; # Exclude reports from those domains or eslds

Prior to Rspamd 3.3 you can skip some domains from the reporting by setting no_reporting_domains that is a map of domains or eSLDs to be excluded. Rspamd 3.3 supports this option in reporting section, however, a legacy option settings.no_reporting_domains is also supported (but not preferred).

DMARC Munging

From version 3.0, Rspamd supports DMARC munging for the mailing list. In this mode, Rspamd will change the From: header to some pre-defined address (e.g. a mailing list address) for those messages who have valid DMARC policy with reject/quarantine that would otherwise fail during mailing list forwarding. An example of this technique is defined here: Here is an example for such a configuration:

# local.d/dmarc.conf
munging {
  list_map = "/etc/rspamd/maps.d/"; # map of maillist domains (mandatory)
  mitigate_strict_only = false; # perform mugning merely for reject/quarantine policies
  reply_goes_to_list = false; # set reply-to to the list address
  mitigate_allow_only = true; # perform munging based on DMARC_POLICY_ALLOW only
  munge_from = true; # replace from with something like <orig name> via <rcpt user>
  munge_map_condition = nil; # maps expression to enable munging