Share or Save

Do you know what your DMARC policy is, or if you even have a DMARC record? Of the authentication mechanisms (DMARC, SPF, DKIM) SPF and DKIM are important resources to authenticate different aspects of your email flow, but it’s important to have a DMARC record stating your DMARC policy as well. This is because your DMARC policy (contained in your DMARC record which is a text record within your DNS records) tells email receivers what they should do with email that claims to be from you but that fails SPF and/or DKIM.

Understanding the DMARC Policy and DMARC Record

Overzealous email receiving systems, such as ISPs and inbox providers, would discard or block messages that didn’t pass an SPF or DKIM authentication check, based on the information available in the sender’s SPF and DKIM records, while more cautious processors would tag the email as spam or deliver the email to the 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. At the same time, the ability to spoof “From:” addresses had never been adequately addressed by any of the previous authentication mechanisms.

This is precisely where DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance, 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, signaling the requested treatment of email that fails SPF or DKIM checks. Another very important feature of DMARC is the ability to generate a dynamic feedback loop that informs the senders about messages that are being rejected.

How does DMARC Work?

DMARC works by publishing a special DNS Resource Record that encodes the sender’s policy relating to the protection of the mail flow. An email sender can express a policy saying “Block mail claiming to come from this domain that fails SPF checks,” for example.

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

[This info is provided by us. We get you to the inbox. Learn how here.]

Specifically, DMARC is concerned with the address that appears in the `From:` header of the email message. This decision was made 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 example of 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 the information about a sender’s email that the inbox providers and ISPs want; this information is published to this day as part of our Good Senders List certified sender service.

DMARC and DKIM Interaction

DMARC allows the email sender to define one of two modes that govern how to apply DKIM for message authentication. This is useful because, although it is not common, any email server in the path of a given message can apply its own DKIM signature to the email message while it is in transit. In many scenarios, the domains that those signatures represent (encoded in the `d=` parameter of the DKIM signature) may 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, not original sender authentication.

With what is known as “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 ensure that the email actually comes from the visible sender in the `From:` header, as by itself DKIM does not make this assertion.

DMARC and SPF Interaction

Similar to DMARC and DKIM, 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.

Defining Multiple DMARC Policies

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

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.

DMARC and Reputation

The DMARC specification permits the sender to request feedback and reports about the messages that are failing the checks prescribed by DMARC. Along with the tags 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 protect against the harm caused by rogue spammers and phishers who attempt to spoof your sending email address. That said, it’s important to note that DMARC is a suggestion to the receiving site, not a commandment. 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.

What Kind of Information Does DMARC Provide?

A common misconception is that DMARC sheds 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, email senders should not set their expectations above what the specification defines.

How to Implement DMARC

If you are stout of heart (or at least somewhat geeky) and want to understand and create your own DMARC policy record, read on. Alternatively, you can use a DMARC generator to generate your records. One such DMARC generator is the free DMARC generator wizard provided by

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 signaling.

Again, if the above seems a bit much to tackle, we recommend using a DMARC generator such as the one provided by

DMARC Email Authentication and How to Set Up a DMARC Policy and DMARC Record

Prefer to listen to the podcast? Listen on Apple, Google, Amazon, Audible, Spotify, or Anchor or say "Alexa play the Everything Email Marketing podcast"


Full Post Archives

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.

We are ISIPP SuretyMail, the original certified sender program and email deliverability service. Learn more here
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages
Filter by Categories
Blocklists and Blacklists
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
Need Help Getting to the Inbox?
If you need help getting out of the spam folder and into the inbox, we're here for you. Our deliverability services come with a personal touch, and we get results. That combination has created customer loyalty that's nearly unheard of. (testimonials)
Read what we'll do for you here.

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