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

  • Article

Continuing on in our series on authenticating outsourced email, how do we outsource our email such that we also pass a DMARC check?

First, decide if you want DMARC to pass via an SPF check or a DKIM validation, or both.

Second, delegate a subdomain for the 3rd party to send email “as your authenticating domain.” If Oceanic Airlines wants BigCommunications.com to send its email, it might pick news.oceanicairlines.com.

Third:

  1. if Oceanic wants to pass DMARC with SPF, it must include BigCommunication.com’s IP addresses in its SPF record for news.oceanic.com, or include it. This is exactly the same as setting up SenderID records except that Oceanic uses syntax for SPF, not SenderID.

  2. If Oceanic wants to pass DMARC with DKIM, it must publish a public/private key pair as described in outsourcing your email but still passing DKIM and building reputation on your domain.

  3. If Oceanic wants to pass DMARC with both SPF or DKIM, it must do both #1 and #2. 

Fourth, Oceanic must publish DMARC records in oceanic.com with “relaxed” SPF and DKIM policies. Since “relaxed” is the default, they don’t have to publish anything special.

BigCommunications.com can now send email with the RFC 5322.From as “news@oceanic.com”, but must specify news.example.com in the d= field in the DKIM header or the RFC 5321 From, or both.

Let’s take a look at a sample message:   

HELO mail.bigcommunications.com
MAIL FROM: bigcommunications.campaign@news.oceanicairlines.com
RCPT TO: <recipient>
DATA
Subject: Discover Ireland from $768* RT
From: Oceanic Airlines <oceanic@oceanicairlines.com>
To: Me
Content-Type: multipart/alternative;
boundary="----=_Part_8280486_25400197.1366674040595"
Date: April 26, 2013, 4:30 PM PST
Message-ID: <04262013_0163013@bigcommunications.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=s1024_oceanicairlines;
d=news.oceanicairlines.com; h=Message-ID:Date:Content-Type:From:To:Subject;
bh=<hash>;
b=<hash>
<Everything else in the email>
.
QUIT

We see the following:

  1. The message passes an SPF check because Oceanic delegated a subdomain for BigCommunications.com and included their SPF records.

  2. The message passes a DKIM check because Oceanic published a DKIM record in that same subdomain and gave BigCommunications.com the private key.

  3. The message passes identifier alignment because the domain in the RFC 5322.From address is a subdomain of the domain domains in the RFC 5321.MailFrom (SPF) and d= field (DKIM), and Oceanic published a DMARC record with “relaxed” identifier alignment.

Et voila! Oceanic has outsourced its email and it passes SPF, DKIM and DMARC!

Fifth, and this is outside of how to send your email but still required for DMARC, Oceanic needs to specify an “rua” address for authentication reports. An “rua” address is an email address that 3rd parties will send rolled up, aggregated reports to when the DMARC record fails.

That is, if a spammer spoofs OceanicAirlines.com, this will fail a DMARC check since it will not pass an SPF check nor a DKIM check. The email receiver will send a rolled up report to this “rua” address. However, if BigCommunications.com messed up their configuration and sent email with the wrong RFC 5321.MailFrom or wrong DKIM private key, this also fails DMARC and the email receiver will send a rolled up report.

For these cases, Oceanic can go through them to verify (a) spammers are spoofing their domains, let’s take action against them, or (b) BigCommunications is authenticating wrong, let’s use this to identify it and fix it.

 

That’s outside of the scope of this discussion, but it is one of DMARC’s most useful features.

* * * * * * * * * * * * * * * * * * * * * * * *

At this point, I think DMARC authentication is well understood but let’s tie up some loose ends.

1.
Delegating a subdomain is optional in SPF and DKIM by themselves, but is required for DMARC
If you don’t want to delegate a subdomain in SPF or DKIM, you don’t have to. The reason you want to is to generate reputation on your own domains. It is more work and there are risks associated with it but there are ways to manage this.

However, to pass DMARC, you *must* delegate a subdomain.  
  
  
*\[“Must” is too strong a word because technically it is optional, but I use it because in my opinion it is the best way to mitigate risk in case a 3rd party starts sending out spam as your domain. You still have to publish the 3rd party’s SPF or DKIM records in your own DNS zone\]*

  1. SenderID is not used by DMARC

    SenderID is designed to combat spoofing of the RFC 5322.From address. However, DMARC does the same thing. Thus, the decision to publish SenderID records is optional. The reason you would do it is to ensure that email receivers that do not validate DMARC but check SenderID will not reject the message.
     

  2. DMARC requires either SPF or DKIM; this means that you cannot pick and choose which one you want to authenticate with

    I went into this a little bit in my blog post on How large financial institutions should use hosted filtering.

    DMARC doesn’t let the sender say “Authenticate with DKIM only, because other senders behind the same IP address might be able to spoof my domain and thereby pass SPF and thereby pass DMARC which only requires one of SPF or DKIM to pass.”

    To get around this, a domain could not publish SPF record, but publish a DKIM record and DMARC record. This means that the SPF check would not pass, but the DKIM check would pass which is good enough for DMARC.

    Unfortunately, there are still a lot of organizations that do not verify DMARC but instead only rely upon SPF. If you don’t publish SPF records, you will open up yourself to being spoofed by spammers who send mail as your domain to receivers who don’t validate DMARC. This is a lot of risk, probably too much (this is the whole problem of phishing that DMARC is supposed to fight).

    Thus, using DMARC works best when you send outbound email from a source where your domain cannot be spoofed (i.e., dedicated IPs), or there is a low likelihood of spoofing, or where you are willing to accept that risk.

  3. DMARC is great but most spam filters still rely upon IP reputation
    DMARC is a great piece of technology: it helps combat phishing, forces senders to start building domain reputation and helps receivers build (and use) domain reputation. However, most spam filters today still rely on IP reputation.

    This means that if the IPs you send from send spam, your reputation will degrade even if you authenticate with SPF, DKIM and DMARC. These three authentication mechanisms can help, but they aren’t a fail safe.

And with that, I am going to close my series on How to Outsource Your Email and Still Pass Authentication. I hope you enjoyed it.

As always, feedback is welcome.

Quick Navigation