DMARC Generator - Generate your DMARC record


Please click on the Next button to start the process of how to create the DMARC policy.

There are three policy levels which can be set for DMARC. Those are:

  1. None - Reports possible suspicious mail messages, but all mail is sent to inbox
  2. Quarantine - Fail SPF/DKIM policy, then message is sent to SPAM/ Junk folder
  3. Reject - Fail SPF/DKIM policy, then message is dropped and not delivered at all

It is strongly recommended to start with None, as this will allow for time to monitor the reports generated and determine if legitimate mail will be blocked before switching the DMARC policy to Quarantine or Reject.

This will add the 'p' tag to the DMARC record.


This is optional, but is strongly recommended, and will add the 'rua' rua tag to the policy. It is strongly recommended that this be added to the policy for analysis and monitoring purposes. Reports can be sent to multiple addresses.



The aggregate reports (XML format) will be generated containing information about which mail messages pass/fail against SPF and DKIM. This provides visibility into possible authentication issues and/or spam activity for your organization.

This is optional and will add the 'ruf'ruf tag to the policy. These XML reports will only be generated if the receiving side generates these types of reports. There is a chance that you may not receive any forensic reports. This is due to privacy and data sharing regulations across nations.



There are three policy levels which can be set for DMARC. Those are:

  1. None - Reports possible suspicious mail messages, but all mail is sent to inbox
  2. Quarantine - Fail SPF/DKIM policy, then message is sent to SPAM/ Junk folder
  3. Reject - Fail SPF/DKIM policy, then message is dropped and not delivered at all

It is strongly recommended to start with None, as this will allow for time to monitor the reports generated and determine if legitimate mail will be blocked before switching the DMARC policy to Quarantine or Reject.

This will add the 'p' tag to the DMARC record.


  1. When should the error report be generated

    Defines error reporting policy.

    If not defined, defaults to 0 (Generate report to the sending MTA if any underlying checks failed).Other values are:

    1. Generate report to the sending MTA if any underlying checks failed.
    2. Generate a report if DKIM check fails
    3. Generate a report if SPF check fails

  2. Alignment mode for DKIM

    Alignment mode for DKIM, Options are:

    r (relaxed) default if not defined. Allows for any subdomain defined in the DKIM header.
    s (strict) the sender's domain name must match the domain in the DKIM header exactly.


  3. Alignment mode for SPF

    Alignment mode for SPF, Options are:

    r (relaxed) default if not defined. Allows for any subdomain.
    s (strict) the organization domain name in the MAIL FROM command (in SMTP) and the from: header (in the mail item) must watch exactly.


  4. Alignment mode for SPF
    Current Value: 0

    % of messages subjected to filtering by the DMARC policy. Can be any number from 1 to 100. Default is 100, which is all messages


  5. Reporting Interval (seconds)

    Defines the reporting intervals in seconds. If not defined, the default is 86400 seconds, or 24 hours. Please note, that reports are not guaranteed to be sent by receiving MTAs. Reports are sent on a best effort basis.

    hours to second convertor
      to  


DMARC Tag Explanations

Tags Tag Description
v (required) The version tag. The only allowed value is "DMARC1". If it's incorrect or the tag is missing, the DMARC record will be ignored.
p (required) The DMARC policy. Allowed values are "none", "quarantine", or "reject". The default is "none," which takes no action against non-authenticated emails. It only helps collect DMARC reports and gain insight into your current email flows and their authentication status. "quarantine" marks the failed emails as suspicious, while "reject" blocks them.
rua Aggregate report sending destination. It's the "mailto:" URI that ESPs use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
ruf Forensic (Failure) report sending destination. It's the "mailto:" URI that ESPs use to send failure reports. The tag is optional, but you won’t receive reports if you skip it.
sp The subdomain policy. The subdomain inherits the domain policy tag (p=) explained above unless specifically defined here. Like the domain policy, the allowed values are "none," "quarantine," or "reject." This option isn't widely used nowadays.
adkim The DKIM signature alignment. This tag follows the alignment between the DKIM domain and the parent Header From domain. Allowed values are "r" (relaxed) or "s" (strict). "r" is the default and allows a partial match, while the "s" tag requires the domains to be the same.
aspf The SPF alignment. This tag follows the alignment between the SPF domain (the sender) and the Header From domain. Allowed values are "r" (relaxed) or "s" (strict). "r" is the default, and allows a partial match, while the "s" tag requires the domains to be exactly the same.
fo Forensic reporting options. Allowed values are "0," "1," "d," and "s." "0" is the default value, which generates a forensic report when both SPF and DKIM fail to produce an aligned pass. If either of the protocol outcome is something other than pass, use "1." "d" generates a report when DKIM is invalid, while "s" does the same for SPF. Define the ruf tag to receive forensic reports.
rf The reporting format for failure reports. Allowed values are "afrf" and "iodef".
pct The percentage tag. This tag works on domains with "quarantine" or "reject" policy only. It marks the percentage of failed emails a given policy should be applied to. The rest falls under a lower policy. For example, if "pct=70," on a domain with "quarantine" policy, it applies only 70% of the time. The remaining 30% goes under "p=none". Similarly, if "p=reject" and "pct=70," "reject" applies to the 70% of failed emails, and the 30% go into "quarantine."
ri Reporting interval. Marks the frequency of received XML reports in seconds. The default is 86400 (once a day). Regardless of the set interval, in most cases, ISPs send the reports at different intervals (usually once a day).

Our Services & Expertise

Spoof proof your inbox with Progist Email Secure Suite.

Start Free   Contact us