Authentication Blog Series: Part 3 – DMARC




  • by Michelle Van den Bergh May 21, 2016
    May 21, 2016

    In this final post of my authentication blog series I focus on DMARC and how it uses SPF and DKIM to close the loop on email authentication.


    What is Domain-based Message Authentication, Reporting and Conformance (DMARC)?


    DMARC basically standardizes how email receivers perform email authentication using SPF and DKIM, enabling consistent results for the sender’s messages.


    Most of the major webmail providers: AOL, Gmail, Hotmail, Yahoo would use this authentication reporting tool.


    High-level principles of DMARC:



    • Senders opt-in by publishing a DMARC policy
    • Receivers provide feedback so that Senders can close gaps (and identify phishing attempts)
    • Senders increase the level of authenticated email being delivered
    • Receivers can identify and block unauthenticated email (as published by the Sender’s DMARC policy)

    How DMARC works:


    A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if one or both authentication methods fail. The policy will direct the receiver to mark non-compliant emails as spam, proceed to quarantine or reject the email.


    DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the end user’s exposure to potentially fraudulent or harmful messages.


    DMARC also provides a way for the email Receiver to report back to the sender about emails that pass or fail DMARC evaluation.


    A real world example:


    Joe works at My Company. My Company has a very security conscious domain administrator who has previously implemented SPF and DKIM on all of the company’s mailservers. He now decides to implement DMARC.


    A real world example


    1. My Company’s domain administrator gets his list of domains that send on behalf of the company (Including external vendors/marketers). This list contains the IP addresses of all servers that send emails on MyCompany’s behalf.


    2. The domain administrator sets up an email address that will receive all of My Company’s reports regarding DMARC activity.


    3. The domain administrator deploys a DMARC DNS record for every domain on his list. When he sets up the configuration, he will specify the following:


    a. What email address the reports need to be sent to


    b. The policy directive on how to handle emails that fail SPF or DKIM or both, i.e.


    i. None – this will deliver to the end user and report back to the domain owner only


    ii. Quarantine/Spam – this will deliver to the end users spam folder


    iii. Reject – Cancels the email and does not deliver to end user


    c. The percentage of messages affected. This is used when the domain owner has not set up policies on all domains, as he is ramping up the deployment of DMARC i.e. he expects only 70% of emails from the organization to pass these tests. This means that only when more than 30% of messages fail, will the DMARC policy be applied. Ultimately, the domain owner should aim at having this policy applied to 100% of emails.


    Joe decides to send an email to Mike. He is using a My Company Mailserver that has DMARC set up;
    DMARC set up correctly


    1. Mike’s mailserver receives the connection from the MyCompany Domain. It performs the SPF validation which passes.


    2. Mike’s mailserver then retrieves the DMARC policies for the email from the My Company domain and then downloads the full email from the MyCompany mailserver.


    3. Mike’s mailserver then does the DKIM check which passes the checksum validation.


    4. As both SPF and DKIM have passed, the DMARC policy states that the email can be delivered to the end user (Mike’s mailbox)


    5. A report is sent to the email address for the My Company domain (usually set up as a daily report) stating that the emails to Mike’s mailserver where successful.


    A phisher tries to send Mike an email, pretending to be from Joe@MyCompany.com


    Phisher attempt without DMARC


    1. The Phishing mailserver does not have the private key to digitally sign its outgoing email


    2. Mike’s mailserver receives the connection from the phishers mailserver and perfoms SPF and DKIM checks.


    3. If either or both checks fail, Mike’s mailserver checks the DMARC policy to decide what to do with the email. As the My Company DMARC policy is set to “Reject” failed emails, Mike’s mailserver does not send it to Mike’s mailbox.


    4. A report is sent to the email address for the My Company domain (usually set up as a daily report) stating that the emails to Mike’s mailserver failed and were not delivered


    a. Joe’s domain administrator can review the trends of emails from this IP address and decide if they need to be added to the policy or permanently blacklisted.


    How to implement DMARC:


    1. If you are a domain owner, make sure that you have SPF and DKIM set up for all mailservers that send on your behalf (Including outsourced marketing companies).


    a. Enable DMARC policies on all mailservers


    b. Monitor your reporting mailbox and decide what to do with repeat offenders


    2. Receiving mailserver owners need to enable their servers to check for DMARC on all inbound emails


    3. If you are Joe or Mike, speak to your domain owner to ensure that this is in place.


    In conclusion, setting up SPF or DKIM in isolation will help towards improving your email delivery and authentication. These technologies are however not fool-proof, so to make sure that you protect your domain completely, you need to implement DMARC to close the loop in your email authentication process.


    For more information on DMARC and how to implement it visit: https://dmarc.org/

    Digital & Social Articles on Business 2 Community

    (1)

    Leave a Reply