I tested with a simple email spoofer and Office 365 (Forefront), and the spoofed email gets scored as suspicious (score of 5/9). The headers are inscrutable so it is difficult to see just how much the lack of MX record contributed to the score. The same test to Gmail, a couple of times, and it never even got delivered. Both of these tests should be repeated with much more rigor, however. SpamAssassin has a rule NO_DNS_FOR_FROM for domains without a MX or A record. (Thanks @pornin) So, it seems that a lack of MX records does factor into the spam score. Perhaps we do not need to add SPF to all our unused domains since spam filters appear to account for this problem.

If any email service is processing mail, then there is a possibility that they can "read" the emails. That goes for ProtonMail, too. The only way to avoid the risks is to have end-to-end encryption of the email content. Email has never meant to be secure from the email handling infrastructure.

Would it be possible to connect with a random Outlook account (attacker@outlook.com) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using name@example.com? Generally not. By default, all SMTP connections to O365 must be authenticated first. In the case of a domain having a non-authenticated SMTP connector set up, it would typically be restricted to accept mail from specific IP addresses only, i.e. ones that you trust to send email for your domain. Third party email providers may handle authentication differently, and may in fact be susceptible to this type of spoofing.

This is not a new problem. I haven't had to work around it in a few years, so I don't know if the state of the art has changed, but there are a few things you can try: 1) don't process your link unless it has a special query param in it. The query param is added by a client-side redirect (I used http://insider.zone/tools/client-side-url-redirect-generator/ to handle some of the cross-browser messiness) but the server-side code would return this with the query-paramless link to the browser. So: user clicks 'https://magiclink.foo.org/ajskdfjwlakefj' server does not see magic redirect, so redirects to 'https://magiclink.foo.org/ajskdfjwlakefj?follow=true' and server-side code, seeing "follow=true", would process and then invalidate that token. 2) I think you could do the same with a redirect from GET->POST with a form submit, but I haven't tried. Good luck!

It is unclear what the actual security and usability requirements are, but if you want to prevent spoofing of the sender you need to authenticate the sender somehow. This could for example be done with PGP or S/MIME signed mails, although most users are not able to send such mails. It could also be done by fingerprinting the mail client used for sending and/or the transport path and require some other form of authentication when this fingerprint changes (like a reply-mail the user has to acknowledge or a link which need to be visited). One could also require some one time token (TAN) to be send together with each mail and offer the user to load more such tokens once authenticated on the web site. And one could probably imagine various other methods with different trade offs between security and usability. But again, the actual security and usability requirements here are not clear.

The question was answered in the comments and summarized here in case someone else comes searching with similar questions. The email address on its own won't reveal IP address of Sender. One needs to have access to email sent from given address and email service provider has added to headers sender's IP address. One should note that many service providers do not add IP address of sender. Further, this applies to only emails sent out from a fixed line connections like Broadband or Leased Line etc. Emails sent out of mobile phone connections usually carry the service providers IP address and location information is out of reach for most people. Edit: As @scott commented one can always find the incoming mail server IP address for the email address in question. If the given domain is hosted on mail services like GSuite, the IP address of incoming mail server will reveal very little or nothing.

Login ID should be considered public. So feel free to send it per email.

Yes this is a vulnerability, more than one vector is depend on same logic, examples listed below. SMTP VRFY option enabled OpenSSH Username Enumeration SIP INVITE/REGISTER Response User Enumeration BUT as you mentioned vulnerability is never black and white, AWS can consider this is a risk and they may implemented rate limiting, if so they are reduce risk significantly.

I've had this issue before, with another e-mail provider. In my case, someone was able to obtain my e-mail address, but not my password. Then, my e-mail address was used as the "reply-to" or the "sent-from" address on a spam e-mail. It is annoying, but you're e-mail itself is probably safe. (TFA helps). Example for clarity: Through whatever means, I notice that a valid e-mail address is Mycroft@googlemail.com. Now, I can authenticate to another mail server, say postoffice.com. I can then use a sendmail program that does something like this: to: JoeBloggs@aol.com from: Mycroft@googlemail.com Subject: Best Diet Program Ever!! Body: blah, blah, blah. For more info, click here! EOT You will then get the mailer-daemon message, and I have not compromised your e-mail, but I have compromised your email ADDRESS.

They might be load-balancing internally. Let's say you are dealing with a team of 10 scammers who spam 10,000,000 people and assume that about 200 marks reply. How do they make sure those 200 marks are evenly distributed on their 10 people? By having them all reply to the same address and then distribute them internally. Whoever gets assigned to the mark then replies from their own email so all further correspondence goes through their personal mailbox. Or they might even go a step further and give each mark an own mailbox to converse with so the scammers don't mix up their marks. A mark might suddenly reply from a different account or accidentally start a new email thread just mentioning "the deal we agreed on". When a scammer operates on multiple marks at the same time (and most scammers do) then they really don't want to be confused by that and risk breaking the illusion that the mark is in some unique negotiation with a private person.

After some serious digging we were able to find a solution to this problem. The UTF-8 encoding that we were seeing specifically =E2=80=8B encodes to a no width space. This is used to bypass the filter by breaking up text but still look normal on the recipients end. Filtering It Out We were able to copy the character from this website: https://codepen.io/chriscoyier/pen/iLKwm We pasted this character into exchanges filtering rules and it was able to detect and properly filter the encoding. Be warned this character is fairly common in day to day emails apparently so if you are going to filter based off of this character be sure to send it to a moderator do not just delete it without notifying anyone. Hope this helps some people as this took a lot of work to figure out.

I agree with the comment; this doesn't sound like an issue to me. If the email legitimately came from Stockholm Arlanda Airport (you can check the email address*) and if the email doesn't ask for any personal information, I wouldn't worry. I don't like putting my personal email address in captive portals; I don't want be on their email list for something I likely don't care about. I suspect that's what happened here - someone simply typed in your email instead of their own. *Note, most modern email providers do filter spoofed emails, and the probability that's the case is low.

It's very common practice even by legit companies to track open success rates by placing a image link in the body of an email. Then if your email browser like outlook is configured to auto-load images in emails then it makes an HTTP request out to a website to load the image. That request will have a unique id in the url specific to you ... so now that web server hosting the image knows that you opened your email. That is all done basically without any real hidden code ... just standard HTML in the body of an email. If there was "hidden code" then perhaps things like scripts hidden in an SVG image or perhaps it was a different attachment type like .html or .js

Relaxed in DMARC doesn't mean completely liberated, but has limitations. From RFC 7489, 3.1.2 SPF-Authenticated Identifiers (emphasis is mine): In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment. The algorithm to determine the Organizational Domain is specified in section 3.2, but basically the Organizational Domain is just your domain (including TLD) e.g. example.com is the Organizational domain for all a.b.c.d.example.com. Thus, since com is an IANA-registered TLD, a subject domain of a.b.c.d.example.com would have an Organizational Domain of example.com. The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current. This means that the relaxed alignment for From: user@example.com would pass if the envelope sender used in SMTP MAIL FROM command was something like newsletter@mail-provider.example.com as the organizational domain for both is the same, but example.mail-provider.com has a different organizational domain and fails. So, what's the solution? You don't necessarily have to do anything. DMARC passes if either SPF or DKIM passes. If you want both to pass, the mail provider has to use your domain or its subdomain as the envelope sender. That should be possible, as you already have include:d their SPF in your SPF record.

X can probably prove those things the headers, but you'll need the whole message so the cryptographic proofs can be verified. You're mentioning ARC, which unfortunately requires a bit of trust, so it depends on who signed what. X should have a cryptographic signature from the ARC signer, which might be good enough assuming that comes from Google or something internal to the company, since that means the ARC signer received the message with a valid DKIM signature. It's also possible that the DKIM signature itself, which I assume is what you're seeking, is intact enough (e.g. if you revert any Subject or body alterations to how they looked when X sent the message, it's likely to pass DKIM). If the DKIM signature can't be vetted, you must rely on the ARC signature and therefore you must trust that additional infrastructure. Armed with ARC from a trusted party or a valid DKIM signature, you can prove at least that the message passed through the DKIM-signing relay with the given DKIM-signed headers (h=…), which should include the Date, To, Subject, From, and a hash of the body (b=…). For X to prove a DKIM match, all signed portions of the message must be provided unmolested (this includes each header in the h=… part plus the body if there's a b=… part). ARC merely signs the Authentication-Results header, but it's still best if you provide the whole email. This might be complicated if there's confidential content in the body, but perhaps you can use the body hash instead.