Technical Tip - Set up DMARC in 5-Easy Steps

Version 4
    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.