Technical Tip - Set up DMARC in 5-Easy Steps

Document created by 9588451ecc601f1a2620c0a3338f73ddec06dbf4 Employee on Dec 12, 2014Last modified by 9588451ecc601f1a2620c0a3338f73ddec06dbf4 Employee on Sep 27, 2017
Version 4Show Document
  • View in full screen mode
  1. Set up DKIM and SPF for the domain used in the From Address.
  2. Send from a dedicated IP through Marketo, contact your salesperson if you need to set this up.
  3. Set up a branded "envelope_from" when provisioning your dedicated IP, this is standard.
  4. Publish a DMARC record with the "monitor" flag set for the policies.  Ask for data reports.
  5. Modify your DMARC policy flags from "monitor" to "quarantine" to "reject" as you gain experience.
Do you wonder what DMARC is? Review this article.

Setting up your DMARC Record

 

To set up a DMARC record, your team should create a TXT entry for _dmarc.<example>.com

Example

 

v=DMARC1; p=none; rua=mailto:example@<example>.com; ruf=mailto:example@<example>.com; adkim=r; aspf=r; rf=afrf; sp=none


v=DMARC1; p=none; rua=mailto:postmaster@mydomain.com; ruf=mailto:postmaster@mydomain.com; adkim=r; aspf=r; rf=afrf; sp=none

 

An explanation of the different mechanisms that can be used in the record:

 

Tag NamePurposeSample
vProtocol versionv=DMARC1
pctPercentage of messages subjected to filteringpct=20
rufReporting URI for forensic reportsruf=mailto:example@example.com
ruaReporting URI of aggregate reportsrua=mailto:example@example.com
pPolicy for organizational domainp=none
spPolicy for subdomains of the ODsp=none
adkimAlignment mode for DKIMadkim=r
aspfAlignment mode for SPFaspf=r
rfReporting formatrf=afrf

Recommendations for a test and reporting mode

Requested policy type [p=] none (this means that this just for reporting at this time.  Once they have reviewed reporting and have made an internal decision about how they want to handle traffic that is not aligned with DKIM and/or SPF.)

Data Reporting Addresses [rua=mailto] their choice

DKIM identifier alignment [adkim=] relaxed

SPF identifier alignment [aspf=]– relaxed

Report format [rf=]– their choice based on how they plan on consuming the reporting.  Arf is recommended.

Apply policy to 100% All recommendations right now are test mode recommendations so they can monitor the feedback from this for a few weeks before implementing more strict settings.

Reporting interval Again, contingent on how frequent they want the reporting to be.  86400 is a count of seconds, this translates into a report every 24 hours.

Subdomain policy [sp=] – none (this means that this just for reporting at this time.  Once they have reviewed reporting and have made an internal decision about how they want to handle traffic that is not aligned with DKIM and/or SPF.)

The DMARC validation process.

In order for DMARC to begin passing a message, either the DKIM must pass or the SPF must pass, if neither passes then the action requested, in p (Domain policy) or sp (Subdomain policy) in the above DMARC DNS text entry will be adhered to. The options on the policies are none, quarantine or reject.

Once either DKIM or SPF have passed, and it can be both, DMARC will then take action based on the requested behavior of adkim or aspf.

For strict adherence:

  1. In all cases, the RFC5321:Mailfrom and the RFC5322:From must match exactly.
  2. If the adkim is set to strict then the d= entry must match exactly the RFC5322:From domain.
  3. If spf is set to strict then spf domain must exactly match the RFC5322:From domain.

For relaxed adherence:

  1. In all cases both RFC5321:Mailfrom and RF5322:From must share an organizational domain.
  2. For dkim relaxed the d= domain must share an organizational domain with the RFC5322:From domain.
  3. For spf relaxed the domain must share an organizational domain with the RFC5322:From domain.

We hope you find the information here of some use however, please note that this document is not meant to replace the information available on DMARC at these locations.

 

 

     - See more at: http://www.messagesystems.com/blog/tech-tips-how-to-implement-dmarc/?utm_source=newsletter&utm_medium=email&utm_content=1-16-14&utm_campaign=The%20Messenger&mkt_tok=3RkMMJWWfF9wsRoguarMZKXonjHpfsX56u0kXqW1lMI%2F0ER3fOvrPUfGjI4HScVgI%2BSLDwEYGJlv6SgFSbXDMbNs3rgNWhg%3D#sthash.rwmaknz7.MVRnv9ND.dpuf

 

To explain some of the references below the envelope_from (RFC5321:Mailfrom) is unseen by the recipient and is used to direct bounces and errors.  The Friendly From (RFC5322:From) is what you see as the From: in an email.

For strict alignment:
    1.    In all cases, the envelope_from and the Friendly From domains must match exactly.  If a customer is setting up for strict adherence and will want to use DKIM as a parameter they will need to work with Marketo Support and Operations to align those two headers, a branded envelope_from will need to be set up.
    2.    If the adkim is set to strict then the d= entry must match exactly the Friendly From domain. The standard Marketo DKIM implementation meets this requirement.
    3.    If spf is set to strict then spf domain must exactly match the Friendly From domain. The standard Marketo SPF recommendations meet this requirement.

For relaxed alignment:
    1.    In all cases, the envelope_from and the Friendly From must share an organizational domain.  If a customer is setting up for relaxed adherence and will want to use DKIM as a parameter they will need to work with Marketo Support and Operations to align those two headers, a branded envelope_from will need to be set up.
    2.    For dkim relaxed the d= domain must share an organizational domain with the Friendly From domain. The standard Marketo DKIM implementation meets this requirement.
    3.    For spf relaxed the domain must share an organizational domain with the Friendly From domain. The standard Marketo SPF recommendations meet this requirement.

For more information please refer to the DMARC site - http://www.dmarc.org/

Other resources:

 

(star)

A few things to monitor for and be aware of is that Microsoft Exchange has a bug which can sometimes break DKIM.  This is a known issue on their end that is being worked on but no ETA on resolving this.  This can result in some false positive DKIM failures.  Another reason to monitor traffic in a reporting/test mode for a few weeks before implementing a strict policy type.

Attachments

    Outcomes