We help IT Professionals succeed at work.

DMARC and SPF not protecting as expected.

mbkitmgr
mbkitmgr used Ask the Experts™
on
Is use DMARC and SPF to protect my domain, however a client recently became infected with malware and propogated the malware via spoofed email.  Now clients of mine are receiving mail addressed as me.  The question is how, what have I missed here.

Details
DMARC Record
v=DMARC1; p=none; rua=mailto:helpdesk@mydomain,mailto:7ffa0582@mxtoolbox.dmarc-report.com; ruf=mailto:My.name@mydomain,mailto:7ffa0582@forensics.dmarc-report.com; fo=1

SPF
v=spf1 +a +mx +ip4:M111.111.111.111 ~all
where
  • IP is my public IP address
  • MX is my cload spam filter provider.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2016

Commented:
it is up to the receiver to act on dkim missing or invalid. Per RFC4781 Email servers should not reject messages because of missing or unverifiable DKIM signatures.  They instead should get a spam confidence level that is high
~all is a softfail,Allow mail whether or not it matches the parameters in the record
-all is a hard fail
Dr. KlahnPrincipal Software Engineer

Commented:
David is correct.  DKIM, DMARC and SPF actions are always taken at the receiving end.  You can say "Here are our keys, verify against them" and "Here are our approved senders, verify against this list" but at the end of the day what a receiving MTA does is not under your control.

Regarding SPF:  If SPF policy commands a hard fail, some valid email is going to be rejected by MTAs which don't process SPF correctly.  If SPF policy commands a soft fail, receiving MTAs are going to let the email pass whether it's valid or not - which is useless as far as validation.

SPF can validate a sender but (I/M/O) as far as invalidating an invalid sender it is not useful and should not be used for that purpose.
mbkitmgrOwener

Author

Commented:
Thanks David and Dr Klahn.  We are certainly on the same page about the receiver needing to verify the msg validity via SPF etc, the thing that has me stumped is that O365 is letting them thru and at least one other cloud based spam filter service that I am aware of.  I expected O365 spam filter to have rejected the messages, and hence checking what I hove not done.

I thought that the settings I had chosen were adequate to stop spoofing in this way.  

Should I change '+a' to 'a' and change ~all to -all?
Top Expert 2014
Commented:
Regarding your DMARC record - your policy is set to none (p=none), so it's requesting that recipients simply report on mail they've received from your domain.  You should be using the reports you get to verify whether your sources are covered by your records.  Once you're comfortable of that, move on to a quarantine or reject policy.

From https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email
Best practices for implementing DMARC in Office 365

You can implement DMARC gradually without impacting the rest of your mail flow. Create and implement a roll out plan that follows these steps. Do each of these steps first with a sub-domain, then other sub-domains, and finally with the top-level domain in your organization before moving on to the next step.

    1. Monitor the impact of implementing DMARC

    Start with a simple monitoring-mode record for a sub-domain or domain that requests that DMARC receivers send you statistics about messages that they see using that domain. A monitoring-mode record is a DMARC TXT record that has its policy set to none (p=none). Many companies publish a DMARC TXT record with p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy.

    You can do this even before you've implemented SPF or DKIM in your messaging infrastructure. However, you won't be able to effectively quarantine or reject mail by using DMARC until you also implement SPF and DKIM. As you introduce SPF and DKIM, the reports generated through DMARC will provide the numbers and sources of messages that pass these checks, and those that don't. You can easily see how much of your legitimate traffic is or isn't covered by them, and troubleshoot any problems. You'll also begin to see how many fraudulent messages are being sent, and from where.

    2. Request that external mail systems quarantine mail that fails DMARC

    When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, and you understand the impact of implementing DMARC, you can implement a quarantine policy. A quarantine policy is a DMARC TXT record that has its policy set to quarantine (p=quarantine). By doing this, you are asking DMARC receivers to put messages from your domain that fail DMARC into the local equivalent of a spam folder instead of your customers' inboxes.

    3. Request that external mail systems not accept messages that fail DMARC

    The final step is implementing a reject policy. A reject policy is a DMARC TXT record that has its policy set to reject (p=reject). When you do this, you're asking DMARC receivers not to accept messages that fail the DMARC checks.

There's more good info on that page, so I suggest reading it and the others in the category.
Even if you have p=reject, Office 365 doesn't reject received mail that fails a DMARC check.  It marks it as spam, but the receiver is still left to configure what they do with such email.
mbkitmgrOwener

Author

Commented:
Thanks Footech,

I ended up checking with DMARC.org after reading your post.  I'm not using O365, but I've taken the leap and set the policy in DMARC to p=reject.  My on-prem exchange server is the only source for email so it should not present any issues.  

Thats interesting about O365 and DMARC.  It explains a recent event where another B2B client opened an attachment that was loaded.  It sent itsef out, was stopped in its tracks except for other companies on O365, who received it without modification or flagging.
mbkitmgrOwener

Author

Commented:
Many thanks for the input