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.
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 “firstname.lastname@example.org”, 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: email@example.com RCPT TO: <recipient> DATA Subject: Discover Ireland from $768* RT From: Oceanic Airlines <firstname.lastname@example.org> To: Me Content-Type: multipart/alternative; boundary="----=_Part_8280486_25400197.1366674040595" Date: April 26, 2013, 4:30 PM PST Message-ID: <email@example.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:
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.
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.
Update: Fixed a typo in the domains thanks to a reader. Without it, my example wouldn't have made sense and *won't* pass DMARC.
Thanks Terry. This series is very informative. Nice compilation for a biginer.
I think this series the best resource out there to figure out SPF and DKIM settings in alignment with DMARC.
Just to clarify, in the following text, "news.example.com" should be "news.oceanicairlines.com", right?
[BigCommunications.com can now send email with the RFC 5322.From as “firstname.lastname@example.org”, but must specify *news.example.com* in the d= field in the DKIM header or the RFC 5321 From, or both.]
And I share your love of "Lost" [Oceanic Airlines]!