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.
Comments
Post a Comment