I've received a phishing email from an @paypal.com email address. (The From: header showed an @paypal.com email address.) Fortunately, the text of the email itself was fishy enough to make me realise it wasn't legitimate. I have no idea how it passed spam filters. I reported the email to both PayPal and my email provider, and I never heard back.

Can you download the email as EML and paste the content here?

Yeah, I don't understand how it passed DMARC and why it wasn't rejected immediately by his mail server (Apple Mail?).

From the article he uses gmail I think

They probably sent it from gmail which would pass the SPF check (google.com and gmail.com have the same SPF). They wouldn't have it signed to pass DKIM, but google doesn't use strict alignment checking so to pass DMARC either SPF or DKIM are acceptable.

    ~ dig _dmarc.google.com txt +short
  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Can't practically require both SPF and DKIM with DMARC anyways. Doing so would also be dumb as it would break forwarding (even when DKIM would otherwise remain intact).

Deprecating SPF would do everyone a favour though. Especially for reasons like these.

SPF alignment ensures the MAIL FROM domain matches the From header. DKIM alignment ensures the From header matches the domain in the DKIM signature header. In the DMARC policy, you can set both adkim=s and aspf=s.

Google owns and manages all of this, so they can send emails with a google.com MAIL FROM, a google.com header, and signed with a google.com DKIM key. And they could do likewise with gmail.com emails.

I'm not clear on why this isn't practical, perhaps there is something I'm missing though? I would appreciate your viewpoint.

Edit: I see you added a point about forwarding.

DMARC specifies that SPF alignment is checked for the domain in the MIME From. The domains in SMTP and MIME From do not have to be the same (nor both align).

Your MTA can still check alignment for both HELO and SMTP From as specified by SPF's RFC(s) though and spam filters often do for extra information/signal.

DMARC's adkim/aspf aren't basically supported in practice. Nor they should be. For reasons already mentioned, as you already read.

So any message from Gmail is treated as legitimate for google.com, and yet Gmail can't do its own checks on outgoing mail to ensure that unauthorized people don't put [email protected] in the From: header? Seriously?

No, gmail will never let you send from an address you don't own.

I'm pretty confident gmail's servers don't let you send with headers matching @google.com email addresses you don't control though.

What you're saying makes little sense.

Yes, SPF (the original design) is horribly broken and trivially bypassed. The most prominent design flaw is that the inbound SMTP service uses the SMTP (rfc5321) MailFrom address for SPF validation, which is not the same sender address shown to the recipient, they can only see the the message (rfc5321) 'From' header address. SPF originally didn't require the domains in the MailFrom and From addresses to match, so an attacker would simply use a domain they control in the MailFrom address, and the 'spoofed' domain in the From header.

That was in 10 years ago though. DMARC fixed this by adding the alignment requirement, meaning that the domains in the MailFrom and From address must match. By default the alignment policy is 'relaxed', meaning that the MailFrom and From domains can differ in subdomain, as long as they share the same organizational domain. Setting the SPF alignment to strict (aspf=s) like you mention in your post requires the domains to match exactly, with no subdomain differences allowed.

So, it doesn't matter that Google doesn't use strict SPF alignment in the DMARC policy, the fact that they have DMARC already adds the requirement to SPF validation that the domains must match.

Yes, google.com and gmail.com use the same IP ranges in the respective SPF policies, but Gmail will never allow you to send email addresses from a domain that you do not own. This is why domain validation is required when you set up Gmail with a custom domain.

The only scenario where your explanation would hold up, is if the attacker was able to gain control of the DNS of a subdomain of the google.com domain, and successfully validated it as a custom domain in Gmail, then send emails from that subdomain in rfc5321.MailFrom address and the google.com domain itself as the rfc5322.From domain.

Probably not the same attack vector, but I've gotten phising emails from a real googlemail.com addresses by the scammer abusing backscatter spam and the reply-to address.

> Wouldn't the Apple account reject it because it fails DKIM/etc?

Yeah, I would be curious to see the actual email headers of what was received.

As an aside, fun fact, this would not be possible with @apple.com because Apple employees have old-school S/MIME signatures as an additional security layer.

How would recipients know to expect an S/MIME signature though. It's not like it's enforced by MTAs like DMARC is.

IIRC, if you're using Apple's Mail client it gets validated against the root cert shipped with MacOS/iOS. You get a little black tick next to the sender.

In theory, third-party places like gmail could (should ?) automagically verify S/MIME sigs where a root cert is readily available.

Support for verification is indeed widespread, but if it's missing there's nothing to verify.

There's no system in place to warn the user when there is no signature and that there should be one.

> this would not be possible with @apple.com because Apple employees have old-school S/MIME signatures as an additional security layer

A few do, but most do not, and certainly Apple's automated-system e-mails do not.

I use gmail and i was attacked almost identically and the email came thru to my gmail with a @google origin account

More details would be great, like the headers.

How Email Spoofing Exploits SPF and DMARC: A Cybersecurity Deep Dive.

https://undercodetesting.com/how-email-spoofing-exploits-spf...

I’ve heard scammers use Google tools like Google forms or Google cloud to send out fraudulent emails that appear like they come from Google.

The latest attempted scams I’m getting on my gmail account are fake postmaster bounces “from” google.com.

There have been cases recently of exploits that successfully spoof valid DKIM credentials too:

https://easydmarc.com/blog/google-spoofed-via-dkim-replay-at...