This mail that got through has me stumped. It appeared to me as being from PayPal <[email protected]> in my Inbox. I happened to look at the original and it says SPF, DKIM and DMARC all passed.

If I'm reading this right, connected to mail2550.paypal-notification.com and sent the mail. They used a Return-Path: <[email protected]>.

bounce.paypal.mkt2944.com (currently) has a SPF record of v=spf1 a ip4: ip4: -all. So OK, they setup a spam mailer and worked it so SPF passes (the mail server paypal-notification.com is gone, seemingly owned by MarkMonitor now, so somebody else noticed this).

But then the DKIM signature has

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=spop1024; d=paypal.com; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type: X-CSA-Complaints:List-Unsubscribe;

Is this not saying "I'm signing all these headers with the key who's public portion is in a TXT record at spop1024._domainkey.paypal.com" (which exists)?

This passes, to my surprise

Authentication-Results: mx.google.com;

I've looked over and over to see if it's a close-cousin typo thing, or unicode address, etc. But it really seems to be signed by that paypal.com key...?

After that, it's still unclear to me why DMARC then passes -- I thought the From: address had to be "aligned" with the Return-Path:?

Delivered-To: <[email protected]>
Received: by 2002:a4a:804a:0:0:0:0:0 with SMTP id y10csp7519296oof;
        Mon, 22 Nov 2021 12:45:16 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyxHoL8oksdcw38NnmHlTdPo1UfJoTCZ/wFDToSgMfRPG6WgHlKDtKbSjMXNh5t44nHazym
X-Received: by 2002:a25:4543:: with SMTP id s64mr27510605yba.304.1637613916462;
        Mon, 22 Nov 2021 12:45:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1637613916; cv=none;
        d=google.com; s=arc-20160816;
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=spop1024 header.b=NSAupQiY;
       spf=pass (google.com: domain of v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com designates as permitted sender) smtp.mailfrom=v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
Return-Path: <v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com>
Received: from mail2550.paypal-notification.com ([])
        by mx.google.com with ESMTPS id n184si7359975ybn.210.2021.
        for <[email protected]>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 22 Nov 2021 12:45:16 -0800 (PST)
Received-SPF: pass (google.com: domain of v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com designates as permitted sender) client-ip=;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=spop1024 header.b=NSAupQiY;
       spf=pass (google.com: domain of v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com designates as permitted sender) smtp.mailfrom=v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=spop1024; d=paypal.com; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type: X-CSA-Complaints:List-Unsubscribe; [email protected]; bh=CXo6gpd99q61PdtNQYL0HweNp45DQK9gDadq1QHszOQ=; b=NSAupQiYb884cGVqugiXkhz/FlcoddCqXJLcD+gwE2xFNP+27ZRQFCGOL61uEai1EdgqXLS0FKSV
Received: by mail2550.paypal-notification.com id hjg0lo2r7aoj for <[email protected]>; Mon, 22 Nov 2021 20:37:22 +0000 (envelope-from <v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com>)
Date: Mon, 22 Nov 2021 20:37:22 +0000 (GMT)
From: PayPal <[email protected]>
Reply-To: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Subject: Notice of Unclaimed PayPal Funds
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1300052_1672151020.1637613438245"
x-mid: 70903810
X-CSA-Complaints: [email protected]
x-rpcampaign: sp70903810
x-job: 70903810
x-orgId: 35487
List-Unsubscribe: <http://links.paypal.mkt2944.com/luoo/v1/...>, <mailto:v-edjoiac_ibeieokafk_iekbmfgb_iekbmfgb_a@bounce.paypal.mkt2944.com?subject=Unsubscribe>

Am I missing something obvious?!


It really does seem to pass DKIM.

$ opendkim-testmsg < Notice\ of\ Unclaimed\ PayPal\ Funds.eml
$ echo $?

update 2

Almost definitely a compromise of/via Acoustic, which was apparently once called "silverpop"

We're 10-year Acoustic Campaign veterans - original beta testers and daily users of the marketing automation tool for the last decade, since it was called Silverpop and then IBM Watson Campaign Automation.

The DKIM key -- spop1024._domainkey.paypal.com, from googling, refers to "silverpop 1024" (here's Wikimedia getting rid of it https://phabricator.wikimedia.org/T214525). This is a legitimate key, but old. The classic "it's an older code, Sir, but it checks out" attack with a forgotten host, maybe? is owned by "acoustic.co". It sent the message and signed it. Not sure where the mail2550.paypal-notification.com bit comes from, it's now owned by MarkMonitor.

Also, the List-Unsubscribe: <http://links.paypal.mkt2944.com/luoo/v1/...> link seems legitimate. http://links.paypal.mkt2944.com still has some landing page branded with silverpop. This suggests to me the service actually "constructed" this mail, rather than say an plain open-relay situation.

As noted below, this does not include any obvious phishing login links. The idea must be that you log into your account legitimately, and can't find your "unclaimed funds" and call the phone number at the bottom of the email with your "client id".

This PayPal account is actually closed, but was registered in California when I lived there (this fact, and that it made it into my inbox, was what got me looking at it closely). "Send this message to old accounts in California" seems like the type of thing this Acoustic marketing mail stuff does, so maybe that is related.

Dastardly ... I wonder how many hits they got from this ...

  • 1
    You say: "After that, it's still unclear to me why DMARC then passes -- I thought the From: address had to be "aligned" with the Return-Path:?" That is the SPF part of the DMARC check. But, only one check needs to pass, SPF or DKIM, aligned with the FROM in order for DMARC to pass. If the header is faked, than there should be a second Authentication-Results header among those headers. But also it is unlikely Google would have trusted it. Indeed, the DKIM selector record exists, so it looks like a compromised private key. You should at least report this to Paypal, so they can have a look.
    – Reinto
    Commented Nov 24, 2021 at 8:25
  • 2
    In addition the possibilities mentioned above by @SteffenUllrich, it's also possible that this may actually be a legitimate message from Paypal. I viewed the message source in a mail client, and curiously there are no links in the message (phishing or otherwise). Also, a quick Google search for 'paypal california unclaimed property' returns several results referencing similar messages that seem to indicate that these messages are in fact legitimate. OP, have you considered replying to replying to [email protected] to inquire?
    – mti2935
    Commented Nov 24, 2021 at 12:41
  • 2
    @ianw, Interesting. So, your theory is that the private key for spop1024._domainkey.paypal.com has been 'hijacked', and is now being used to send these fraudulent emails with valid DKIM signatures for paypal.com. It also seems like Paypal might need to clean up their SPF records as well. Have you reported this to Paypal?
    – mti2935
    Commented Nov 26, 2021 at 16:00
  • 1
    Your analysis looks solid to me - I can't see any other way that this would occur without a compromised key, and it certainly wouldn't be the first time that a third party's lack of security hygiene has impacted a large vendor whose security posture is usually strong. I'd echo mti's suggestion of reporting this to PayPal.
    – Polynomial
    Commented Nov 26, 2021 at 17:28
  • 1
    Yes I have reported to PayPal. links.paypal.mkt2944.com -- which appears to be a genuine Acoustic server, lists [email protected] which no longer receives mail...
    – ianw
    Commented Nov 27, 2021 at 17:59

2 Answers 2


This is a legitimate email that Paypal has been sending for over a decade, there is nothing suspicious about it.

Here's a post from 2012 with exactly the same email https://www.flickr.com/groups/olympus-e500/discuss/72157630856927736/


"Spoofing" is generally considered to be some form of forged message, usually through taking advantage of something within the DNS records, messaging system, or other aspect outside of the standardized methods for authentication.

This email:

✅ Legitimately passes SPF authentication check
✅ Legitimately passes DKIM authentication check
✅ Legitimately passes DMARC authentication check
✅ DNS records for sending domain appear correctly configured.

It is authenticated, therefore not spoofed.

Generally, when a message is from: a server that has been hacked, an account with compromised credentials, a rogue vendor, etc., it can be said to be fraudulent, but not spoofed.

However, the email described in the question otherwise appears legitimate because it is a commonly sent email from PayPal that is also commonly misinterpreted as a phishing attempt.

You can go to the California State Controller's Office to find and claim your unclaimed property PayPal is informing you about.


In the off-chance that going to this site and entering every address you can recall having while living in California does not reveal your hidden treasure, you can try contacting PayPal through some communications channel you can verify independent of the message and ask them where to find out about this information that they have on record.

  • I mentioned above. Admittedly I have redacted the mail as it has my personal details! The two clues are that paypal-notification.com has been claimed by markmonitor.com now, and the phone number at the bottom 1-866-XXX-5854 appears to be the "attack vector". They don't provide any obvious misdirect links. I think the play must be to get you to legitimately log in and look around trying to find the "claim" button. When you don't find it, you call the number at the bottom... It is certainly a level above usual phising efforts
    – ianw
    Commented Nov 27, 2021 at 18:03
  • Please expand the MarkMonitor claim, because it has only been stated, not explained, and the last update to the domain registry was six months prior to your email. Since you don't provide the phone number, there is no way to verify it as a scam number. Generally, you don't provide any information other than confirmation that all authentication tests pass, which means this isn't a spoofed email. Additionally, searches on the 'net reveal this is a commonly misinterpreted legitimate PayPal message. My experience is that most people I know have unclaimed property, but not necessarily from PayPal.
    – Paul
    Commented Nov 27, 2021 at 18:17
  • OP briefly posted the full source of the email in question. From that, I copied the phone number, which was: 866-648-5854. But, there is something else squirrelly about this message. The envelope sender is [email protected]. The SPF record for bounce.paypal.mkt2944.com designates as a permitted sender for mail from [email protected]. The message was in fact sent from, so it passes the SPF check. Now, reverses to mail2550.paypal-notification.com. But, mail2550.paypal-notification.com does not forward to
    – mti2935
    Commented Nov 29, 2021 at 15:29
  • Normally the hostname of a legitimate mail server forwards to its ip, and its ip reverses back to that same hostname. Spam filters will often block messages sent from hosts that do not pass this test, as this is often the case with systems that have been compromised and are being used to send spam. See serverfault.com/questions/45272/… for more info. This might be what OP is alluding to with his claim about MarkMonitor, as MarkMonitor seems to be the registrar for paypal-notification.com.
    – mti2935
    Commented Nov 29, 2021 at 15:29
  • A sender can fail FCrDNS forever and forever pass SPF. These aren't related and misconfigurations are common, which is why it's optional and many admins, including the ones at Google, don't strictly enforce. Not to mention there is no published standard stating FCrDNS MUST pass and FCrDNS definitions originate in informational RFC1912.
    – Paul
    Commented Nov 29, 2021 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .