Share or Save

SPF and DKIM are important resources to help secure different aspects of the mail flow. One of the problems left unsolved by SPF and DKIM, however, was the specification of the actions that needed to be taken at the receiving site based on the information conveyed by these protocols. Enter DMARC.

Understanding DMARC

Aggressive receivers would discard or block messages based on the information available via SPF and DKIM while more cautious processors would just tag or deliver the mail to the dreaded spam folder. Throughout this process, the sender was entirely out of the loop with no way to help improve filtering efficiency or fix a mistake that ultimately caused mail to be missed by the recipients.

Also, the ability to spoof “From:” addresses had never been adequately addressed by any of the previous authentication mechanisms.

This is precisely where Domain-based Message Authentication, Reporting & Conformance (DMARC) comes in. It is a protocol – championed by some well-respected authorities in the email landscape – providing a mechanism to inform email receivers about the policies in use for a given mail flow and more importantly, signalling the intended treatment of mail that fails SPF or DKIM checks. Another very important features is the ability to generate a dynamic feed back loop that informs the senders about messages that are being rejected.

Currently DMARC exists as an Internet Draft. While its specification has not been accepted yet as an Internet Standard, there’s no reason not to use it given the support it enjoys among the mail receiving community.

[NOTE: ISIPP SuretyMail can set up your DMARC for you if you would rather not do it yourself. For more information about this service, contact us here.]

How does DMARC Work?

DMARC works by publishing a special DNS Resource Record that encodes a _policy_ relating to the protection of the mail flow. A mail sender can express a policy saying: “Block mail claiming to come from this domain that fails SPF checks.”

[Note: For another, comprehensive explanation of DMARC, check out DMARC: Monitor & secure your email delivery, written by Chris Nagele, founder of Wildbit.]

Specifically, DMARC is concerned with the address that appears in the `From:` header of the email message. This decision was taken because this is usually presented to the recipient as the actual origin of the message and therefore, it’s the common part of the message targeted by phishers and scammers.

This is good news for the mail receivers, because now they unambiguously know that they don’t need to waste resources further analyzing and filing messages that fail the prescribed checks. This is also excellent news for the sender, because now it becomes much harder to spoof his messages. The end user will be automatically protected from impersonators and phishers.

By using DNS to publish information, DMARC follows the experience gathered with SPF and DKIM. DNS is a robust and very well-tested mechanism for publishing this type of information quickly and effortlessly.

In fact, ISIPP SuretyMail was the very first email deliverability organization to use the DNS system to publish policy information about a sender’s email!

DMARC and DKIM Interaction

Although it is not common, any mail server in the path of a given message can apply a DKIM signature in transit to the message. In many scenarios, the domains that those signatures represent (encoded in the `d=` parameter of the DKIM signature) might not match the domain name of the email address in the `From:` header. This behavior is by design, because after all the DKIM signature in this case is establishing message validity.

DMARC allows the mail author to define one of two modes that govern how to apply DKIM for message authentication.

how to set up dmarc

Image from

With the first or _relaxed mode_, the domain part of the `d=` tag in the DKIM signature must match with the domain part of the address in the `From:` header. The `strict mode` requires instead that the fully qualified domain name present in the `d=` tag matches the `From:` header.

This interaction is called _DKIM Identifier Alignment_ and is very important to help insure that the email actually comes from the visible sender in the `From:` header. After all, DKIM by itself does not make this assertion.

DMARC and SPF Interaction

In a similar vein, DMARC provides two alignment modes for SPF identifiers, which are named in the same way.

In _relaxed mode_, a SPF identifier such as `` would match a `From:` address such as ``. Under _strict mode_, both identifiers would have to be identical in order to show _SPF Identifier Alignment_.

DMARC and Reputation

The DMARC specification includes a rich set of primitives that permit the sender to request feedback and reports about the messages that are failing the checks prescribed my DMARC. Along with the primitives that permit specifying how to process SPF and DKIM, these features combine to not only protect, but report on the attempted misuse of email addresses under your brand domains.

By effectively helping receivers to discard messages earlier in the process – messages that would likely cause rejection by the final recipients because these messages might be malicious or aren’t what they expect, adopting DMARC helps to curb the effects that those rogue mail streams might cause to your domain’s reputation.

Note however that DMARC is a suggestion to the receiving site. Regardless of the result of evaluating DMARC, SPF and DKIM rules, the recipient site can still decide to block, discard or file the messages in different folders based on their own policy.

How to Implement DMARC

As mentioned above, DMARC is implemented by providing special DNS Resource Records. Namely, a record such as this 3600 in txt ( “v=DMARC1; p=none;” )

As you can see, the text is composed of `key`, `value` pairs. Let’s discuss the different pairs that can be present in such a record:

* `v` — Magic number and version tag. Currently, it has to be the string “DMARC1”. This should always be the first component of your DMARC policy record.

* `adkim` — The DKIM alignment mode required. The default vale for this key is “r” standing for “relaxed” mode. It can also be set to “s” for “strict” mode.

* `aspf` — The SPF alignment mode required. The default vale for this key is “r” standing for “relaxed” mode. It can also be set to “s” for “strict” mode.

* `fo` — Tell the receiving server about the preference of the sender about failure reports. Use of this tag requires that a `ruf` tag is also specified in the policy. The following values can be concatenated using colons to signal the preference for different types of reports:

* `0` — Generate a DMARC failure report only if both SPF and DKIM failed to pass in the given alignment modes.

* `1` — Generate a DMARC failure report only if either SPF or DKIM failed to pass in the given alignment modes.

* `d` — Regardless of the current alignment mode, generate a failure report if a DKIM signature in the email failed to pass. Alignment is not considered for this report.

* `s` — Regardless of the current alignment mode, generate a failure report if a SPF signature in the email failed to pass. Alignment is not considered for this report.

* `p` — The policy that the sender requests the receiver to implement on its behalf. It can be one of:

* `none`: No specific requests.

* `quarantine`: The sender requests that mail failing the DMARC checks be considered _suspicious_. This can mean anywhere from “file in the spam folder” to “flag this message as suspicious to the end user”.

* `reject`: The sender would like to have the receiver reject messages failing the DMARC prescribed checks at SMTP transaction time.

* `pct` — This allows the sender to specify what percentage of the mail flow is to be subjected to the DMARC checks. For senders that are beginning to setup their policies, this parameter provides a way to gradually implement and test the impact of the policy, considerably reducing the risk of impact by error.

The specification does not mandate how to calculate this percentage. Instead, it suggests that a common way to implement this at the receiver side, is to use the value as a probability that the message is subjected to the DKIM checks.

* `rf` — Format used for the message-specific failure reports expressed as an optional comma-separated list of values. The two accepted formats are

* `afrf`: An “augmented” ARF report with additional DMARC-specific headers included.

* `iodf`: RFC-5070 (“Incident Object Description Exchange Format”), which is a format suitable for reporting computer security incidents.

Note that receivers can define other formats, albeit this should be a rare occurrence as most operations are embracing ARF as the reporting format of choice.

* `ri` — The Reporting Interval. The number of seconds elapsed between sending aggregate reports to the sender. The default value is 86400 seconds or a day. This is the value that is most commonly supported. Higher frequencies are accommodated on a best-effort basis.

* `rua` — The addresses to which aggregate feedback reports will be sent. It’s encoded as a list of DMARC URIs. It can also include a size limit for cases when the reports become hard to manage due to its size.

The only URL scheme that must be supported by compliant mail receivers is “mailto:”.

It is possible to specify destination addresses outside the domain being checked with DMARC. For these cases, special DNS Resource Records must be configured to allow for the reports to be sent.

* `ruf` — The addresses to which message-specific failure reports are sent. It’s a comma separated list of DMARC URIs used in conjunction with the `fo` key described above.

The only URL scheme that must be supported by compliant mail receivers is “mailto:”.

It is possible to specify destination addresses outside the domain being checked with DMARC. For these cases, special DNS Resource Records must be configured to allow for the reports to be sent.

* `sp` — Subdomain Policy; The policy to be enacted by the receiver at the request of the sender. It follows the syntax of the `p` tag above. By default, receivers apply the same policies of a parent domain to its subdomains.

The protocol leaves space for other keys, that must be ignored by mail servers that implement the specification but do not understand them. It is envisioned that mail providers can implement their own tags for service-specific signalling.

Defining Multiple DMARC Policies

DMARC allows for multiple policies to be applied to mail originating from a domain that it so desires. This works by defining an “Order of Severity” in the policies. The three severities in decreasing priority order are “reject”, “quarantine”, and “none”.

Combining this with the `pct` tag, it is possible to specify that 30% of the mail be subject to rejection when DMARC checks fail, and the rest be subjected to quarantine.

This is useful for generating rules that report on problems and violations only for a sample of your mail thus reducing the amount of data that needs to be analyzed.

What Kind of Information Will DMARC Provide?

A common misconception is that DMARC will shed light on the internal processes used by the mail receivers to process inbound mail. This is not true. The specification is clear when saying that “Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy.”

Mail receivers will continue basing their decision on the final disposition of an email message based on their own internal policies. As a matter of practice, mail senders should not set their expectations above what the specification defines.

[NOTE: ISIPP SuretyMail can set up your DMARC for you if you would rather not do it yourself. For more information about this service, contact us here.]

🌟 Has this been helpful? Please let us know here!

Share or Save

9 Responses

  1. the article is well written. i am a non technical person and i could understand the concept after reading this article. thanks a lot.

  2. Hi,

    Could someone set Up DMARC Email Authentication on the website/server please.

    I can give you full access to it.

    P.S. How much would it cost please?

    Regards, Pierre

  3. The left hand TXT entry is curiously omitted.

    For example, the following request for an activity report may generate an error saying that the “rua=…” report can’t be sent to an external address:

    _dmarc TXT “v=DMARC1; p=none; pct=100; rua=mailto:dmarc_errors@domain.tld”

    Yet the changing to requesting a failure notice may generate a different error:

    _dmarc TXT “v=DMARC1; p=none; pct=100; ruf=mailto:dmarc_errors@domain.tld”

    What is simply omitted here is how to clarify that you indeed intend for the reports to go to the specified address.

    Some internet sources suggest “domain.tld._dmarc” others seem equally caught in the weeds with suggestions like “_dmarc._report.domain.tld” — none of which seem to work.

  4. Hi Aza, thank you for your comment.

    I think you’re referring to situations where the DMARC record of a domain requests reports to be sent to a third party domain. In this case, the domain where the reporting addresses live, need to publish a specially formatted record in the DNS to signify acceptance of the email reports.

    Let’s pretend we have two domain names: will be used to send email and will publish a DMARC record while will be receiving the DMARC reports.

    In the zone you would add a record as

    _dmarc TXT “v=DMARC1; p=none;”

    However, in order for reports to be generated, the following record would need to be added to the zone: txt “v=DMARC1”

    This is the way for to signal that it is ok to send reports about

    Hope this helps.

  5. Thanks for the followup Lem.

    And a tribute to you because I’d never have seen your response had it not been that your site is so useful that I came back to figure out a bit more.

    Thanks for your thoughtful and useful contributions!


  6. I hope things improve. I suppose there’s no way of google checking as to the veracity of contents. I suppose they must receive millions of such reports.

  7. Hi,
    following the illustration, I tried to add a record for the sub domaine _dmarc instead of @ :)

    the txt record must be for

Leave a Reply

Your email address will not be published.

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
Filter by Categories
Content Issues
Email Authentication
Email List Building
Feedback Loops
Mailing List Hygiene
Monitoring and Tracking
Opt-in Practices
Our News
Privacy & Email Laws
Sending Practices
Spam Complaints
Technical Stuff
The Industry
More from Us

Join our email community and get
How to Stay Out of the Spam Folder 
& How to Grow Your Email List free!

 Get to the Inbox by SuretyMail
The Original Email Deliverability Company

Free stuff!
Skip to content