Freigeben über

How to setup DMARC records if you are outsourcing some, or all, of your email – Part 1

  • Artikel

In my previous posts, I discussed how to set up your SPF, SenderID, and DKIM records if you are an organization that outsources some of its email to a 3rd party, such as advertising. For example, an airline might send out its flight confirmations from its own email servers and infrastructure, but contract out a 3rd party to send out advertising such as a sale on upcoming flights to Europe.

So far we’ve learned the following for the organization that is doing the outsourcing:

  1. Complying with SPF is easy.

  2. Complying with SenderID is more difficult because you have to delegate a subdomain that 3rd parties can use, and then publish their SPF information in that subdomain’s SenderID record.

  3. Complying with DKIM is easy if you don’t mind not building your own reputation (that is, the 3rd party builds reputation and not you).

    However, if you want your own domain to build reputation using DKIM, you have to delegate a subdomain to that 3rd party (the same as SenderID) and then either generate a public/private key pair and give the 3rd party the private key and publish the public key into that subdomain’s DKIM record, or have the 3rd party generate the keys and then you publish the public key into that subdomain’s DKIM record.

The next step is DMARC. I am going to assume you have a basic familiarity with DMARC. If not, you can view more details at https://dmarc.org. It’s not that difficult to understand, here’s a recap:

  1. DMARC is an anti-spoofing technology
    DMARC ensures that the email you receive in your inbox is authenticated.
    For example, below is a message from Geico. The email address in my email client, the RFC 5322.From, is geico @ email1.geico.com.

    [For the sake of this discussion, I am going to change some of the details of this message. Geico does not actually do what I am about to describe, they just happened to be in my inbox.]

    The domain in the d= field in the DKIM signature is campaigns.geico.com, and it passes a DKIM check.

    The domain in the RFC 5321.MailFrom (which does the SPF check) is bounces.email1.bigcommunications.com, and it passes an SPF check.

    Both the DKIM signature and the SPF check pass. This is part 1 what DMARC requires – the message must pass an SPF check or a DKIM check.

    image

  2. DMARC is a “what you see is what you authenticate” technology
    DMARC is designed to ensure that the sender you see that is rendered in your email client is the same as the one that is authenticated.

    In the above example, there are three domains: email1.geico.com (which is displayed to the end-user), campaigns.geico.com (which is validated with DKIM), and bounces.email1.bigcommunications.com (which is authenticated with SPF).

    Even though two domains are authenticated, this is transparent to the end-user. There is nothing in SMTP that says the RFC 5322.From domain couldn’t be “security @ paypal.com”. The email is authenticated (with SPF or DKIM) but the user still sees that the mail came “from” Paypal. A spammer can use this to send a spam blitz (by sending from an authenticated domain that the user never sees) in hopes they can trick users before spam filters catch up.

    DMARC combats this by requiring the RFC 5322.From address to be the same as the one that was authenticated, either with SPF or DKIM. This means that in the example above, even though the message was authenticated twice, it did not pass DMARC.

    Strict Mode

    Thus, in order for the above message to be DMARC compliant, the message must be one of the following (in DMARC “strict” mode):

    RFC 5322.From: email1.geico.com (the one the user sees)
    d= field in DKIM signature: email1.geico.com
    RFC 5321.MailFrom: This can be anything(the one used for SPF but not shown to the end user)

    OR

    RFC 5322.From: email1.geico.com (the one the user sees)
    d= field in DKIM signature: This can be anything
    RFC 5321.MailFrom: email1.geico.com (the one used for SPF)

    OR

    RFC 5322.From: email1.geico.com (the one the user sees)
    d= field in DKIM signature: email1.geico.com
    RFC 5321.MailFrom: email1.geico.com (the one used for SPF)

    In the last version, there is identifier alignment between the RFC 5322.From and the DKIM field and identifier alignment between the RFC 5322.From and the SPF identifier, but you don't get any extra points for this. You only need one or the other to be aligned.

    Relaxed Mode

DMARC also has “relaxed” mode for DKIM and SPF. This means that the RFC 5322.From and the domain in the d= field or RFC 5321.MailFrom can be sub-domains of each other. For example:

RFC 5322.From: geico.com (the one the user sees)
d= field in DKIM signature: email1.geico.com
RFC 5321.MailFrom: This can be anything(the one used for SPF but not shown to the end user)

OR

RFC 5322.From: geico.com (the one the user sees)
d= field in DKIM signature: This can be anything
RFC 5321.MailFrom: email1.geico.com (the one used for SPF)

OR

RFC 5322.From: geico.com (the one the user sees)
d= field in DKIM signature: campaigns.geico.com
RFC 5321.MailFrom: email1.geico.com (the one used for SPF)

Since geico.com is a subdomain of email1.geico.com, this passes “relaxed” DMARC identifier alignment.

Okay, we’ve now seen how DMARC works. What the user sees is what is authenticated. This is easy to do when the domain that is sending the email directly transmits the messages from its email infrastructure directly. But what about for outsourced email?

This is something we have already encountered, and is the subject of my next post.

Quick Navigation

Comments

  • Anonymous
    February 03, 2014
    Great article..