Further understanding of SPF, DKIM, and DMARC

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 user@ourdomain.com, 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?

Answer

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.