0

I've been trying to wrap my head around some of the information I've gathered online, and I was hoping for some clarification.

We are using Office 365, for our email server.

A.) Are SPF records and DKIM actually doing anything on their own, if DMARC is not enabled or set to p=none?

B.) SPF Record dictates which Email servers, IP's or external domains are allowed to send email as our domain, correct? For example, we could authorize gmail.com or yahoo.com to send email as our domain with an SPF record?

or

When someone tries to send an email, from anywhere in the world as [email protected], it would be our SPF record that checks the email was sent from a valid source, right?

C.) According to my DMARC Reports, the only IP address that fails DKIM, is our internal corporate IP, why might this be? Everything external passes DKIM.

*Emails sent internally, from employee to employee, the header states DKIM=none

*I can't seem to find any emails that say DKIM=fail.

D.) DKIM sounds more like us, protecting our customers from receiving fraudulent emails. Unless, someone tries to spoof our domain and send us something. Correct?

2 Answers 2

3

A) Yes, a spam filter for a receiving server can use SPF and DKIM records on their own to evaluate mail that claims to be sent from your domain. DMARC does add an additional layer of security, but also provides the recipient a way to automatically report back to you on received mail. By parsing the XML reports sent by mail recipients you can find out if mail is being sent as if from your domain by third parties.

B) Yes. For example: We send most of our mail via Microsoft EOP, but some is sent directly from a local Postfix server. By adding a DNS alias for EOP and the specific IP address for our local outbound server to our SPF record, we mark both sources as legitimate.

Just to nit-pick, though: Your SPF record by itself doesn’t check anything; it’s just a dumb text string. The checking is performed by servers that compare the mail header contents with a few DNS TXT records including SPF if it exists.

C) The behavior you describe means you don’t use DKIM to sign mail in your own systems. This is pretty common in Microsoft-based environments. Since the mail isn’t signed at all, you don’t get a signature verification failure.

If you instead would add a DKIM signature to your mail and have the header point at a public DKIM key that didn’t mathematically correspond to the signature, or if you tampered with a mail after it had been signed, you would end up with actual DKIM failures.

D) DKIM is basically a digital signature and a pointer to a public key. It tells the recipient that a mail with this particular hash value did in fact pass through a mail server you trust as a valid sender.

3
  • Appreciate it, most items make some clearer sense now. However C.) As far as I can tell, according to Office 365, I have "Sign messages for this domain with DKIM signatures: Enabled" set for my domain. What else might I need to do to enable it?
    – level42
    Jul 31, 2019 at 16:03
  • 1
    Your mail probably only gets signed upon leaving your tenancy in Microsoft’s environment, then. As I wrote; since these internal mails don’t get signed at all, there’s nothing to fail. Mail sent to external recipients will be signed (you can test it by looking at the header of a mail sent to a mailbox you have with any other provider).
    – Mikael H
    Jul 31, 2019 at 16:56
  • Ah, that does make sense. Much appreciated for clearing that up!
    – level42
    Jul 31, 2019 at 17:45
3

On top of the excellent answer Mikael H wrote, I'd like to emphasize the nit-picking some more.

It is very important to understand that SPF and DKIM (and DMARC for that matter) are just a bunch of DNS text records. It is up to the receiving mail server to implement measures based on what it finds in these records and the results of the checks it is configured to perform.

Also, SPF and DKIM do not protect a receiving party against spoofing. In fact, SPF is checked against the email domain in the bounce address and DKIM is checked against the domain in the d= value in the DKIM signature. Both fields are generally not visible to the recipient of an email, without combing through the actual headers of that email.

That means that both SPF and DKIM may pass, while not at all authenticating the spoofed domain. That is what DMARC aims to fix, the link between the email address that is shown in the email client (FROM field) and the authenticated domain in the bounce address or DKIM d= value.

So to answer your questions with this in mind:

A. Yes, they allow you to authenticate the domains you use to receive bounces on (SPF) and which your cryptographically sign for (DKIM). More and more ESPs check for DMARC alignment whether or not you publish such a record. Most definitely Office 365 works this way (check the authentication-results headers for dmarc=bestguesspass). It influences the classification, it does not treat the emails as if there was a p=reject policy published.

B. No. SPF will not protect your domain from being spoofed. If the FROM address is [email protected] and the bounce address is [email protected] and spoofersdomain.com lists the sending IP in their SPF record, SPF will pass. DMARC alignment will fail, however.

C. Emails are not being DKIM signed. Pretty common for Exchange Server on premise as DKIM signing is not a natively supported feature. In your DMARC reports, the DKIM result may show as none. However, in terms of DMARC it would show as failing (in the policy_evaluated section of the XML document). All (regular, non DSN or forwarded) emails leaving your Office 365 tenant should be signed. If you haven't enabled DKIM for some of your domains, those emails will be signed by selector1-ourdomain-com._domainkey.ourdomain.onmicrosoft.com.

D. Keeping in mind why DMARC is so important, the answer is No. DKIM signing authenticates the domain used in the DKIM signature (d=). This can be an entirely different domain than used in the FROM field that the recipient sees in his email client. DMARC ensures alignment between the domain used in the FROM field and either the domain in the bounce address or the domain used to DKIM sign the message.

Also, a large part of the phishing schemes is spoofing the same domain as the recipient is in. CxO fraud is one of the most well-known examples.

I hope this helps you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .