Antispoofing

%3CLINGO-SUB%20id%3D%22lingo-sub-781684%22%20slang%3D%22en-US%22%3EAntispoofing%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-781684%22%20slang%3D%22en-US%22%3E%3CP%3ERecently%20we%20have%20been%20having%20a%20lot%20of%20issues%20with%20spoofed%20emails.%20The%20Return-Path%20address%20will%20normally%20be%20a%20gmail%20address%20and%20the%20From%20address%20will%20be%20example%40mydomain.com%20asking%20for%20one%20of%20our%20users%20to%20do%20them%20a%20favor.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20looked%20through%20our%20anti-phishing%20settings%2C%20impersonation%20settings%2C%20antispoofing%2C%20etc.%20Everything%20looks%20like%20it's%20set%20correctly%2C%20but%20I%20would%20assume%20something%20in%20one%20of%20these%20policies%20should%20stop%20those%20emails%20from%20coming%20through%20without%20any%20sort%20of%20flag%20or%20intervention.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20there%20anyway%20to%20setup%20a%20transport%20rule%20that%20will%20look%20at%20both%20the%20sender%20and%20from%20addresses%20and%20if%20they%20are%20different%2C%20insert%20a%20disclaimer%20to%20warn%20the%20recipient%20it's%20an%20impersonation%3F%20Or%20is%20there%20something%20within%20one%20of%20the%20policies%20I%20mentioned%20previously%2C%20that%20will%20already%20do%20this%20(or%20automatically%20route%20it%20to%20Junk%20Mail%20or%20Quarantine)%20and%20I%20have%20it%20configured%20incorrectly%20or%20not%20set%20to%20a%20high%20enough%20threshold%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-781684%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAnti%20Spoof%20Policy%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAnti-Phishing%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EEmail%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EEmail%20Security%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%20%26amp%3B%20Compliance%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-799747%22%20slang%3D%22en-US%22%3ERe%3A%20Antispoofing%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-799747%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F301580%22%20target%3D%22_blank%22%3E%40EASchmitt%3C%2FA%3E%26nbsp%3B%20Have%20you%20checked%20your%20SPF%20Records%20(if%20not%20already)%20.%20Spoofing%20generally%20happens%20when%20you%20have%20SPF%20Records%20setup%20incorrectly.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3ETo%20stop%20spoofing%2C%20the%20email%20filtering%20industry%20has%20developed%20email%20authentication%20protocols%20such%20as%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Foffice365%2FSecurityCompliance%2Fset-up-spf-in-office-365-to-help-prevent-spoofing%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3ESPF%3C%2FA%3E%2C%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Foffice365%2FSecurityCompliance%2Fuse-dkim-to-validate-outbound-email%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EDKIM%3C%2FA%3E%2C%20and%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Foffice365%2FSecurityCompliance%2Fuse-dmarc-to-validate-email%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3EDMARC%3C%2FA%3E.%20DMARC%20prevents%20spoofing%20examining%20a%20message's%20sender%20-%20the%20one%20that%20the%20user%20sees%20in%20their%20email%20client%20(in%20the%20examples%20above%2C%20this%20is%20service.outlook.com%2C%20outlook.com%2C%20and%20accountprotection.microsoft.com)%20-%20with%20the%20domain%20that%20passed%20SPF%20or%20DKIM.%20That%20is%2C%20the%20domain%20that%20the%20user%20sees%20has%20been%20authenticated%20and%20is%20therefore%20not%20spoofed.%20For%20a%20more%20complete%20discussion%2C%20see%20the%20section%20%22%3CEM%3EUnderstanding%20why%20email%20authentication%20is%20not%20always%20enough%20to%20stop%20spoofing%22%3C%2FEM%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Elater%20on%20in%20this%20article.%3C%2FP%3E%3CP%20class%3D%22%22%3EHowever%2C%20the%20problem%20is%20that%20email%20authentication%20records%20are%20optional%2C%20not%20required.%20Therefore%2C%20while%20domains%20with%20strong%20authentication%20policies%20like%20microsoft.com%20and%20skype.com%20are%20protected%20from%20spoofing%2C%20domains%20that%20publish%20weaker%20authentication%20policies%2C%20or%20no%20policy%20at%20all%2C%20are%20targets%20for%20being%20spoofed.%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Foffice365%2Fsecuritycompliance%2Fanti-spoofing-protection%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Foffice365%2Fsecuritycompliance%2Fanti-spoofing-protection%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3EPls%20see%20the%20article%20and%20compare%20your%20current%20settings%20to%20block%20these%20spoof%20emails.%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3ECheers%20!%3C%2FP%3E%3CP%20class%3D%22%22%3EAnkit%20Shukla%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

Recently we have been having a lot of issues with spoofed emails. The Return-Path address will normally be a gmail address and the From address will be example@mydomain.com asking for one of our users to do them a favor.

 

I looked through our anti-phishing settings, impersonation settings, antispoofing, etc. Everything looks like it's set correctly, but I would assume something in one of these policies should stop those emails from coming through without any sort of flag or intervention.

 

Is there anyway to setup a transport rule that will look at both the sender and from addresses and if they are different, insert a disclaimer to warn the recipient it's an impersonation? Or is there something within one of the policies I mentioned previously, that will already do this (or automatically route it to Junk Mail or Quarantine) and I have it configured incorrectly or not set to a high enough threshold?

1 Reply

@EASchmitt  Have you checked your SPF Records (if not already) . Spoofing generally happens when you have SPF Records setup incorrectly. 

 

To stop spoofing, the email filtering industry has developed email authentication protocols such as SPF, DKIM, and DMARC. DMARC prevents spoofing examining a message's sender - the one that the user sees in their email client (in the examples above, this is service.outlook.com, outlook.com, and accountprotection.microsoft.com) - with the domain that passed SPF or DKIM. That is, the domain that the user sees has been authenticated and is therefore not spoofed. For a more complete discussion, see the section "Understanding why email authentication is not always enough to stop spoofing" later on in this article.

However, the problem is that email authentication records are optional, not required. Therefore, while domains with strong authentication policies like microsoft.com and skype.com are protected from spoofing, domains that publish weaker authentication policies, or no policy at all, are targets for being spoofed.

 

https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spoofing-protection 

 

Pls see the article and compare your current settings to block these spoof emails.

 

Cheers !

Ankit Shukla